Volume Shadow Copy (VSS): איך זה עובד בפועל — למה תוכנת גיבוי מצליחה להעתיק קבצים שבשימוש

“ניסיתי להעתיק קובץ שאפליקציה אחרת פתחה, ואמרו לי שה-process אינו יכול לגשת לקובץ משום שהקובץ נמצא בשימוש על ידי process אחר.” “ביקשו מאיתנו לגבות את תיקיית הנתונים בלי לעצור את המערכת המרכזית.” “למה תוכנת גיבוי מעתיקה ברוגע קובץ מסד נתונים שבשימוש?” — בין אם מפתחים אפליקציות עסקיות ובין אם מפעילים שרתי קבצים, אלה שאלות שנתקלים בהן במוקדם או במאוחר.

במרכז התשובה עומד Volume Shadow Copy Service (VSS). הוא בנוי בתוך Windows כבר יותר מעשרים שנה, ו-Windows Server Backup, System Restore, וכמעט כל מוצר גיבוי מסחרי יושבים על אותו יסוד.¹

המאמר מיועד למפתחי אפליקציות עסקיות שמתבקשים להוסיף יכולת “העתקת קובץ שבשימוש”, ולאנשי מערכות מידע שמפעילים גיבויים של שרתי קבצים ומחשבים עסקיים. מתוך מקורות ראשוניים נכון לאוגוסט 2026, הוא מסדר את צוות הדמויות של VSS ואיך הוא עובד, את התפעול היומיומי ב-vssadmin, ואת קו הגבול — עד כמה מפתח צריך בכלל להיכנס ל-VSS. סדרת “מעמקי ה-I/O של Windows” נכנסה פנימה אל Cache Manager ו-NTFS; המאמר הזה הוא ההמשך שלה, על שכבת ה-snapshot שיושבת ממש מעל ה-volume.

1. קודם כל, המסקנות

• VSS הוא אוסף ממשקי COM ושירות תיאום שמאפשרים לגבות volume בזמן שאפליקציה ממשיכה לכתוב אליו. הוא בנוי בתוך Windows מאז Windows XP.²
• יש שלושה תפקידים ועוד מתאם. שירות VSS מתווך בין ה-requester שדורש shadow copy (תוכנת גיבוי), ה-writer שמבטיח consistency של נתונים בצד האפליקציה (SQL Server, למשל), וה-provider שיוצר בפועל את ה-snapshot.¹
• ה-system provider התקני של Windows משתמש ב-copy-on-write. במקום לשכפל את ה-volume כולו, הוא מעביר ל-diff area רק את הבלוקים שנכתבים מחדש אחרי ה-snapshot — ורק את תוכנם שלפני הכתיבה. ה-diff area חייב לשבת על volume NTFS.¹
• נקודת עקביות נוצרת דרך “freeze של writers (עד 60 שניות) → יצירת snapshot (תוך 10 שניות) → thaw”. אם אחת ממגבלות הזמן חורגת, היצירה מבוטלת וה-requester מנסה שוב.¹
• שיתוף פעולה של writer משנה את איכות ההעתקה. snapshot בלי שיתוף פעולה של writer שקול ל”הדיסק ברגע שבו נשלף החשמל” (crash-consistent); snapshot עם שיתוף פעולה כבר גלגל logs ועשה flush ל-caches, והשאיר מצב consistent שהאפליקציה עצמה מבטיחה שניתן לשחזור (application-consistent).³¹
• vssadmin הוא הכלי לבדיקת מצב תפעולי. משתמשים ב-list shadows / list writers / list shadowstorage לראות את המצב הנוכחי, וב-resize shadowstorage לכוונן את מגבלת ה-diff area. כשה-diff area אוזל, ה-shadow copies הישנים ביותר נמחקים בשקט.⁴⁵¹
• הטמעת VSS requester באפליקציה עצמית היא משימה גדולה. זה API נייטיב מבוסס COM, בלי wrapper רשמי ל-.NET. ברוב המקרים retries, כוונון share mode, או עצירה קצרה מספיקים; אם באמת צריך VSS, סקריפט DiskShadow הוא התשובה המעשית (Windows Server בלבד).⁶⁷
• shadow copy אינו גיבוי כשלעצמו. כי הפרש ה-copy-on-write תלוי בבלוקים השלמים של ה-volume המקורי, הוא חסר אונים מול כשל שלוקח את ה-volume המקורי כולו, כמו תקלת דיסק או גניבה. גם מול ransomware אי אפשר לסמוך עליו, כי אפשר למחוק את ה-shadow copies עצמם (פרק 7.3) או למצות את ה-diff area בכתיבות המוניות מחדש (פרק 7.4). הוא מקבל משמעות רק כשמשלבים אותו עם גיבויים במדיה נפרדת.¹

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 26, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. הגדרת הבעיה — למה אי אפשר פשוט להעתיק קובץ שבשימוש?

