עותק צל של כרך (VSS): המנגנון והפרקטיקה — למה תוכנת גיבוי מצליחה להעתיק קבצים שעדיין בשימוש

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

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

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

1. השורה התחתונה קודם

• VSS הוא אוסף ממשקי COM ושירות תיאום שמאפשרים לגבות כרך בזמן שיישום ממשיך לכתוב אליו. הוא בנוי בתוך Windows מאז Windows XP.²
• יש שלושה תפקידים ועוד מתאם. שירות VSS מתווך בין המבקש שדורש עותק צל (תוכנת גיבוי), הכותב שמבטיח עקביות נתונים בצד היישום (SQL Server, למשל), והספק שיוצר בפועל את צילום המצב.¹
• הספק המערכתי התקני של Windows משתמש בהעתקה-בכתיבה. במקום לשכפל את הכרך כולו, הוא מעביר לאזור הפרשים (diff area) רק את הבלוקים שנכתבים מחדש אחרי צילום המצב — ורק את תוכנם שלפני הכתיבה. אזור הפרשים חייב לשבת על כרך NTFS.¹
• נקודת עקביות נוצרת דרך «הקפאת הכותבים (עד 60 שניות) → יצירת צילום המצב (תוך 10 שניות) → הפשרה». אם אחת ממגבלות הזמן חורגת, היצירה מבוטלת והמבקש מנסה שוב.¹
• שיתוף פעולה של כותב משנה את איכות ההעתקה. צילום מצב בלי שיתוף פעולה של כותב שקול ל«הדיסק ברגע שבו נשלף החשמל» (עקביות קריסה); צילום עם שיתוף פעולה כבר גלגל יומנים ושטף מטמונים, והשאיר מצב עקבי שהיישום עצמו מבטיח שניתן לשחזור (עקביות יישום).³¹
• vssadmin הוא הכלי לבדיקת מצב תפעולי. משתמשים ב-list shadows / list writers / list shadowstorage לראות את המצב הנוכחי, וב-resize shadowstorage לכוונן את מגבלת אזור הפרשים. כשאזור הפרשים אוזל, עותקי הצל הישנים ביותר נמחקים בשקט.⁴⁵¹
• הטמעת מבקש VSS ביישום עצמי היא משימה גדולה. זה ממשק נייטיב מבוסס COM, בלי עטיפה רשמית ל-.NET. ברוב המקרים ניסיונות חוזרים, כוונון מצב שיתוף, או עצירה קצרה מספיקים; אם באמת צריך VSS, סקריפט DiskShadow הוא התשובה המעשית (Windows Server בלבד).⁶⁷
• עותק צל אינו גיבוי כשלעצמו. כי הפרש ההעתקה-בכתיבה תלוי בבלוקים השלמים של הכרך המקורי, הוא חסר אונים מול כשל שלוקח את הכרך המקורי כולו, כמו תקלת דיסק או גניבה. גם מול כופרה אי אפשר לסמוך עליו, כי אפשר למחוק את עותקי הצל עצמם (פרק 7.3) או למצות את אזור הפרשים בכתיבות המוניות מחדש (פרק 7.4). הוא מקבל משמעות רק כשמשלבים אותו עם גיבויים במדיה נפרדת.¹

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

נקודת המוצא היא מצב שיתוף הקבצים של Windows. כשפותחים קובץ ב-Windows (CreateFile), מכריזים, כמצב שיתוף (dwShareMode), מה יורשה לתהליכים אחרים לעשות בזמן שהוא פתוח אצלכם. כל עוד תהליך מחזיק את הקובץ פתוח באופן שלא מתיר שיתוף קריאה, כל תהליך שמנסה אחר כך לפתוח אותו לקריאה נכשל בהפרת שיתוף (ERROR_SHARING_VIOLATION, שגיאה 32).⁸ ב-.NET זו ה-IOException המוכרת («התהליך אינו יכול לגשת לקובץ משום שהקובץ נמצא בשימוש על ידי תהליך אחר»).

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

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

