לדלג לתוכן

שיעור 07: גיבוי ושחזור

**חלק א': מאגר ידע למדריך **

1. Snapshots (תמונות מצב): איך פועל הגיבוי המקומי ב-APFS (Rollbacks)

תיאוריה והיסטוריה (High-Level Theory & History)

בימים שלפני הכנסת מערכת הקבצים המודרנית של אפל, APFS (Apple File System), גיבויים מקומיים נוהלו על ידי מנגנון בתוך Time Machine שנקרא "Mobile Time Machine". תכונה זו תוכננה בעיקר עבור משתמשי MacBook שהיו מנותקים לעתים קרובות מכונני הגיבוי החיצוניים הראשיים שלהם. המערכת פעלה על גבי מערכת הקבצים הישנה יותר HFS+ (Mac OS Extended), וסימלה מצבי זמן (Point-in-time) על ידי הסתמכות על Directory Hard Links (קישורים קשיחים לתיקיות). הארכיטקטורה הישנה הזו הייתה כבדה ומסורבלת באופן יוצא דופן, ודרשה כ-10,000 שורות קוד ייעודיות רק כדי להערים על מערכת הקבצים כדי להציג מה שנראה כמו תמונת מצב סטטית.

עם המעבר הארכיטקטוני הגורף ל-APFS החל מ-macOS High Sierra, הגישה הפרימיטיבית והשברירית הזו הוצאה לחלוטין משימוש (Deprecated) והוחלפה על ידי תמונות מצב אמיתיות - APFS Snapshots. תמונת מצב (Snapshot) היא הקפאה מיידית לקריאה-בלבד (Read-only) של מצב מערכת הקבצים על ווליום ספציפי, באלפית השנייה המדויקת. היתרון העמוק ביותר של APFS Snapshot על פני איטרציות קודמות הוא מהירות ויעילות היצירה שלו: לוקח תרתי משמע שבריר שנייה כדי לצלם Snapshot. הסיבה לכך היא שיצירת תמונת המצב דורשת אפס העתקת נתונים או שכפול קבצים. המערכת פשוט רושמת את המצב הנוכחי של המטא-דאטה (Metadata) של מערכת הקבצים.

[!TIP] הערת הדרכה לדור הישן: כאשר מסבירים זאת לצוותי IT ותיקים, הזכירו להם את הימים של Carbon Copy Cloner על HFS+ ואת השבריריות הקיצונית של Directory Hard Links. קישור קשיח פגום ב-HFS+ יכול היה להרוס בקלות את שלמות הגיבוי. APFS עוקפת לחלוטין את הסיכון הזה על ידי פעולה ברמת הבלוקים והמטא-דאטה.

ארכיטקטורה טכנית (Deep Technical Architecture)

כדי להבין באמת את העוצמה של APFS Snapshots, יש להבין את המנגנון הבסיסי של APFS: פעולת העתקה-בעת-כתיבה (Copy-on-Write - CoW).

כאשר נוצר APFS Snapshot, מערכת ההפעלה נועלת את המצביעים (הידועים כ-Extents) שממפים לבלוקים הפיזיים של הנתונים על הכונן. מאותו רגע והלאה, אם משתמש מנסה לשנות או למחוק קובץ, APFS לא באמת דורסת את הבלוקים הפיזיים המכילים את הנתונים של אותו קובץ. במקום זאת, הודות לארכיטקטורת Copy-on-Write, ה-APFS כותבת את הנתונים שהשתנו לאחרונה לבלוקים פנויים וזמינים לחלוטין במקום אחר בכונן, ולאחר מכן מעדכנת את הקטלוג הפעיל של מערכת הקבצים להצביע על הבלוקים החדשים.