נקודת המוצא היא share mode של קבצים ב-Windows. כשפותחים קובץ ב-Windows (CreateFile), מכריזים, כ-share mode (dwShareMode), מה יורשה ל-processes אחרים לעשות בזמן שהוא פתוח אצלכם. כל עוד process מחזיק את הקובץ פתוח באופן שלא מתיר share לקריאה, כל process שמנסה אחר כך לפתוח אותו לקריאה נכשל ב-sharing violation (ERROR_SHARING_VIOLATION, שגיאה 32).⁸ ב-.NET זו ה-IOException המוכרת (“ה-process אינו יכול לגשת לקובץ משום שהקובץ נמצא בשימוש על ידי process אחר”).

הנקודה החשובה היא שזה לא באג, אלא המנגנון הנכון להגנה על נתונים. אם קוראים באמצע כתיבה לקובץ שנכתב, הקורא מקבל מצב חצוי, באמצע עבודה. כפי שמפורט ב”ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים — נעילת קבצים ושיטות עבודה מומלצות ל-claim אטומי”, תכנון ה-locking הוא היסוד לשילוב בין אפליקציות.

אבל המנגנון הנכון הזה מתנגש ביסודו עם גיבוי.

• קיר ה-sharing violation: קובץ שמסד נתונים או אפליקציה עסקית מחזיקה פתוח אולי בכלל לא ייפתח כמקור להעתקה.
• קיר ה-consistency: גם אם אפשר לפתוח (כי share לקריאה מותר), ההעתקה לוקחת זמן. כי האפליקציה ממשיכה לכתוב בזמן ההעתקה, החצי הראשון והחצי השני של הקובץ יכולים לשקף רגעים שונים, או כמה קבצים (קובץ הנתונים וה-log, למשל) יכולים לצאת מתיאום זה עם זה. וכפי שראינו בפרק “Cache Manager”, כתיבה נוחתת קודם ב-cache שבזיכרון, כך שמבט רק על הקובץ בדיסק אינו מבטיח שרואים את התוכן העדכני.
• קיר התפעול: “אז פשוט עוצרים את האפליקציה ומעתיקים” היא תשובה סבירה עקרונית, אבל אינה מתקבלת במערכת עסקית או בשרת קבצים שעובדים מסביב לשעון.

כלומר, מה שבעצם רוצים הוא “עותק של רגע consistent אחד, בלי לעצור את האפליקציה.” זה יותר מדי לאפליקציות בודדות לפתור לבד, ולכן VSS נבנה כמנגנון ברמת ה-OS. VSS מוצע כמסגרת ממשקי COM שמאפשרת לגבות volume גם בזמן שאפליקציה ממשיכה לכתוב אליו.²

3. צוות הדמויות של VSS —‏ requester, writer, provider

מבנה VSS מתפרק לשלושה תפקידים ולשירות שמתווך ביניהם.¹

האלגנטיות של חלוקת העבודה היא שמוצרים שלא יודעים דבר זה על זה עדיין יכולים לשתף פעולה. תוכנת הגיבוי (ה-requester) אינה מכירה את המבנה הפנימי של SQL Server, אבל ה-writer של SQL Server מצהיר, כ-metadata, אילו קבצים (components) צריך לגבות, ומסדר את הנתונים שלו ממש סביב נקודת העקביות — כך שה-requester יכול לקחת גיבוי consistent פשוט בכך שהוא הולך אחרי ההובלה הזו.¹⁹ כמעט כל מוצר גיבוי צד-שלישי שרץ ב-Windows הוא VSS requester.¹

בתפעול מערכות מידע, הרגע שבו באמת צריך לחשוב על שלושת התפקידים האלה הוא troubleshooting. האם כשל גיבוי הוא בעיה ב-requester (צד התוכנה), ב-writer מסוים (צד האפליקציה), או ב-provider / diff area (צד התשתית) משנה לגמרי לאן מסתכלים (פרקים 5 ו-7).

4. איך snapshots עובדים — copy-on-write ו”נקודת העקביות”

4.1. copy-on-write — לשמור את “הרגע ההוא” בלי לשכפל את ה-volume