• קיר הפרת השיתוף: קובץ שמסד נתונים או יישום עסקי מחזיק פתוח אולי בכלל לא ייפתח כמקור להעתקה.
• קיר העקביות: גם אם אפשר לפתוח (כי שיתוף קריאה מותר), ההעתקה לוקחת זמן. כי היישום ממשיך לכתוב בזמן ההעתקה, החצי הראשון והחצי השני של הקובץ יכולים לשקף רגעים שונים, או כמה קבצים (קובץ הנתונים והיומן, למשל) יכולים לצאת מתיאום זה עם זה. וכפי שראינו בפרק «Cache Manager», כתיבה נוחתת קודם במטמון שבזיכרון, כך שמבט רק על הקובץ בדיסק אינו מבטיח שרואים את התוכן העדכני.
• קיר התפעול: «אז פשוט עוצרים את היישום ומעתיקים» היא תשובה סבירה עקרונית, אבל אינה מתקבלת במערכת עסקית או בשרת קבצים שעובדים מסביב לשעון.

כלומר, מה שבעצם רוצים הוא «עותק של רגע עקבי אחד, בלי לעצור את היישום.» זה יותר מדי ליישומים בודדים לפתור לבד, ולכן VSS נבנה כמנגנון ברמת מערכת ההפעלה. VSS מוצע כמסגרת ממשקי COM שמאפשרת לגבות כרך גם בזמן שיישום ממשיך לכתוב אליו.²

3. צוות הדמויות של VSS — מבקש, כותב, ספק

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

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

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

4. איך צילומי מצב עובדים — העתקה-בכתיבה ו«נקודת העקביות»

4.1. העתקה-בכתיבה — לשמור את «הרגע ההוא» בלי לשכפל את הכרך

שמיעת המילה «צילום מצב» גורמת לדמיין שכפול של הכרך כולו, אבל השיטה שהספק המערכתי התקני של Windows באמת משתמש בה היא העתקה-בכתיבה (copy-on-write). ברגע צילום המצב כמעט לא מועתק דבר. אחר כך, כשבלוק בכרך המקורי עומד להיכתב מחדש, תוכן הבלוק שלפני הכתיבה מועבר לאזור הפרשים (diff area, אחסון עותקי הצל) לפני שהכתיבה מחדש מסתיימת, ורק אז הכתיבה מורשית לעבור.¹ ההעברה צריכה לקרות רק בפעם הראשונה שכל בלוק נכתב מחדש; כתיבה מחדש לבלוק שכבר הועבר אינה מגדילה עוד את אזור הפרשים.

כדי לקרוא את «הכרך כפי שהיה באותו רגע», הבלוקים שלא השתנו נקראים מהכרך המקורי, והבלוקים שהשתנו נקראים מאזור הפרשים, ושניהם מורכבים יחד. כי מועתק רק החלק שהשתנה, היצירה מיידית והמקום שנצרך הוא רק ההפרש. הצד השני הוא שכרך שנכתב אליו בכבדות צורך את אזור הפרשים מהר יותר (רמז לפרק 7), ואזור הפרשים יושב על כרך NTFS באותו מחשב כמו נתוני המקור.¹ מה שמחזיק את המנגנון הזה הוא קובץ הרכיב של הספק המערכתי, swprv.dll, ומנהל ההתקן שמיירט את הקלט/פלט של כרך, volsnap.sys.¹ אם מעניין אתכם ה«איך» של יירוט מחסנית הקלט/פלט, ראו גם «מנהלי מסנן ו-Minifilter».

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

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

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

