בקצרה: Time Machine מתוכנן למחוק גיבויים ישנים. השעתיים שורדים יום, היומיים שורדים חודש, והשבועיים שורדים עד שהדיסק מתמלא. ואז הישנים ביותר הולכים.
אין לזה הגדרה. אי אפשר להגיד ל-Time Machine לשמור שלוש שנים, והמנוף היחיד שיש לכם הוא גודל הדיסק.
זו התנהגות מתועדת והיא לא השתנתה שנים:
אז הגיל של הגיבוי הישן ביותר שלכם נקבע לפי דבר אחד: בכמה דיסק הגיבוי גדול מהנתונים ב-Mac, וכמה הנתונים האלה משתנים. כונן של 1 TB שמחזיק 900 GB של Mac נותן לכם שבועות. אותו כונן שמחזיק 200 GB נותן לכם שנים. אף אחד לא אומר לכם מה יש לכם.
זו שלמעלה. לפעמים תראו במרכז העדכונים "Time Machine מחק כמה גיבויים ישנים יותר כדי לפנות מקום", ובאותה תדירות לא תראו כלום, כי קל לפספס את ההודעה וקל שהיא כבויה.
בדקו מה באמת שורד:
tmutil listbackupsזה מדפיס כל גיבוי ביעד המחובר, מהישן לחדש. קראו את התאריכים בצד ו צורת התזמון נראית: רצף של גיבויים יומיים בסוף, שבועיים לפני כן, ותאריך התחלה שעונה עד כמה רחוק אפשר לחזור.
לפעמים Time Machine נוטש את ההיסטוריה הקיימת ומתחיל מחדש. שדרוג macOS, כרך שתוקן, מזהה דיסק ששונה, או אינדקס גיבוי פגום יכולים כולם לגרום לזה. הגיבויים הישנים עשויים עדיין להיות בדיסק ולתפוס מקום בזמן שאי אפשר להגיע אליהם מממשק השחזור.
tmutil listbackups מול היעד מראה מה עדיין נגיש. אם הרשומה הישנה ביותר בת כמה ימים בכונן שאתם משתמשים בו שנתיים, זה מה שקרה.
ב-Mac עם APFS, Time Machine שומר גם תמונות מצב בדיסק הפנימי, כך שאפשר לשחזר משהו כשכונן הגיבוי לא מחובר. הן נשמרות בערך 24 שעות ונמחקות אוטומטית כשצריך מקום.
tmutil listlocalsnapshots /אנשים מוצאים אותן, מניחים שהן הגיבוי, ואז מגלים שהן נעלמו. הן נמצאות באותו דיסק כמו המקור, כך שכונן שכשל לוקח את שתיהן. שימושיות לטעות שתשימו לב אליה היום אחר הצהריים. לא גיבוי.
ביעד רשת כל ההיסטוריה שלכם נמצאת בתוך sparse bundle אחד. עצות באינטרנט על בעיות גיבוי נגמרות לעיתים קרובות מאוד ב"מחקו את ה-sparsebundle והתחילו מחדש", וזה מוחק כל גרסה שהייתה לכם בפעולה אחת. לשגיאות תמונת הדיסק יש תיקונים שלא כרוכים בזה, ושווה לנסות אותם קודם.
בכנות, מעט מאוד.
מה שאי אפשר לעשות הוא להגדיר מדיניות שמירה. לא מספר ימים, לא מספר מינימלי של גרסאות, לא "שמור את הגיבוי הראשון של כל חודש לתמיד". לוח הזמנים בראש הדף הזה הוא כל הממשק.
זה נועד לגרום לדיסק בגודל קבוע להחזיק מעמד, וזו תשובה סבירה לכך. הבעיה היא שהמדיניות בלתי נראית בזמן שהיא רצה. היום שבו אתם מחפשים את הגרסה של קובץ משמונה חודשים אחורה הוא היום שבו אתם לומדים כמה אחורה הדיסק שלכם באמת מגיע, ואז התשובה כבר קבועה.
גרסאות ישנות נשארות עד שתחליטו אחרת. אין מונה שזורק אותן אחרי שלושים יום ואין לוח זמנים שמדלל אותן מאחורי הגב שלכם.
כשהמקום כן אוזל, האפליקציה שואלת, והיא אומרת לכם מה היא הייתה מסירה וכמה זה מפנה לפני שמשהו קורה. התוכנית נקבעת קודם ומבוצעת מאוחר יותר, כך שטעות בכלל נשארת ניתנת לשחזור במשך שבוע.
המסך הראשי מראה כמה אחורה ההיסטוריה מגיעה, וזה המספר שכל הדף הזה עוסק בו. ושחזור הגיבוי החדש ביותר חינמי בכל שכבה, גם אחרי שרישיון מסתיים, כך שהיסטוריה היא נוחות שמשלמים עליה וקבלת הקבצים בחזרה היא לא.
אם אתם נשארים עם Time Machine, הדבר המועיל לעשות היום הוא להריץ tmutil listbackups, להסתכל על התאריך הראשון, ולהחליט אם זה מספיק אחורה בשבילכם. כלל 3-2-1 מכסה את החצי השני של השאלה, כלומר מה קורה כשהדיסק האחד שמחזיק את הכול נכשל.
לא. אין הגדרה, אין פקודת defaults ששורדת, ואין דרך נתמכת לנעוץ גיבוי. המנופים היחידים הם גודל הדיסק, כמה אתם מגבים, ושימוש ביותר מיעד אחד.
הריצו tmutil listbackups כשהכונן מחובר. השורה הראשונה היא הגיבוי הישן ביותר שעדיין אפשר לשחזר ממנו. התאריך הזה, ולא גיל הכונן, קובע עד כמה רחוק ההיסטוריה שלכם מגיעה.
כן, זו ההתנהגות המתוכננת: הגיבויים הישנים ביותר נמחקים כדי לפנות מקום לחדש ביותר. כדאי גם לבדוק אם הדיסק מלא, כי ההודעה על חוסר מקום נוגעת לעיתים קרובות לאופן שבו הוא מעריך את גודל העבודה, ולא למקום הפנוי.
לא. הן נמצאות באותו דיסק כמו הקבצים שמהם הגיעו, הן נשמרות בערך יום, והן נמחקות כשהמערכת רוצה מקום. הן מכסות מחיקה בטעות היום אחר הצהריים ותו לא.
עדכון יכול לבטל את תוקף אינדקס הגיבוי ולהתחיל שרשרת חדשה. הנתונים הישנים לרוב עדיין בדיסק בזמן שאי אפשר להגיע אליהם מממשק השחזור. tmutil listbackups אומר לכם מה עדיין נגיש, ואם התשובה היא רק הימים האחרונים, השרשרת התחילה מחדש.
קשור: Time Machine אומר שאין מספיק מקום, כלל 3-2-1, והשוואה בין Copy Shelter ל-Time Machine.