שמיעת המילה “snapshot” גורמת לדמיין שכפול של ה-volume כולו, אבל השיטה שה-system provider התקני של Windows באמת משתמש בה היא copy-on-write. ברגע ה-snapshot כמעט לא מועתק דבר. אחר כך, כשבלוק ב-volume המקורי עומד להיכתב מחדש, תוכן הבלוק שלפני הכתיבה מועבר ל-diff area (shadow copy storage) לפני שהכתיבה מחדש מסתיימת, ורק אז הכתיבה מורשית לעבור.¹ ההעברה צריכה לקרות רק בפעם הראשונה שכל בלוק נכתב מחדש; כתיבה מחדש לבלוק שכבר הועבר אינה מגדילה עוד את ה-diff area.

כדי לקרוא את “ה-volume כפי שהיה באותו רגע”, הבלוקים שלא השתנו נקראים מה-volume המקורי, והבלוקים שהשתנו נקראים מה-diff area, ושניהם מורכבים יחד. כי מועתק רק החלק שהשתנה, היצירה מיידית והמקום שנצרך הוא רק ההפרש. הצד השני הוא ש-volume שנכתב אליו בכבדות צורך את ה-diff area מהר יותר (רמז לפרק 7), וה-diff area יושב על volume NTFS באותו מחשב כמו נתוני המקור.¹ מה שמחזיק את המנגנון הזה הוא קובץ הרכיב של ה-system provider, swprv.dll, וה-driver שמיירט את ה-I/O של volume, volsnap.sys.¹ אם מעניין אתכם ה”איך” של יירוט מחסנית ה-I/O, ראו גם “filter drivers ו-Minifilter”.

יש גם שיטות אחרות: העתקה מלאה, שמנתקת mirror, ו-redirect-on-write, שכותב שינויים ל-volume נפרד; hardware providers משתמשים בשיטה שמתאימה ביותר למערך האחסון.¹

4.2. זרימת יצירת נקודת העקביות — 60 שניות ל-freeze, 10 שניות ליצירה

אם copy-on-write הוא על איך הנתונים נשמרים, הערך האמיתי של VSS הוא איזה מצב, של איזה רגע, נשמר — כלומר איך נוצרת נקודת העקביות. יצירת shadow copy מתקדמת כך.¹

flowchart TB
    accTitle: זרימת יצירת ה-shadow copy
    accDescr: זרימת יצירת ה-shadow copy. מה שנעצר בפועל הוא רק שניות ספורות עד עשרות שניות; הגיבוי עצמו רץ מול ה-snapshot אחר כך
    R["ה-requester דורש יצירה<br/>מונה writers ואוסף metadata"] --> M["כל writer מצהיר על יעדי הגיבוי<br/>(components) ב-XML"]
    M --> P["כל writer מכין את הנתונים<br/>גלגול logs, flush של cache וכדומה<br/>למצב consistent שניתן לשחזור"]
    P --> F["freeze של I/O כתיבה של ה-writers<br/>(קריאה אפשרית. עד 60 שניות)"]
    F --> FS["VSS עושה flush ל-buffers של מערכת הקבצים<br/>ומקפיא את מערכת הקבצים"]
    FS --> C["ה-provider יוצר את ה-shadow copy<br/>(תוך 10 שניות. I/O כתיבה נשאר מוקפא)"]
    C --> T["שחרור מערכת הקבצים → thaw של ה-writers<br/>האפליקציה חוזרת לכתוב"]
    T --> B["ה-requester מריץ את הגיבוי מ-shadow copy<br/>במשך הזמן הנדרש"]

איור 1: זרימת יצירת ה-shadow copy. מה שנעצר בפועל הוא רק שניות ספורות עד עשרות שניות; הגיבוי עצמו רץ מול ה-snapshot אחר כך

יש שלוש נקודות לתשומת לב.

1. האפליקציה נעצרת רק לרגע שבו נוצרת נקודת העקביות. ה-freeze מוגבל ל-60 שניות, והיצירה (ה-commit) בידי ה-provider מוגבלת ל-10 שניות; חורגים מאחת מהן — היצירה מבוטלת וה-requester מנסה שוב.¹ הגיבוי עצמו, שיכול לקחת שעות, רץ מול ה-shadow copy המוכן לקריאה בלבד בזמן שהאפליקציה ממשיכה לרוץ.
2. קריאה עדיין אפשרית בזמן ה-freeze. רק I/O כתיבה נעצר.¹
3. גם מערכת הקבצים מוקפאת. כי VSS עושה flush ל-buffers של מערכת הקבצים לפני ה-freeze, כתיבות שישבו ב-cache, ו-metadata של מערכת הקבצים, משתקפים ב-snapshot בסדר consistent.¹

4.3. crash-consistent ו-application-consistent

כאן נכנס הבחן חשוב שקובע את איכות הגיבוי.