flowchart TB
    accTitle: זרימת יצירת עותק הצל
    accDescr: זרימת יצירת עותק הצל. מה שנעצר בפועל הוא רק שניות ספורות עד עשרות שניות; הגיבוי עצמו רץ מול צילום המצב אחר כך
    R["המבקש דורש יצירה<br/>מונה כותבים ואוסף מטא־נתונים"] --> M["כל כותב מצהיר על יעדי הגיבוי<br/>(רכיבים) ב-XML"]
    M --> P["כל כותב מכין את הנתונים<br/>גלגול יומנים, שטיפת מטמון וכדומה<br/>למצב עקבי שניתן לשחזור"]
    P --> F["הקפאת קלט/פלט כתיבה של הכותבים<br/>(קריאה אפשרית. עד 60 שניות)"]
    F --> FS["VSS שוטף את מאגרי מערכת הקבצים<br/>ומקפיא את מערכת הקבצים"]
    FS --> C["הספק יוצר את עותק הצל<br/>(תוך 10 שניות. קלט/פלט כתיבה נשאר מוקפא)"]
    C --> T["שחרור מערכת הקבצים → הפשרת הכותבים (thaw)<br/>היישום חוזר לכתוב"]
    T --> B["המבקש מריץ את הגיבוי מעותק הצל<br/>במשך הזמן הנדרש"]

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

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

1. היישום נעצר רק לרגע שבו נוצרת נקודת העקביות. ההקפאה מוגבלת ל-60 שניות, והיצירה (ה-commit) בידי הספק מוגבלת ל-10 שניות; חורגים מאחת מהן — היצירה מבוטלת והמבקש מנסה שוב.¹ הגיבוי עצמו, שיכול לקחת שעות, רץ מול עותק הצל המוכן לקריאה בלבד בזמן שהיישום ממשיך לרוץ.
2. קריאה עדיין אפשרית בזמן ההקפאה. רק קלט/פלט כתיבה נעצר.¹
3. גם מערכת הקבצים מוקפאת. כי VSS שוטף את מאגרי מערכת הקבצים לפני ההקפאה, כתיבות שישבו במטמון, ומטא־נתונים של מערכת הקבצים, משתקפים בצילום המצב בסדר עקבי.¹

4.3. עקביות קריסה ועקביות יישום

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

עותק צל שנוצר בלי שיתוף פעולה של כותב נמצא במה שמינוח Microsoft קורא מצב עקביות קריסה (crash consistent). ההגדרה הרשמית היא «מצב דיסק השקול למצב שהיה נמצא אחרי כשל הרסני שסוגר את המערכת בפתאומיות», והשחזור ממנו מתואר כ«שקול לאתחול אחרי כיבוי פתאומי».³ כמערכת קבצים היא אינה פגומה, אבל מנקודת המבט של היישום זה «הרגע שבו נשלף החשמל באמצע כתיבה». מסד נתונים עם מנגנון שחזור מיומן טרנזקציות יכול לעיתים קרובות להתאושש מזה, אבל עיבוד השחזור חייב לרוץ קודם — זו תנאי מוקדם, לא בונוס.

עם שיתוף פעולה של כותב, כל כותב מגלגל את יומן הטרנזקציות ושוטף את המטמונים ממש לפני נקודת העקביות, ומביא את הנתונים למצב עקבי שהיישום עצמו מבטיח שהוא יכול לשחזר ממנו נכון.¹ זו עקביות יישום, וזו כל סיבת הקיום של מנגנון הכותב. מה שכדאי לשים לב אליו הוא שמה שכותב מבטיח הוא «מצב עקבי שניתן לשחזור מבחינת היישום» — הוא אינו מבצע commit ומשלים בשקט טרנזקציות שבאוויר בשבילכם. עבודה שלא אושרה מגולגלת לאחור בשחזור, באותו אופן כמו בשחזור רגיל של מסד נתונים. כותב מספק את ערבות האיכות הזו בלי לעצור את היישום, באמצעות הקפאה של עשרות שניות בלבד.