בינתיים, הבלוקים הישנים המכילים את הנתונים המקוריים נשמרים בדיוק כפי שהיו, לחלוטין בגלל שה-Snapshot עדיין שומר מצביע פעיל אליהם. משמעות ארכיטקטורה זו היא ש-APFS Snapshot צורך כמעט אפס בתים של שטח דיסק ברגע המדויק של יצירתו. עם זאת, כאשר המשתמש ממשיך להשתמש באופן פעיל ב-Mac שלו - משנה מסמכים, מוחק סרטונים ישנים, מוריד אפליקציות חדשות - "הדלתא" (ההבדל בין המצב החי הנוכחי לבין מצב ה-Snapshot המוקפא) גדלה. הקבצים המקוריים שנמחקו או שונו נשמרים בחיים על ידי תמונת המצב, שמונעת את סימון הבלוקים הללו כשטח פנוי. כתוצאה מכך, שמירת תמונות מצב לפרקי זמן ממושכים עלולה בסופו של דבר לצרוך כמויות עצומות של שטח אחסון נסתר ב-Data Volume.

חשוב מאוד לציין ש-Snapshots שוכנים בתוך אותו APFS Container בדיוק כמו ה-Data Volume. כשמוחקים תמונת מצב, המערכת מפנה באופן מיידי את הבלוקים שהיא הגנה עליהם, ומחזירה מיד את שטח האחסון לשימוש. בנוסף, ה-System Volume של macOS (נקרא SSV - Sealed System Volume) מבודד לחלוטין מנתוני משתמש (User Data). הוא משתמש ב-Snapshot החתום קריפטוגרפית משלו עבור ה-Root Filesystem, כלומר, תמונות מצב שנוזמו על ידי המשתמש חלות אך ורק על ה-Data Volume, היכן שמידע המשתמש באמת שוכן.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

עבור מנהלי IT ומשתמשים מתקדמים, הטרמינל (Terminal) מספק שליטה פרטנית על Local Snapshots:

  • כדי ליזום יצירה מיידית וידנית של תמונת מצב מקומית: tmutil localsnapshot

  • כדי לרשום את כל תמונות המצב הקיימות ב-Data Volume (באמצעות מסגרת ה-APFS ברמה נמוכה יותר): diskutil apfs listSnapshots /System/Volumes/Data

  • כדי להציג רשימה מסודרת של תמונות מצב מקומיות המנוהלות על ידי Time Machine: tmutil listlocalsnapshots /

  • כדי למחוק באופן יזום תמונות מצב מקומיות במקרה של דלדול חמור בשטח האחסון: tmutil thinlocalsnapshots / 10000000000 4 (המספר הראשון מייצג את כמות שטח הבתים הרצויה לפינוי—10GB בדוגמה זו—והמספר האחרון '4' מייצג את הרמה הגבוהה ביותר של דחיפות).

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

תופעת הדיסק המלא "באופן מסתורי": תרחיש תמיכה קלאסי (Helpdesk) מערב משתמש שמקבל אזהרת "Disk Almost Full". בתגובה, הוא מוחק קובצי וידאו כבדים בנפח 100GB, מרוקן את פח האשפה, ונדהמ לגלות שהשטח הפנוי לא גדל אפילו בבייט אחד. זה קורה מכיוון ש-Local Snapshot פעיל עדיין מצביע על ה-Extents של אותם קבצי וידאו שנמחקו, ומגן עליהם מפני מחיקה אמיתית. הפתרון הוא למחוק את תמונות המצב באופן ידני באמצעות הפקודה tmutil thinlocalsnapshots או פשוט להמליץ למשתמש להמתין, שכן macOS מבצעת בדרך כלל ניקוי אוטומטי (ניהול Purgeable Space) בתוך 24 שעות.

התפצלות חד-כיוונית ב-Rollback (Rollback): כאשר משתמש נתקל בבעיית נתונים קטסטרופלית, הוא עשוי להיכנס ל-1TR (מצב Recovery Mode) ולהשתמש בכלי "Restore from Time Machine" כדי לבצע Rollback מערכת מלא באמצעות Local Snapshot. פעולה זו מחזירה את כל ה-Data Volume לאותה שנייה היסטורית מדויקת. עם זאת, Edge Case קריטי שיש לזכור הוא ש-APFS Rollback הוא רחוב חד-כיווני. ברגע שאתם מבצעים Rollback, אתם יוצרים "פיצול" (Fork) בציר הזמן של מערכת הקבצים. כל ה-Snapshots שצולמו לאחר יעד זמן ה-Rollback מחוסלים לחלוטין ומיידית. אין כפתור "ביטול" (Undo) ל-Rollback.