shadow copy שנוצר בלי שיתוף פעולה של writer נמצא במה שמינוח Microsoft קורא מצב crash-consistent. ההגדרה הרשמית היא “מצב דיסק השקול למצב שהיה נמצא אחרי כשל הרסני שסוגר את המערכת בפתאומיות”, והשחזור ממנו מתואר כ”שקול ל-restart אחרי כיבוי פתאומי”.³ כמערכת קבצים היא אינה פגומה, אבל מנקודת המבט של האפליקציה זה “הרגע שבו נשלף החשמל באמצע כתיבה”. מסד נתונים עם מנגנון recovery מ-transaction log יכול לעיתים קרובות להתאושש מזה, אבל עיבוד ה-recovery חייב לרוץ קודם — זו תנאי מוקדם, לא בונוס.

עם שיתוף פעולה של writer, כל writer מגלגל את ה-transaction log ועושה flush ל-caches ממש לפני נקודת העקביות, ומביא את הנתונים למצב consistent שהאפליקציה עצמה מבטיחה שהיא יכולה לשחזר ממנו נכון.¹ זו application-consistent, וזו כל סיבת הקיום של מנגנון ה-writer. מה שכדאי לשים לב אליו הוא שמה ש-writer מבטיח הוא “מצב consistent שניתן לשחזור מבחינת האפליקציה” — הוא אינו מבצע commit ומשלים בשקט transactions שבאוויר בשבילכם. עבודה שלא אושרה מגולגלת לאחור בשחזור, באותו אופן כמו ב-recovery רגיל של מסד נתונים. writer מספק את ערבות האיכות הזו בלי לעצור את האפליקציה, באמצעות freeze של עשרות שניות בלבד.

הסיבה שלתוכנות גיבוי יש הגדרות כמו “השתמש ב-VSS” או “הבטח application consistency” היא בדיוק ההבחן הזה. לקבוצת קבצים רגילה בשרת קבצים, crash-consistent כמעט אף פעם אינו בעיה; אבל בשרת שמארח מסד נתונים או mail store, הבריאות של ה-writer המתאים היא, כשלעצמה, איכות הגיבוי.

5. תפעול VSS ביום-יום — vssadmin ו-Previous Versions

הכלי שאנשי מערכות מידע משתמשים בו בפועל לבדוק את מצב VSS הוא vssadmin (מריצים משורת פקודה מוגבהת). הפניה הנוכחית לפקודות מציגה את list shadows / list writers / delete shadows / resize shadowstorage כזמינים גם בלקוח וגם בשרת.⁴ ההפניה המוכוונת ל-Windows Server מוסיפה בין השאר create shadow / list shadowstorage / list providers.⁵ שימו לב ש-vssadmin יכול לנהל רק shadow copies שנוצרו בידי ה-system provider.¹

אם list writers מציג writer במצב שגיאה, מה שצריך לחשוד בו אינו VSS עצמו אלא האפליקציה שמספקת את ה-writer הזה. בודקים את מצב ה-service של האפליקציה הבעלים ואת Event Log של Application/System (פרק 7).

/maxsize של resize shadowstorage מאפשר לציין את המגבלה עם יחידה כמו KB/MB/GB; משאירים בלי ערך — אין מגבלה כלל. מה שכדאי לשים לב אליו הוא שהתיעוד של Microsoft קובע במפורש ששינוי מגבלת האחסון — הקטנתה בפרט — יכול בעצמו לגרום לאובדן shadow copies.¹⁰ אל תקטינו בקלות ראש את המגבלה ב-volume שבו רוצים לשמור כמה דורות.

5.1. הקשר ל-Previous Versions

הפעלת Shadow Copies of Shared Folders בשרת קבצים שומרת מדי פעם עותקים לרגע מסוים של קבצים בשיתוף, ומאפשרת למשתמשים לשחזר קובץ שמחקו או דרסו מ-Previous Versions בלי עזרת Administrator.¹ זה היישום המוכר ביותר של VSS, ואחד שמצמצם באמינות את עומס הדלפק.

יש מגבלה, עם זאת. shadow copies של ה-system provider מגיעים לכל היותר ל-512 לכל volume, ומתוכם תכונת Shadow Copies of Shared Folders שומרת עד 64 כברירת מחדל (ניתן לשינוי בערך Registry MaxShadowCopies).¹ וכפי שמכוסה מהפרק הבא ואילך, אם ה-diff area מתקצר, הדורות הישנים מוסרים אוטומטית. הבטוח ביותר להבין ש”כמה דורות באמת נשמרים” נקבע לא לפי המספר שהגדרתם, אלא לפי כמה נכתב וגודל ה-diff area.

6. נקודת המבט של המפתח — האם האפליקציה שלכם צריכה VSS?