הסיבה שלתוכנות גיבוי יש הגדרות כמו «השתמש ב-VSS» או «הבטח עקביות יישום» היא בדיוק ההבחן הזה. לקבוצת קבצים רגילה בשרת קבצים, עקביות קריסה כמעט אף פעם אינה בעיה; אבל בשרת שמארח מסד נתונים או מאגר דואר, הבריאות של הכותב המתאים היא, כשלעצמה, איכות הגיבוי.

5. תפעול VSS ביום-יום — vssadmin ו«גירסאות קודמות»

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

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

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

5.1. הקשר ל«גירסאות קודמות»

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

יש מגבלה, עם זאת. עותקי צל של הספק המערכתי מגיעים לכל היותר ל-512 לכל כרך, ומתוכם תכונת עותקי הצל של תיקיות משותפות שומרת עד 64 כברירת מחדל (ניתן לשינוי בערך הרישום MaxShadowCopies).¹ וכפי שמכוסה מהפרק הבא ואילך, אם אזור הפרשים מתקצר, הדורות הישנים מוסרים אוטומטית. הבטוח ביותר להבין ש«כמה דורות באמת נשמרים» נקבע לא לפי המספר שהגדרתם, אלא לפי כמה נכתב וגודל אזור הפרשים.

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

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

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

ממשק VSS, גם למבקשים וגם לכותבים, מסופק כממשקי COM ו-C++ (הליבה של מבקש היא IVssBackupComponents).⁶ אין עטיפה רשמית ל-.NET, וצריך לממש נכון הכול — מאיסוף מטא־נתונים של כותבים, דרך ניהול ערכת צילומי המצב, ועד ניקוי אחרי שגיאה — כך שאי אפשר פשוט לחבר את זה כתכונה אחת של יישום עסקי. באומדני פיתוח בחוזה אצלנו, «בניית מבקש VSS» מטופלת כסעיף נפרד.

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

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

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

6.3. האם היישום שלכם צריך לרשום כותב?

כדאי לחדד גם את השאלה ההפוכה: האם היישום העסקי שלכם צריך לספק כותב VSS? אם כותבים אחד, הנתונים של היישום יגובו בעקביות יישום לא משנה איזה מוצר גיבוי הלקוח משתמש בו. יש גם מנגנון קל יותר מכותב רגיל, הכותב express (IVssExpressWriter), אבל כל מה שהוא עושה הוא לרשום הצהרת מטא־נתונים אילו קבצים לכלול או להחריג.⁶ הוא אינו מקבל התראות הקפאה/הפשרה, ולכן אינו יכול להשהות כתיבות של היישום כדי להתיישר עם יצירת צילום המצב. כותב express מתאים רק כשהוא צמוד לתכנון אחסון שאינו נפגם גם אם נתפס באמצע כתיבה (כלומר עקביות קריסה מספיקה); אם באמת צריך תיאום בנקודת העקביות, צריך מימוש כותב מלא.

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

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

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

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

זו המלכודת החשובה ביותר. עותק צל של הספק המערכתי הוא הפרש שיושב על הדיסק של אותו מחשב בדיוק כמו נתוני המקור. אם אזור הפרשים אובד, אין ממה להרכיב מחדש, ולכן אין כאן שום הגנה מפני תקלת דיסק, גניבה או אובדן של המכונה, או הצפנה של כרך שלם. גם התיעוד של Microsoft מבחין בבירור בין עותקי צל לגיבויים: «התוכן שהועתק מעותק צל אל מדיה כמו סרט הוא הגיבוי, ואת עותק הצל עצמו מותר למחוק אחרי שההעתקה הושלמה.»¹ עותק צל הוא נקודת עקביות ודרך מהירה להתאושש מטעות — לא תחליף לגיבוי שנשמר במדיה נפרדת ובאתר נפרד.

7.2. שגיאת כותב היא בעיה בצד היישום