2. Time Machine: לוגיקת הגיבוי למקור חיצון

תיאוריה והיסטוריה (High-Level Theory & History)

ה-Time Machine הוצגה לעולם לראשונה ב-26 באוקטובר 2007, יחד עם Mac OS X Leopard. באותה תקופה, אפל זיהתה פגיעות אדירה בשוק הצרכני והמקצועי: אף אחד לא גיבה את הנתונים שלו. פתרונות צד-שלישי שהיו זמינים, כמו Retrospect של Dantz Development, התאפיינו בעקומות למידה תלולות, פרדיגמות מפותלות של כונני קלטות (Tape Drives) ותזמונים מורכבים שהרתיעו משתמשים ממוצעים. Time Machine עשתה דמוקרטיזציה לגיבויים בכך שסיפקה ממשק חלל (Cosmic) אינטואיטיבי שסימל את ה-Finder, ואפשר למשתמשים ממש לטוס אחורה בזמן.

בתחילה, במערכת הקבצים HFS+, פעלה Time Machine באמצעות רשת סבוכה של Directory Hard Links. המשמעות היא שכל גיבוי שעתי נראה כמו עותק מלא ושלם של הכונן הקשיח, אבל הוא היה למעשה מגדל קלפים העשוי מקיצורי דרך (Aliases) המצביעים למופע פיזי יחיד של קובץ. כאשר אפל עברה ל-APFS ב-macOS Big Sur וגרסאות מאוחרות יותר (כולל Sonoma, Sequoia ו-Tahoe), הקצה האחורי (Backend) של Time Machine נכתב מחדש לחלוטין. Time Machine המודרני מסתמך אך ורק על העברות מ-APFS ל-APFS, ומבטל Hard Links לחלוטין לטובת Synthetic Snapshots מהירים כברק על יעד הגיבוי החיצוני.

ארכיטקטורה טכנית (Deep Technical Architecture)

מחזור החיים המודרני של ה-Time Machine פועל באמצעות תהליך אוטומטי מתוחכם ביותר ורב-שלבי:

  1. תזמון DAS-CTS: במערכות macOS מודרניות (Sequoia ו-Tahoe), הגיבויים מתוזמנים ומשוגרים על ידי מנגנון ה-DAS-CTS (ראשי תיבות: Duet Activity Scheduler ו-Centralized Task Scheduling). זה מבטיח שהגיבויים יפעלו מדי שעה אך ייכנעו לעומסי עבודה כבדים בחזית (Foreground Workloads), וימנעו מה-Mac לקרטע במהלך משימות אינטנסיביות כמו רינדור וידאו.
  2. אימות מצב וביצועים: לפני העברת בייט בודד, Time Machine מעריך את מצב החשמל של ה-Mac ומבצע מבחן ביצועי I/O קצר ביעד הגיבוי החיצוני (APFS) כדי לאמוד את כדאיות ההעברה.
  3. שאילתת FSEvents Database: כדי לקבוע בדיוק מה השתנה, Time Machine מבצע שאילתה למסד הנתונים FSEvents (File System Events). בסיס נתונים זה רושם כל שינוי בכונן, ומאפשר ל-Time Machine להימנע מסריקת הכונן הקשיח כולו.
  4. Local Anchor Snapshot: ה-Time Machine לוקח תמונת מצב מקומית זמנית על ה-Data Volume הפנימי כדי לשמש כנקודת עיגון სტטית (Anchor) לגיבוי.
  5. Delta-Copying (העתקת דלתא): מנגנון ה-Time Machine מבצע "Delta-Copying" לתיקייה נסתרת בשם .inprogress בכונן החיצוני. במקום להעתיק קבצים גדולים שלמים ששונו רק מעט (כמו בסיס נתונים ענק), הוא מעתיק רק את בלוקי ה-APFS הספציפיים שהשתנו.
  6. יצירת Synthetic Snapshot: לאחר סיום העברת הדלתא, Time Machine בונה תמונת מצב סינתטית (Synthetic Snapshot) בכונן ה-APFS החיצוני, ומרכיב את הבלוקים החדשים ואת ההפניות לבלוקים הישנים לכדי ייצוג מושלם של ה-Mac.
  7. מערכת שני השלבים (macOS Tahoe): ב-macOS Tahoe, גיבויים עשויים להתבצע ברצף "דו-שלבי" (Two-pass). השלב הראשון מתרחש כאשר המכשיר אינו נעול (Unlocked), ומאבטח את נתוני המשתמש במהירות. שלב משני יכול להתרחש כאשר המכשיר נעול (Locked), ומושך פריטי מערכת אבטחה עמוקים או פריטי רקע שלא היו נגישים קודם לכן.
  8. ננעצות (Pinning) של iCloud Drive (תכונה ב-Sequoia/Tahoe): מבחינה היסטורית, התכונה "Optimise Mac Storage" הייתה סיוט עבור Time Machine, שכן קבצים שפונו (Evicted) לענן דולגו במהלך הגיבוי. ב-macOS Sequoia ו-Tahoe, משתמשים יכולים ללחוץ לחיצה ימנית ולבצע "Pin" (הורדה קבועה / Keep Downloaded) לקבצים או לתיקיות שלמות. קבצים נעוצים (Pinned) מובטחים להישאר בדיסק המקומי ולכן נכללים באופן קפדני בגיבוי הבלוקים של Time Machine.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