מכאן ואילך זו נקודת המבט של המפתח. כשמתבקשים “להוסיף יכולת גיבוי שיכולה להעתיק קבצים גם כשהם בשימוש”, איך ניגשים ל-VSS?

6.1. לכתוב requester משלכם זה משימה גדולה

ממשק VSS, גם ל-requesters וגם ל-writers, מסופק כממשקי COM ו-C++ (הליבה של requester היא IVssBackupComponents).⁶ אין wrapper רשמי ל-.NET, וצריך לממש נכון הכול — מאיסוף metadata של writers, דרך ניהול ערכת snapshots, ועד cleanup אחרי שגיאה — כך שאי אפשר פשוט לחבר את זה כתכונה אחת של אפליקציה עסקית. באומדני Custom Software Development אצלנו, “בניית VSS requester” מטופלת כסעיף נפרד.

יש שתי תשובות מציאותיות. ראשית, להשאיר את זה למוצר גיבוי קיים שמודע ל-VSS. שנית, ב-Windows Server, להריץ DiskShadow מסקריפט. DiskShadow הוא VSS requester שמגיע עם ה-OS; מלבד מצב אינטראקטיבי יש לו מצב סקריפט (diskshadow /s script.txt), וסקריפט אחד יכול לכסות יצירת shadow copy, חשיפה כאות כונן (expose), הרצת תהליך אצווה שמבצע את ההעתקה (exec), ו-cleanup אחר כך.⁷¹ אפשר לבנות את הזרימה “צור shadow copy → שלוף ממנו קבצים בלוגיקת ההעתקה שלכם → מחק אותו” בלי לכתוב שורת COM אחת. עם זאת, DiskShadow הוא ל-Windows Server בלבד ואינו כלול במהדורות הלקוח של ה-OS.¹ אם גם מחשבי לקוח נמצאים בהיקף הדרישה, העובדה הזו לבדה מטה את הכף לאימוץ מוצר גיבוי קיים.

6.2. בכלל צריך VSS? — טבלת החלטה

לפי הניסיון שלנו, הרוב הגדול של בקשות “העתקת קובץ שבשימוש” אפשר לפתור בלי VSS. מבררים בדיוק באיזו רמת דרישה מדובר לפני שבוחרים כלי.

6.3. האם האפליקציה שלכם צריכה לרשום writer?

כדאי לחדד גם את השאלה ההפוכה: האם האפליקציה העסקית שלכם צריכה לספק VSS writer? אם כותבים אחד, הנתונים של האפליקציה יגובו כ-application-consistent לא משנה איזה מוצר גיבוי הלקוח משתמש בו. יש גם מנגנון קל יותר מ-writer רגיל, ה-express writer (IVssExpressWriter), אבל כל מה שהוא עושה הוא לרשום הצהרת metadata אילו קבצים לכלול או להחריג.⁶ הוא אינו מקבל התראות freeze/thaw, ולכן אינו יכול להשהות כתיבות של האפליקציה כדי להתיישר עם יצירת ה-snapshot. express writer מתאים רק כשהוא צמוד לתכנון אחסון שאינו נפגם גם אם נתפס באמצע כתיבה (כלומר crash-consistent מספיק); אם באמת צריך תיאום בנקודת העקביות, צריך מימוש writer מלא.

ועם זאת, כלל האצבע להחלטה פשוט.

• אם הנתונים חיים במסד נתונים כמו SQL Server, אין צורך. ה-writer של מסד הנתונים עצמו מבטיח consistency.¹
• לאחסון פשוט מבוסס קבצים, פותרים קודם דרך תכנון שגרת השמירה. אם כותבים לגמרי לקובץ זמני ואז מחליפים ב-rename אטומי, snapshot crash-consistent לעולם לא ישאיר קובץ שמור פגום.
• רישום writer שווה שיקול רק לאפליקציות שמתחזקות מחסן נתונים ייחודי שחוצה כמה קבצים וצריכות consistency הדדית ביניהם בנקודת העקביות. ייתכן ששווה קודם לשקול מחדש אם בכלל נכון להחזיק כמות כזו של נתונים בפורמט ביתי.

7. מלכודות — ארבעה דברים שבאמת נושכים בתפעול

7.1. VSS אינו גיבוי כשלעצמו

זו המלכודת החשובה ביותר. shadow copy של ה-system provider הוא הפרש שיושב על הדיסק של אותו מחשב בדיוק כמו נתוני המקור. אם ה-diff area אובד, אין ממה להרכיב מחדש, ולכן אין כאן שום הגנה מפני תקלת דיסק, גניבה או אובדן של המכונה, או הצפנה של volume שלם. גם התיעוד של Microsoft מבחין בבירור בין shadow copies לגיבויים: “התוכן שהועתק מ-shadow copy אל מדיה כמו סרט הוא הגיבוי, ואת ה-shadow copy עצמו מותר למחוק אחרי שההעתקה הושלמה.”¹ shadow copy הוא נקודת עקביות ודרך מהירה להתאושש מטעות — לא תחליף לגיבוי שנשמר במדיה נפרדת ובאתר נפרד.