כשתוכנת גיבוי נכשלת ב«שגיאת VSS», מתחילים בזיהוי איזה כותב נכשל, עם vssadmin list writers. כי כותב הוא, במהותו, רכיב ששייך ליישום (או לרכיב Windows)¹, שדה הקרב העיקרי לחקירת הסיבה הוא מצב השירות של אותו יישום ויומני האירועים שלו. להיסחב אחרי המראה החיצוני של «שגיאה מתוכנת הגיבוי» ולהמשיך לחקור רק את תוכנת הגיבוי מוביל לדרך הארוכה. הדפוס הכללי לצמצום החשודים הוא אותו דפוס שמכוסה ב«כשמקבלים בירושה מערכת בלי קוד מקור ובלי תיעוד — מדריך מעשי להמשך תפעול»: מצמצמים את רשימת החשודים מהעובדות שאפשר באמת לצפות.

7.3. כופרה באה למחוק את עותקי הצל

זו עובדה שכדאי לדעת כשיקול הגנתי בלבד. מפתה לקוות שאם אפשר לחזור אחורה עם «גירסאות קודמות», אפשר להתאושש גם אחרי פגיעת כופרה — אבל ידוע היטב שחלק גדול מתוכנות הכופרה מוחקות עותקי צל לפני ההצפנה או אחריה, במפורש כדי לסגור את נתיב השחזור הזה. מחיקת עותקי צל אפשרית בפקודה לגיטימית לגמרי כל עוד יש הרשאות מנהל, ולכן היא אינה יכולה לשמש קו הגנה אחרון מול תוקף שכבר נכנס. עמודי התווך של מענה הם אפוא: (1) להתייחס לעותקי צל כאל «נוח אם הם שם» ולא כאל «חלק מתוכנית השחזור»; (2) להחזיק בנפרד גיבוי לא מקוון באתר נפרד שתוקף אינו יכול להגיע אליו; ו-(3) לא לתת הרשאות מנהל לחשבונות של תפעול יומיומי. להגנה לאורך מחזור החיים של המחשב, כולל גיבוי, הצפנה והשלכה, ראו גם «מדריך מעשי ל-BitLocker — הצפנת כונן שמתחילה בניהול מפתח השחזור» ו«מה לעשות לפני שמשליכים מחשב Windows — רשימת בדיקה מעשית למחיקת נתונים, ניתוק חשבונות וגיבויים».

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

כפי שכוסה בפרק 4, העתקה-בכתיבה צורכת את אזור הפרשים רק כשכל בלוק נכתב מחדש בפעם הראשונה אחרי צילום המצב. כתיבה מחדש לבלוק שכבר הועבר, כמה פעמים שתרצו, אינה מוסיפה לצריכה, כך שכמה נצרך נקבע לא לפי «כמה כתיבות קרו» אלא לפי «עד כמה רחב טווח הבלוקים שנכתב מחדש מאז צילום המצב שנשמר.» וברגע שאזור הפרשים מגיע למגבלה, עותקי הצל של אותו כרך נמחקים, מהישן ביותר.¹ למשתמש האינטראקטיבי לא מודיעים דבר, כך שזה לעיתים קרובות עולה רק כש«אמור להיות אפשר לחזור לגירסה של השבוע שעבר» כבר אינו נכון. זה לא לגמרי שקט, עם זאת: יומן System כן רושם אירועים ממקור volsnap (מזהה אירוע 25 כשעותק נמחק כי לא היה אפשר לפנות מקום לאזור הפרשים, 35/36 כשהרחבה נכשלת או מבוטלת אחרי הגעה למגבלה, וכן הלאה). מעבר לבדיקות תקופתיות, הכללת אירועי volsnap האלה בניטור ובהתראות מאפשרת לתפוס אובדן במהירות. הסיבה שפעולות המוניות ש«סורקות את הכרך כולו» — עדכוני קבצים המוניים, המרות אצווה, איחוי — יכולות לבלוע את אזור הפרשים בבת אחת נשענת בדיוק על התכונה הזו: הצריכה נקבעת לפי טווח הבלוקים שנכתב מחדש. בודקים באופן קבוע אם מספר הדורות שנשמרים עדיין עומד בדרישה העסקית («תוך כמה ימים לכל היותר שמים לב למחיקה בטעות?») מול השימוש שמראה vssadmin list shadowstorage, ומרחיבים את המגבלה אם צריך.⁵¹⁰

