בקצרה: ביעד רשת Time Machine לא מעתיק קבצים לשיתוף. הוא יוצר תמונת דיסק גדולה אחת בשיתוף ומעתיק לתוכה. כל שגיאה במשפחה הזו קשורה לתמונה: אי אפשר ליצור אותה, אי אפשר לפתוח אותה, או שמשהו עדיין מחזיק אותה פתוחה.
אף אחת מהן לא אומרת שהגיבויים הקיימים שלכם נעלמו. מחיקת הכונן כמעט אף פעם לא הפתרון, וזו העצה שתמצאו הכי הרבה.
Time Machine צריך תכונות של מערכת קבצים ששיתוף רשת לא מציע: קישורים קשיחים, בעלות שהוא שולט בה, ויכולת לנעול קובץ בזמן שהוא עובד עליו. NAS שמדבר SMB לא יכול להבטיח אותן.
אז בכל יעד רשת Time Machine יוצר sparse bundle, תיקייה שמסתיימת ב-.sparsebundle ומתנהגת כמו תמונת דיסק. הוא מעגן את התמונה, והגיבוי נמצא בתוכה על מערכת קבצים ש-Time Machine שולט בה לגמרי. השיתוף צריך רק להחזיק תיקייה של מקטעים ממוספרים שנקראים bands.
בגלל זה לגיבוי רשת יש קטגוריה שלמה של כשלים שאין לכונן מחובר. שני דברים יכולים להשתבש היכן שלכונן מחובר יש אחד, וההודעה שמקבלים עוסקת בדרך כלל בתמונה.
Time Machine ניסה ליצור את ה-sparse bundle והשיתוף סירב. עברו על אלה לפי הסדר.
fruit:time machine = yes בהגדרת השיתוף. בלעדיה, macOS עשויה להתחבר בשמחה ועדיין לסרב ליצור את התמונה.התמונה קיימת ו-macOS לא הצליחה לחבר אותה. שגיאה 45 היא שגיאת נעילת קובץ, כך שהסיבה הרגילה היא שמשהו כבר מחזיק את התמונה פתוחה.
token או קובץ .lock ברמה העליונה. מחיקתם בטוחה כששום דבר לא מעגן את התמונה, והם נוצרים מחדש בעיגון הבא. ודאו קודם שהתמונה לא מעוגנת, אחרת תשחיתו אותה.אותה סיבה, בניסוח פשוט יותר, ואותם ארבעה שלבים מנקים אותה. לפני כל דבר אחר, חפשו בסרגל הצד של Finder כרך מעוגן שנקרא על שם ה-Mac שלכם, כי התשובה הנפוצה ביותר היא שהוא מעוגן ממש עכשיו במחשב שאתם יושבים מולו.
בדרך כלל השיתוף נעלם באמצע גיבוי, בגלל שינה, Wi-Fi, או NAS שאותחל לעדכון. בדקו אם השיתוף מתחבר מחדש, ואז בדקו את התמונה עם שלב האימות שלמטה לפני שסומכים על מה שיש בה.
גיבוי רשת שנקטע יכול להשאיר את התמונה לא עקבית מבפנים בזמן שכל הודעה על המסך נראית בסדר. עגנו אותה ושאלו את המערכת:
hdiutil attach -readonly /Volumes/<share>/<YourMac>.sparsebundlediskutil verifyVolume /Volumes/<the volume it mounted>לקריאה בלבד, כך ששום דבר לא משתנה מההסתכלות. אם האימות מדווח על שגיאות, הריצו diskutil repairVolume על אותו כרך. אם התיקון נכשל, התמונה הזו גמורה, והצעד הכן הוא להתחיל עליה שרשרת גיבוי חדשה ולהפסיק לסמוך על מה שיש בישנה.
כל אחת מהשגיאות האלה היא תכונה של תמונת הדיסק, ותמונת הדיסק קיימת כי היעד נמצא ברשת. לגיבוי שכותב קבצים רגילים לתיקייה רגילה אין שום דבר מזה: אין תמונה שנכשלת ביצירה, אין נעילה שמתיישנת, אין אובייקט גדול יחיד שהשחתה שלו לוקחת איתה כל גיבוי שבתוכו בבת אחת.
הנקודה האחרונה היא זו ששווה להתעכב עליה. כל היסטוריית ה-Time Machine שלכם ב-NAS נמצאת בתוך sparse bundle אחד. זה אובייקט אחד. נזק במקום הלא נכון לוקח את הכול.
היא כותבת תיקייה של קבצים רגילים לשיתוף, כך שאין תמונת דיסק, אין נעילה, ואין אובייקט יחיד שמחזיק כל גרסה שיש לכם. שיתוף שנעלם באמצע גיבוי מדווח כיעד שלא נגיש, עם התאריך שבו נראה לאחרונה, והגיבוי הבא ממשיך מהמקום שבו הקודם נעצר.
כל חלק נשמר תחת ה-hash של התוכן שלו ונקרא בחזרה מול ה-hash הזה לפי לוח זמנים, כך שנזק בכל מקום בשרשרת מזוהה וממוקם ביום שלישי רגיל. גיבוי Mac ל-NAS מכסה את ההגדרה, כולל התנהגות הזמן הקצוב שקובעת אם שיתוף ישן הוא שגיאה או היעדרות.
אפשר, וזה זורק כל גיבוי שבתוכה, כי כולם נמצאים בתמונה האחת הזו. נסו קודם את ארבעת השלבים שלמעלה. מחיקה היא התשובה רק כש-diskutil repairVolume כבר נכשל עליה.
כי אין תמונת דיסק. כונן שמחובר ישירות מקבל מערכת קבצים משלו ש־Time Machine מפרמט ושולט בה, כך שהוא לא צריך תמונה ואין לו נעילה שיכולה להתיישן. זה הטיעון החזק ביותר לשמירת עותק מקומי אחד.
תמיכה בזה והפעלה של זה בשיתוף הספציפי הן הגדרות שונות ברוב תוכנות ה-NAS. בדקו את השיתוף, לא את דף המוצר. מכסות הן הסיבה הנפוצה האחרת: התמונה מצהירה על גודל מקסימלי ביצירתה, ומכסה קטנה יותר דוחה אותה.
כשלעצמה, לא. היא אומרת ש-macOS לא הצליחה לנעול את התמונה, כך ששום דבר לא נכתב. מה שמסוכן הוא רצף ארוך שלהן שאף אחד לא שם לב אליו, כי הגיבוי התקין האחרון ממשיך להתיישן בזמן שהכול נראה רגיל.
לא. היא כותבת קבצים רגילים לתיקייה בשיתוף, ולכן אף אחת מהשגיאות בדף הזה לא קיימת אצלה. הפשרה היא שהשיתוף צריך להיות נגיש כדי להיספר, והאפליקציה אומרת זאת כשהוא לא.
קשור: גיבוי Mac ל-NAS, Time Machine אומר שאין מספיק מקום, ואיך לאמת גיבוי.