7.2. שגיאת writer היא בעיה בצד האפליקציה

כשתוכנת גיבוי נכשלת ב”שגיאת VSS”, מתחילים בזיהוי איזה writer נכשל, עם vssadmin list writers. כי writer הוא, במהותו, רכיב ששייך לאפליקציה (או לרכיב Windows)¹, שדה הקרב העיקרי לחקירת הסיבה הוא מצב ה-service של אותה אפליקציה ו-Event Log שלה. להיסחב אחרי המראה החיצוני של “שגיאה מתוכנת הגיבוי” ולהמשיך לחקור רק את תוכנת הגיבוי מוביל לדרך הארוכה. הדפוס הכללי לצמצום החשודים הוא אותו דפוס שמכוסה ב”כשמקבלים בירושה מערכת בלי קוד מקור ובלי תיעוד — מדריך מעשי להמשך תפעול”: מצמצמים את רשימת החשודים מהעובדות שאפשר באמת לצפות.

7.3. ransomware בא למחוק את ה-shadow copies

זו עובדה שכדאי לדעת כשיקול הגנתי בלבד. מפתה לקוות שאם אפשר לחזור אחורה עם Previous Versions, אפשר להתאושש גם אחרי פגיעת ransomware — אבל ידוע היטב שחלק גדול מתוכנות ransomware מוחקות shadow copies לפני ההצפנה או אחריה, במפורש כדי לסגור את נתיב השחזור הזה. מחיקת shadow copies אפשרית בפקודה לגיטימית לגמרי כל עוד יש הרשאות Administrator, ולכן היא אינה יכולה לשמש קו הגנה אחרון מול תוקף שכבר נכנס. עמודי התווך של מענה הם אפוא: (1) להתייחס ל-shadow copies כאל “נוח אם הם שם” ולא כאל “חלק מתוכנית השחזור”; (2) להחזיק בנפרד גיבוי לא מקוון באתר נפרד שתוקף אינו יכול להגיע אליו; ו-(3) לא לתת הרשאות Administrator לחשבונות של תפעול יומיומי. להגנה לאורך מחזור החיים של המחשב, כולל גיבוי, הצפנה והשלכה, ראו גם “מדריך מעשי ל-BitLocker — הצפנת כונן שמתחילה בניהול מפתח השחזור” ו”מה לעשות לפני שמשליכים מחשב Windows — רשימת בדיקה מעשית למחיקת נתונים, ניתוק חשבונות וגיבויים”.

7.4. כשה-diff area אוזל, הדורות הישנים נעלמים בשקט

כפי שכוסה בפרק 4, copy-on-write צורך את ה-diff area רק כשכל בלוק נכתב מחדש בפעם הראשונה אחרי ה-snapshot. כתיבה מחדש לבלוק שכבר הועבר, כמה פעמים שתרצו, אינה מוסיפה לצריכה, כך שכמה נצרך נקבע לא לפי “כמה כתיבות קרו” אלא לפי “עד כמה רחב טווח הבלוקים שנכתב מחדש מאז ה-snapshot שנשמר.” וברגע שה-diff area מגיע למגבלה, ה-shadow copies של אותו volume נמחקים, מהישן ביותר.¹ למשתמש האינטראקטיבי לא מודיעים דבר, כך שזה לעיתים קרובות עולה רק כש”אמור להיות אפשר לחזור לגרסה של השבוע שעבר” כבר אינו נכון. זה לא לגמרי שקט, עם זאת: System log כן רושם events ממקור volsnap (Event ID 25 כש-shadow copy נמחק כי לא היה אפשר לפנות מקום ל-diff area, 35/36 כשהרחבה נכשלת או מבוטלת אחרי הגעה למגבלה, וכן הלאה). מעבר לבדיקות תקופתיות, הכללת events האלה של volsnap בניטור ובהתראות מאפשרת לתפוס אובדן במהירות. הסיבה שפעולות המוניות ש”סורקות את ה-volume כולו” — עדכוני קבצים המוניים, המרות אצווה, defrag — יכולות לבלוע את ה-diff area בבת אחת נשענת בדיוק על התכונה הזו: הצריכה נקבעת לפי טווח הבלוקים שנכתב מחדש. בודקים באופן קבוע אם מספר הדורות שנשמרים עדיין עומד בדרישה העסקית (“תוך כמה ימים לכל היותר שמים לב למחיקה בטעות?”) מול השימוש שמראה vssadmin list shadowstorage, ומרחיבים את המגבלה אם צריך.⁵¹⁰