8. סיכום

• הסיבה שאי אפשר בדרך כלל להעתיק קובץ שבשימוש היא עניין של הפרות שיתוף ועקביות, וזה המנגנון הנכון להגנה על נתונים. VSS הוא התשובה ברמת מערכת ההפעלה ל«אני רוצה עותק עקבי בלי לעצור את היישום.»
• VSS הוא מסגרת שבה שירות VSS מתווך בין שלושה תפקידים — מבקש (דורש), כותב (מבטיח עקביות) וספק (יוצר) — ומאפשר לתוכנת גיבוי וליישומים עסקיים שלא יודעים דבר זה על זה לשתף פעולה.
• הספק המערכתי משתמש בהעתקה-בכתיבה, ונקודת עקביות נוצרת דרך «הקפאת הכותבים (עד 60 שניות) → יצירה (תוך 10 שניות) → הפשרה.» בלי שיתוף פעולה של כותב מקבלים עקביות קריסה; איתו, עקביות יישום.
• בודקים מצב תפעולי ב-vssadmin (list shadows / list writers / list shadowstorage). חושדים בצד היישום בשגיאת כותב, ובודקים את השימוש באזור הפרשים באופן קבוע.
• מפתחים צריכים קודם להשתמש בטבלת ההחלטה ולבדוק אם ניסיונות חוזרים, מצבי שיתוף, חלון עצירה או תכנון שילוב יכולים לפתור את הבעיה, ולפנות ל-VSS רק כשבאמת צריך. סקריפט DiskShadow (שרת בלבד) או מוצר קיים הם התשובה המציאותית, לפני מימוש עצמי.
• עותק צל אינו גיבוי. הוא לא יותר מהפרש שתלוי בבלוקים השלמים של הכרך המקורי; הוא חסר אונים מול אובדן הכרך המקורי, כמו בתקלת דיסק, ואי אפשר לסמוך עליו מול כופרה, בהתחשב בכך שאפשר למחוק עותקי צל או למצות את אזור הפרשים. משלבים אותו עם גיבוי לא מקוון שנשמר באתר נפרד.

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

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

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

KomuraSoft LLC מטפלת בתכנון ובפיתוח יישומים עסקיים שכוללים יכולות כמו «העתקת קבצים שבשימוש» וגיבוי, בחקירת שורש של הפרות שיתוף סביב העברת קבצים ושל כשלי גיבוי (שגיאות כותב VSS), ובסידור מבנה התפעול של גיבויי שרתי קבצים וניהול דורות. אפשר להתחיל משאלת היסוד אם VSS בכלל הדרישה הנכונה.

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

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

אם יש עותקי צל, האם עדיין צריך גיבויים?

לא, זה לא פוטר מגיבוי. עותקי הצל שיוצר הספק המערכתי התקני של Windows הם הפרשי העתקה-בכתיבה — אין כאן עותק מלא נפרד של הכרך באותו רגע, אלא תלות בבלוקים של הכרך המקורי שעדיין לא נכתבו מחדש. גם אם שמים את אזור הפרשים (diff area) בכרך נפרד, האמת נשארת: אם הכרך המקורי אובד, אי אפשר לשחזר, ואין כאן הגנה מפני אירועים שלוקחים את הכרך המקורי כולו, כמו תקלת דיסק או גניבה או אובדן של מחשב. אותו דבר בכופרה: פעולת הכתיבה בהצפנה אכן מעבירה לאזור הפרשים את הבלוקים שלפני הכתיבה, אבל בהתקפות אמיתיות מוחקים את עותקי הצל עצמם, או שממלאים את אזור הפרשים בכתיבות המוניות מחדש, ולכן אי אפשר לסמוך על זה. התיעוד של Microsoft עצמו מבחין בבירור בין השניים: גיבוי הוא הנתונים שהועתקו מעותק צל אל מדיה כמו סרט, ואחרי שההעתקה הושלמה מותר למחוק את עותק הצל עצמו. עותק צל הוא «צילום מצב לרגע מסוים שממנו לוקחים גיבוי» ו«דרך מהירה להתאושש מטעות קטנה» — לא תחליף לגיבוי שנשמר במדיה נפרדת ובאתר נפרד.

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