לאבחון מתקדם וניהול IT:

  • כדי לבדוק את המצב החי של גיבוי Time Machine שרץ כעת: tmutil status

  • כדי לאלץ גיבוי להתחיל באופן מיידי ולחסום את הטרמינל עד להשלמתו (מצוין עבור סקריפטים של הטמעה): tmutil startbackup --block

  • כדי לחלץ לוגים פרטניים לגבי התנהגות Time Machine: log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 4h

  • מיקום ה-Plist של הגדרות: /Library/Preferences/com.apple.TimeMachine.plist

[!TIP] T2M2 (The Time Machine Mechanic): למדריכים ומשתמשים מתקדמים, ניווט במערכת הלוגים המאוחדת (Unified Logging System) עבור בעיות Time Machine עלול להיות מאיים. תוכלו להמליץ על כלי החינם T2M2 מאת Howard Oakley, אשר מנתח באופן אוטומטי לוגים אלו כדי לחשוף עיכובים של מנגנון DAS-CTS, סריקות עמוקות (Deep Traversal Scans) ומדדי העתקת דלתא בפורמט קריא מאוד.

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

קריסת בסיס הנתונים FSEvents (Deep Traversal Scan): בנסיבות רגילות, חישוב הדלתא לוקח שניות. עם זאת, אם ה-Mac חווה קריסת קרנל (Kernel Panic) או אובדן כוח חזק ולא מבוקר, ייתכן שבסיס הנתונים FSEvents ייפגם. בניסיון הגיבוי הבא, Time Machine מבינה שהיא אינה יכולה לסמוך על בסיס הנתונים ונאלצת לבצע "סריקה עמוקה" (Deep Traversal Scan). היא תשווה באופן ידני כל קובץ בודד בדיסק הפנימי מול תמונת המצב החיצונית. תהליך זה יכול לקחת שעות רבות, במהלכן הממשק הגרפי יציג בעקשנות "Preparing Backup". יש להדריך את המשתמשים לגלות סבלנות קיצונית; הפרעה לתהליך זה רק תאלץ אותו להתחיל מחדש.