8. סיכום

• הסיבה שאי אפשר בדרך כלל להעתיק קובץ שבשימוש היא עניין של sharing violation ו-consistency, וזה המנגנון הנכון להגנה על נתונים. VSS הוא התשובה ברמת ה-OS ל”אני רוצה עותק consistent בלי לעצור את האפליקציה.”
• VSS הוא מסגרת שבה שירות VSS מתווך בין שלושה תפקידים — requester (דורש), writer (מבטיח consistency) ו-provider (יוצר) — ומאפשר לתוכנת גיבוי ולאפליקציות עסקיות שלא יודעות דבר זה על זה לשתף פעולה.
• ה-system provider משתמש ב-copy-on-write, ונקודת עקביות נוצרת דרך “freeze של writers (עד 60 שניות) → יצירה (תוך 10 שניות) → thaw.” בלי שיתוף פעולה של writer מקבלים crash-consistent; איתו, application-consistent.
• בודקים מצב תפעולי ב-vssadmin (list shadows / list writers / list shadowstorage). חושדים בצד האפליקציה בשגיאת writer, ובודקים את השימוש ב-diff area באופן קבוע.
• מפתחים צריכים קודם להשתמש בטבלת ההחלטה ולבדוק אם retries, share modes, חלון עצירה או תכנון שילוב יכולים לפתור את הבעיה, ולפנות ל-VSS רק כשבאמת צריך. סקריפט DiskShadow (Server בלבד) או מוצר קיים הם התשובה המציאותית, לפני מימוש עצמי.
• shadow copy אינו גיבוי. הוא לא יותר מהפרש שתלוי בבלוקים השלמים של ה-volume המקורי; הוא חסר אונים מול אובדן ה-volume המקורי, כמו בתקלת דיסק, ואי אפשר לסמוך עליו מול ransomware, בהתחשב בכך שאפשר למחוק shadow copies או למצות את ה-diff area. משלבים אותו עם גיבוי לא מקוון שנשמר באתר נפרד.

מאמרים קשורים

• ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים — נעילת קבצים ושיטות עבודה מומלצות ל-claim אטומי
• מעמקי ה-I/O של Windows (חלק 4) — Cache Manager: מתי WriteFile שלכם באמת מגיע לדיסק?
• מעמקי ה-I/O של Windows (חלק 5) — פנים NTFS: הבנת מערכת הקבצים דרך ה-MFT
• כשמקבלים בירושה מערכת בלי קוד מקור ובלי תיעוד — מדריך מעשי להמשך תפעול
• מדריך מעשי ל-BitLocker — הצפנת כונן שמתחילה בניהול מפתח השחזור
• מה לעשות לפני שמשליכים מחשב Windows — רשימת בדיקה מעשית למחיקת נתונים, ניתוק חשבונות וגיבויים

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון ובפיתוח אפליקציות עסקיות שכוללות יכולות כמו “העתקת קבצים שבשימוש” וגיבוי, בחקירת שורש של sharing violations סביב העברת קבצים ושל כשלי גיבוי (שגיאות VSS writer), ובסידור מבנה התפעול של גיבויי שרתי קבצים וניהול דורות. אפשר להתחיל משאלת היסוד אם VSS בכלל הדרישה הנכונה.

• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

אם יש shadow copies, האם עדיין צריך גיבויים?

לא, זה לא פוטר מגיבוי. ה-shadow copies שיוצר system provider התקני של Windows הם הפרשי copy-on-write — אין כאן עותק מלא נפרד של ה-volume באותו רגע, אלא תלות בבלוקים של ה-volume המקורי שעדיין לא נכתבו מחדש. גם אם שמים את ה-diff area ב-volume נפרד, האמת נשארת: אם ה-volume המקורי אובד, אי אפשר לשחזר, ואין כאן הגנה מפני אירועים שלוקחים את ה-volume המקורי כולו, כמו תקלת דיסק או גניבה או אובדן של מחשב. אותו דבר ב-ransomware: פעולת הכתיבה בהצפנה אכן מעבירה ל-diff area את הבלוקים שלפני הכתיבה, אבל בהתקפות אמיתיות מוחקים את ה-shadow copies עצמם, או שממלאים את ה-diff area בכתיבות המוניות מחדש, ולכן אי אפשר לסמוך על זה. התיעוד של Microsoft עצמו מבחין בבירור בין השניים: גיבוי הוא הנתונים שהועתקו מ-shadow copy אל מדיה כמו סרט, ואחרי שההעתקה הושלמה מותר למחוק את ה-shadow copy עצמו. shadow copy הוא "צילום מצב לרגע מסוים שממנו לוקחים גיבוי" ו"דרך מהירה להתאושש מטעות קטנה" — לא תחליף לגיבוי שנשמר במדיה נפרדת ובאתר נפרד.