הצעד הראשון המציאותי הוא לחפש דרך שלא תצריך את זה. מבקשי VSS נכתבים מול ממשק נייטיב מבוסס COM (כמו IVssBackupComponents), ואין עטיפה רשמית ל-.NET, כך שהטמעה ביישום עצמי היא משימה גדולה. אם הדרישה היא רק «לקרוא בסוף קובץ שתהליך אחר כותב אליו», ניסיונות חוזרים מספיקים; אם «היישום האחר מתיר שיתוף קריאה», פתיחה במצב שיתוף תואם מספיקה. אם אפשר לעצור את היישום לזמן קצר, ההעתקה בהפסקה טבעית בעבודה היא הפשוטה והאמינה ביותר. VSS נכנס לתמונה רק כשהדרישה היא «לשכפל ערכת נתונים שלמה מיישום שאי אפשר לעצור, במצב עקבי» — וגם אז, בודקים קודם מוצר גיבוי קיים שמודע ל-VSS או סקריפט DiskShadow, לפני מימוש עצמי.

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

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

עותק צל נעלם בלי ששמתי לב. למה?

הסיבה הנפוצה ביותר היא שאזור הפרשים (אחסון עותקי הצל) נגמר. בהעתקה-בכתיבה, תוכן כל בלוק מועבר לאזור הפרשים בפעם הראשונה שהוא נכתב מחדש אחרי צילום המצב, כך שככל שטווח הבלוקים שנכתבים מחדש רחב יותר, כך נצרך יותר מאזור הפרשים. ברגע שמגיעים למגבלה שהוקצתה, Windows מוחק קודם את עותקי הצל הישנים ביותר כדי לפנות מקום. זה קורה בשקט, בלי הודעה למשתמש האינטראקטיבי, ולכן מתגלים בדרך כלל כשמישהו מצפה לשחזר מ«גירסאות קודמות» את הגירסה של השבוע שעבר ומגלה שהיא איננה (יומן System כן רושם אירועים כמו מזהה אירוע 25 ממקור volsnap, ולכן מעקב אחריהם מאפשר לתפוס את זה). בודקים שימוש ומגבלה עם vssadmin list shadowstorage, ומעלים את המגבלה ב-vssadmin resize shadowstorage אם צריך. חשוב לזכור, עם זאת, ששינוי המגבלה — במיוחד הקטנתה — יכול בעצמו לגרום לאובדן עותקי צל.

איך «גירסאות קודמות» בסייר הקבצים קשור ל-VSS?

«גירסאות קודמות» הוא אחד מנקודות הכניסה לשליפת גירסאות עבר של קובץ מעותק צל ש-VSS יצר. בשרת קבצים, הפעלת «עותקי צל של תיקיות משותפות» (Shadow Copies of Shared Folders) גורמת לצילומי מצב בלוח זמנים, ומשתמשים יכולים ללחוץ לחיצה ימנית על קובץ בתיקייה משותפת ולשחזר בעצמם מ«גירסאות קודמות». היתרון הוא שמשתמשים יכולים לבטל מחיקה או דריסה בטעות בלי עזרת מנהל. אבל כי מתחתיו יושבים עותקי צל, יש תקרה למספר הדורות שנשמרים, ואם אזור הפרשים מתקצר, הדורות הישנים נעלמים ראשונים. כפי שמפורט בגוף המאמר, «יש לנו גירסאות קודמות» אינו אומר «אין צורך בגיבויים».

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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