הגיבויים הראשוניים האיטיים במיוחד ברשת SMB NAS: ניסיון לבצע את הגיבוי המלא הראשון של Time Machine דרך חיבור Wi-Fi להתקן אחסון רשת SMB (NAS - Network Attached Storage) הוא איטי עד מאוד. התקורה של משא ומתן בפרוטוקול SMB עבור מיליוני קבצים קטנטנים יכולה למתוח את הגיבוי הראשוני למספר ימים. הדרך המומלצת היא תמיד לבצע את הגיבוי הראשוני דרך חיבור Ethernet קווי. גיבויי הדלתא הבאים יכולים להתבצע בנוחות באמצעות Wi-Fi.

3. שחזור קבצים: חילוץ קבצים ספציפיים או שחזור מערכת כולל

תיאוריה והיסטוריה (High-Level Theory & History)

המעבר הארכיטקטוני ל-APFS ול-System Volume החתום קריפטוגרפית (SSV) שינה מן היסוד את המושג של "שחזור מערכת מלא" (Full System Restore). בתקופת macOS Monterey ומוקדם יותר, שחזור של Mac פירושו היה לקחת את מערכת ההפעלה כולה, בתוספת נתוני המשתמש, מהכונן החיצוני ולדרוס את הכונן הפנימי. כיום, מערכת ההפעלה עצמה חתומה קריפטוגרפית ובלתי ניתנת לשינוי (Immutable). לא ניתן "לשחזר" את מערכת ההפעלה מגיבוי של Time Machine; ניתן לשחזר רק את ה-Data Volume. המטרה הכפולה של Time Machine נותרת בעינה: חילוץ פרטני של קובץ בודד שנמחק בטעות, והתאוששות מלאה מאסון (Disaster Recovery).

ארכיטקטורה טכנית (Deep Technical Architecture)

חילוץ קובץ ספציפי (Specific File Extraction): כאשר המשתמש נכנס לממשק הגרפי של Time Machine כדי לשחזר מסמך ספציפי שנמחק, macOS עוגנת (Mount) בשקט את תמונת המצב ההיסטורית (Synthetic Snapshot) מהכונן החיצוני בתור כונן Read-Only ברקע. לאחר מכן היא פשוט מעתיקה את הקובץ המבוקש מתוך תמונת המצב שעוגנה בחזרה אל תוך ה-Data Volume החי של המשתמש.

התאוששות מאסון (Full System Restore): אם הלוח-אם הפנימי של ה-Mac הוחלף או שהכונן נמחק לחלוטין, הפרוטוקול הנכון שונה בתכלית מבעבר:

  1. המשתמש חייב קודם לאתחל את המחשב לתוך 1TR (Recovery Mode) או להשתמש בקובץ IPSW דרך Apple Configurator כדי להתקין מערכת הפעלה (macOS) חדשה, חתומה ונקייה מהמפעל.
  2. באתחול הראשון, במהלך ה-Setup Assistant, המשתמש מקבל הודעה מ-Migration Assistant.
  3. עוזר ההגירה (Migration Assistant) מתחבר לכונן ה-Time Machine, קורא את ה-Synthetic Snapshot העדכני ביותר, ומחלץ אך ורק את תוכן ה-Data Volume (פרופילי משתמש, הגדרות, יישומים).

ארכיטקטורה זו מבטיחה שה-Mac מאתחל עם מערכת הפעלה נקייה מנוזקות (Malware) וצלילה קריפטוגרפית (Cryptographically sound), תוך כדי השתלת הנתונים ההיסטוריים של המשתמש מעליה בצורה שקופה.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

לשחזור אוטומטי או נטול ממשק גרפי (Headless) של קבצים ספציפיים באמצעות ה-CLI: tmutil restore /Volumes/TimeMachineDisk/Backups.backupdb/.../User/Documents/File.txt ~/Documents/

הכלי הגרפי הראשי (GUI) לשחזור המוני ממוקם ב: /System/Applications/Utilities/Migration Assistant.app

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