אני רוצה שהאפליקציה העסקית שלי תעתיק קבצים שבשימוש — כדאי להשתמש ב-VSS?

הצעד הראשון המציאותי הוא לחפש דרך שלא תצריך את זה. VSS requesters נכתבים מול API נייטיב מבוסס COM (כמו IVssBackupComponents), ואין wrapper רשמי ל-.NET, כך שהטמעה באפליקציה עצמית היא משימה גדולה. אם הדרישה היא רק "לקרוא בסוף קובץ ש-process אחר כותב אליו", retries מספיקים; אם "האפליקציה האחרת מתירה share לקריאה", פתיחה ב-share mode תואם מספיקה. אם אפשר לעצור את האפליקציה לזמן קצר, ההעתקה בהפסקה טבעית בעבודה היא הפשוטה והאמינה ביותר. VSS נכנס לתמונה רק כשהדרישה היא "לשכפל ערכת נתונים שלמה מאפליקציה שאי אפשר לעצור, במצב consistent" — וגם אז, בודקים קודם מוצר גיבוי קיים שמודע ל-VSS או סקריפט DiskShadow, לפני מימוש עצמי.

vssadmin list writers מציג writer במצב שגיאה. מה לעשות?

הגישה הבסיסית היא לחקור זאת כבעיה בצד האפליקציה שמספקת את ה-writer הזה. vssadmin list writers מציג את ה-writers הרשומים יחד עם מצבם, אז מתחילים בזיהוי איזה writer נכשל. writers מסופקים בידי אפליקציות כמו SQL Server או בידי רכיבי Windows (Registry, למשל), ולכן הסיבה כמעט תמיד נמצאת במצב ה-service של האפליקציה הבעלים, או בשגיאות שנרשמו ב-Event Log של Application/System, ולא ב-VSS עצמו. מפעילים מחדש את ה-service הרלוונטי ומצמצמים את תנאי השחזור; אם זה לא נפתר, בודקים את מידע התמיכה של אותה אפליקציה. זה גם צעד המיון הראשון הנכון כשתוכנת גיבוי נכשלת בשגיאת VSS.

shadow copy נעלם בלי ששמתי לב. למה?

הסיבה הנפוצה ביותר היא שה-diff area (shadow copy storage) נגמר. ב-copy-on-write, תוכן כל בלוק מועבר ל-diff area בפעם הראשונה שהוא נכתב מחדש אחרי ה-snapshot, כך שככל שטווח הבלוקים שנכתבים מחדש רחב יותר, כך נצרך יותר מה-diff area. ברגע שמגיעים למגבלה שהוקצתה, Windows מוחק קודם את ה-shadow copies הישנים ביותר כדי לפנות מקום. זה קורה בשקט, בלי הודעה למשתמש האינטראקטיבי, ולכן מתגלים בדרך כלל כשמישהו מצפה לשחזר מ-Previous Versions את הגרסה של השבוע שעבר ומגלה שהיא איננה (System log כן רושם events כמו Event ID 25 ממקור volsnap, ולכן מעקב אחריהם מאפשר לתפוס את זה). בודקים שימוש ומגבלה עם vssadmin list shadowstorage, ומעלים את המגבלה ב-vssadmin resize shadowstorage אם צריך. חשוב לזכור, עם זאת, ששינוי המגבלה — במיוחד הקטנתה — יכול בעצמו לגרום לאובדן shadow copies.

איך Previous Versions ב-Explorer קשור ל-VSS?

Previous Versions הוא אחד מנקודות הכניסה לשליפת גרסאות עבר של קובץ מ-shadow copy ש-VSS יצר. בשרת קבצים, הפעלת Shadow Copies of Shared Folders גורמת ל-snapshots בלוח זמנים, ומשתמשים יכולים ללחוץ לחיצה ימנית על קובץ בתיקייה משותפת ולשחזר בעצמם מ-Previous Versions. היתרון הוא שמשתמשים יכולים לבטל מחיקה או דריסה בטעות בלי עזרת Administrator. אבל כי מתחתיו יושבים shadow copies, יש תקרה למספר הדורות שנשמרים, ואם ה-diff area מתקצר, הדורות הישנים נעלמים ראשונים. כפי שמפורט בגוף המאמר, "יש לנו Previous Versions" אינו אומר "אין צורך בגיבויים".

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.