התנגשות שם חשבון ב-Migration Assistant: שגיאה שכיחה מתרחשת כאשר משתמש קונה Mac חדש, מדלג על ה-Migration Assistant במהלך ההגדרה הראשונית (Setup Assistant), יוצר חשבון מקומי עם שם המשתמש "admin" או "john", ורק לאחר מכן מנסה להפעיל את ה-Migration Assistant מתוך גיבוי שמכיל גם הוא את שם המשתמש "john". זה גורם להתנגשות אדירה, ומאלץ את המשתמש לשנות את שם החשבון הנכנס או לדרוס את החשבון הפעיל, מה שגורם פעמים רבות לסיוט של הרשאות. חוק הברזל הוא: תמיד יש להגר במהלך ה-Setup Assistant הראשוני, או ליצור חשבון זמני חלופי (Dummy account) עם שם שונה לחלוטין אם מהגרים לאחר מכן.

FileVault ושוויון הצפנה חיצוני: הנתונים השוכנים ב-Local Snapshots על הכונן הפנימי של ה-Mac מוגנים באופן מובנה על ידי הצפנת ה-FileVault הפנימית של ה-Mac. עם זאת, כאשר Time Machine מייצא את הנתונים האלו לכונן חיצוני, זה קריטי שהווליום החיצוני (APFS) יפורמט במפורש כ-APFS (Encrypted). אם משתמש ילחץ בעיוורון על המסכים (Next-Next) במהלך ההתקנה וישתמש בווליום לא מוצפן, הנתונים המאובטחים בצורה יפהפייה מה-Mac שלו ייכתבו בטקסט גלוי (Plain Text) על כונן נייד שיכול בקלות להיגנב מתרמיל, מה שמהווה פרצת אבטחת מידע קטסטרופלית.

4. תיבול ארגוני: האם בכלל צריך Time Machine בסביבה ארגונית מנוהלת ענן (OneDrive/Google Drive)?

תיאוריה והיסטוריה (High-Level Theory & History)

בנוף הארגוני המודרני, המאופיין בארכיטקטורת Zero-Trust ופריסת Zero-Touch, נקודת הקצה הפיזית (ה-Mac) נחשבת ל-"Ephemeral" (בת-חלוף). מדובר בזכוכית זמנית המשמשת לגישה לנתונים עסקיים. הפרדיגמה המסורתית שבה מוסרים לכל עובד כונן USB חיצוני ומתפללים שהוא יזכור לחבר אותו לצורך גיבויי Time Machine נחשבת לארכאית, בלתי ניתנת לניהול וסיכון אבטחה חמור.

במקום זאת, מחלקות ה-IT המודרניות מחייבות שימוש בפתרונות סנכרון ענן (Cloud Sync) כגון Microsoft OneDrive, Google Drive או Box כדי להזרים נתונים ברציפות לענן. אם עובד שופך קפה על ה-Mac שלו, פרוטוקול ה-IT אינו לחטט ולחפש כונן Time Machine; אלא הוא להנפיק פקודת מחיקה מלאה מרוחקת (Erase All Content and Settings - EACS), למסור לעובד Mac חדש מהניילונים, לאפשר למערכת ההרשמה האוטומטית למכשירים (Automated Device Enrollment - ADE) להגדיר אותו, ולבקש מהעובד להיכנס לחשבון הענן שלו. תוך שלושים דקות, הם חוזרים לעבוד. כתוצאה מכך, Time Machine נאסרת לרוב ומושבתת כליל בצי המחשבים הארגוני.

ארכיטקטורה טכנית (Deep Technical Architecture)

החיכוך בין Time Machine לבין ספקי ה-Cloud Sync נובע מהארכיטקטורות המנוגדות שלהם מיסודן. ספקי ענן במערכות macOS מודרניות משתמשים במסגרת העבודה של אפל, FileProvider Framework. מסגרת זו מאפשרת לשירותי ענן לייצג טרה-בייטים של נתונים ארגוניים כ-"Dataless files" (קבצים ללא נתונים או קבצים דלילים) ב-Finder. הקובץ נראה כאילו הוא שם, אבל הוא צורך אפס בתים; הנתונים נמשכים מהענן רק "לפי דרישה" (On-Demand) כאשר המשתמש לוחץ עליהם פעמיים (Double-click).

מכונת הזמן (Time Machine), לעומת זאת, פועלת ברמת הבלוק הפיזי ורוצה לגבות את המצב הפיזי המדויק של הכונן. אם Time Machine מנסה לגבות תיקייה המנוהלת על ידי FileProvider, היא עשויה לעורר אירוע הורדה המוני (Mass-download event). Time Machine יבקש בכוח את הבלוקים הפיזיים עבור כל קובץ שחסר, כדי שתוכל לכתוב אותם לכונן הגיבוי החיצוני. הדבר יגרום ל-Mac לנסות להוריד טרה-בייטים של נתונים מ-OneDrive בבת אחת, מה שיהרוס את רוחב הפס של הרשת הארגונית וימלא מיידית את הכונן הקשיח הפנימי עד ל-100% קיבולת.

פקודות מסוף והגדרות (Terminal Commands, Plists & Logs)

על מנת לאכוף את חסימת השימוש ב-Time Machine, מנהל ה-IT יפרוס פרופיל תצורה של MDM (Configuration Profile) המשתמש בפיילואד com.apple.MCX.TimeMachine שבו המפתח הבא מוגדר כדי לחסום זאת: 

<key>restrictTimeMachine</key>
<true/>
זה מסיר לחלוטין את היכולת של המשתמש להגדיר או להפעיל גיבויים מקומיים.

לפתרון בעיות (Troubleshooting) של FileProvider כאשר הסנכרון לענן נתקע: fileproviderctl dump

מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)

משתמשים כבדים (היוצא מן הכלל לחוק הענן): בעוד שסנכרון ענן עובד בצורה חלקה עבור מחלקות שיווק ומשאבי אנוש (HR), הוא נכשל עבור עורכי וידאו, טכנאי שמע ומפתחי תוכנה העובדים עם מאגרים (Repositories) מקומיים עצומים המשתנים במהירות (לדוגמה, ספריות Final Cut Pro או Docker Containers). המשתמשים הללו אינם יכולים לחכות שקובץ של 50GB יועלה ל-OneDrive בכל פעם שהם מבצעים עריכה. במקרי קצה אלה, סביבת ה-IT חייבת לספק פתרון גיבוי ברמת הבלוק (Block-level). בתרחישים ספציפיים אלה, פוליסות ה-MDM יאפשרו במפורש Time Machine למשתמשים ויכוונו לכונן רשת NAS מהיר באמצעות חיבור 10GbE מקומי, או על ידי ניצול של סוכני גיבוי Endpoint ארגוניים מתקדמים כמו Code42 (או CrashPlan).

סכנת הנעילה ב-Sync Lock ב-FileProvider: הסכנה העיקרית של הסתמכות אך ורק על ה-FileProvider (והשבתת Time Machine) היא ה-"Sync Lock". לעיתים, המנוע של OneDrive או של Google Drive עלול לקרוס או להיתקע, מה שישאיר קובץ שנשמר מקומית על המק (Locally) שעדיין לא סונכרן לענן (Unsynced). מכיוון שה-Time Machine מושבת, שום Local Snapshot לא נוצר כדי להגן על הקובץ. אם המשתמש מוחק בטעות את הקובץ במהלך פער סנכרון זה, הקובץ מושמד לחלוטין. אין תמונת מצב מקומית (Snapshot) שיכולה להציל אותו, והוא מעולם לא הגיע לענן. זוהי הפשרה המקובלת, אם כי מלחיצה לעתים, של אסטרטגיית המכשיר בר-החלוף (Ephemeral Device) מבוסס הענן בלבד.

[!IMPORTANT] הערה למדריך: הדגישו בכיתה שלמרות ש-Time Machine היא טכנולוגיה צרכנית גאונית, הרלוונטיות שלה ב-Enterprise (בארגונים גדולים) היא מאוד תלוית מצב (Situational). המעבר לשיטות עבודה (Workflows) מבוססות ענן מייצג את העתיד של ניהול ה-Mac בארגון.