Chapter 7: גיבויים ושחזור מקומי (Time Machine & Snapshots) - Asset A (Instructor Ref)¶

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

High-Level Theory & History¶

לפני המעבר ל-APFS, מנגנון Time Machine ייצר מעין גיבוי מקומי שנקרא Mobile Time Machine שעבד על גבי HFS+ דרך יצירת Hard Links. עם המעבר ל-APFS, טכנולוגיה זו הוחלפה לחלוטין על ידי APFS Snapshots (Snapshots). Snapshot היא הקפאה רגעית לקריאה-בלבד (Read-Only) של כל מערכת הקבצים של ה-Volume באותו שבריר שנייה בו היא נוצרה. היתרון הגדול ביותר של Snapshot הוא המהירות - היצירה שלו אורכת חלקיק שנייה מכיוון שאינה דורשת העתקה של קבצים, אלא רק רישום של המטא-דאטה (Metadata) של ה-Volume באותו רגע.

Deep Technical Architecture¶

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

Terminal Commands, Plists & Logs¶

ליצירת Snapshot מקומי באופן ידני: tmutil localsnapshot

לרשימת כל ה-Snapshots הקיימים על ה-Data Volume (דרך מערכת APFS): diskutil apfs listSnapshots /System/Volumes/Data

להצגת רשימת Snapshots של Time Machine: tmutil listlocalsnapshots /

למחיקת כל ה-Snapshots המקומיים במקרה של מצוקת מקום: tmutil thinlocalsnapshots / 10000000000 4 (המספרים מציינים את נפח המקום הרצוי לפינוי בבתים, ורמת הדחיפות בין 1 ל-4).

Edge Cases & Troubleshooting¶

נפח דיסק מתמלא באופן מסתורי: משתמשים מוחקים קבצי וידאו ענקיים ומתלוננים שהמקום לא התפנה. הסיבה לכך היא שה-Snapshot עדיין מצביע לבלוקים של הוידאו. הפתרון הוא למחוק את ה-Snapshots בעזרת tmutil או לאפשר למערכת לנקות אותם אוטומטית (לרוב אחרי 24 שעות). Rollback ב-Recovery Mode (חד-כיווני): כשמבצעים שחזור מערכת כולל ל-Snapshot דרך ה-Recovery Mode (על ידי כניסה ל-Time Machine System Restore ובחירת ה-Macintosh HD), התהליך מחזיר את כל ה-Data Volume לאותו רגע. תופעת הלוואי (Edge Case) הקריטית היא שמדובר בפעולה בלתי-הפיכה שיוצרת התפצלות במערכת הקבצים (Fork). לאחר ה-Rollback, כל ה-Snapshots המאוחרים יותר שהיו קיימים נמחקים אוטומטית ולא ניתן לחזור קדימה או להגיע אליהם.

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

High-Level Theory & History¶

מערכת Time Machine הוצגה לראשונה ב-2007 (OS X Leopard) כמהפכה בתחום הגיבויים. הרעיון היה לייצר אשליה של חלון Finder המאפשר לטייל אחורה בזמן בין תיקיות הגיבוי. בימים של HFS+, הדבר נעשה על ידי Directory Hard Links - יצירת מצביעים לתיקיות כך שכל "גיבוי יומי" היה למעשה אוסף של קיצורי דרך לקבצים שלא השתנו, ורק קבצים חדשים הועתקו פיזית. החל מ-macOS Big Sur ועם הבשלת APFS, הארכיטקטורה נכתבה מחדש לחלוטין. כעת Time Machine מגבה אל כונני APFS בלבד, משתמש ב-Synthetic Snapshots ואינו משתמש עוד ב-Hard Links כלל.

Deep Technical Architecture¶

התהליך המודרני של Time Machine עובד בצורה הבאה:

המערכת קוראת את בסיס הנתונים FSEvents (File System Events) כדי לדעת אילו קבצים השתנו מאז הגיבוי האחרון.
נוצר Local Snapshot על ה-Data Volume המקומי. זהו העוגן.
המערכת משתמשת בטכניקת Delta-Copying כדי להעתיק רק את הבלוקים שהשתנו (ולא קבצים שלמים מחדש) אל כונן הגיבוי החיצוני, אל תוך תיקיית .inprogress.
בסיום ההעתקה, Time Machine בונה Synthetic Snapshot על כונן הגיבוי (שכעת מפורמט כ-APFS) שמייצג את מצב המערכת במדויק. ה-System Volume (SSV) כלל לא מגובה יותר ב-Time Machine, מכיוון שהוא חתום קריפטוגרפית (Sealed) ואינו מכיל דאטה של המשתמש. Time Machine מגבה אך ורק את ה-Data Volume. בנוסף, מנגנון ה-Thinning (Age-based ו-Space-based) מוחק אוטומטית גיבויים ישנים כשהכונן מתמלא, תוך שמירה על היררכיית זמן (גיבוי יומי, שבועי, חודשי).

Terminal Commands, Plists & Logs¶

לקבלת סטטוס גיבוי נוכחי: tmutil status

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

לחקירת הלוגים והבנת סיבות לכישלון גיבוי, יש לפנות ל-Unified Logging System: log show --predicate 'subsystem == "com.apple.TimeMachine"' --info --last 4h

הגדרות Time Machine נשמרות בקובץ ה-Plist הבא: /Library/Preferences/com.apple.TimeMachine.plist

Edge Cases & Troubleshooting¶

קריסת FSEvents Database: במקרים חריגים שבהם בסיס הנתונים של ה-FSEvents נפגם (לדוגמה לאחר קריסת קרנל או Hard Reboot), Time Machine לא ידע מה השתנה ויאלץ לבצע Deep Traversal Scan (סריקה עמוקה וידנית של כל מערכת הקבצים). תהליך זה אורך שעות ארוכות וגורם למשתמשים לחשוב שהגיבוי נתקע בשלב ה-"Preparing Backup". הפתרון הוא פשוט להמתין. הגיבוי לוקח הרבה זמן. חיבור NAS איטי: העתקה ל-Time Machine על גבי Wi-Fi (פרוטוקול SMB אל שרתי NAS) יכולה להיות איטית מאוד לגיבוי ראשוני מלא בגלל כמות העצמים. גיבוי ראשון מומלץ לבצע בחיבור קווי.

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

High-Level Theory & History¶

המטרה של Time Machine היא כפולה: לאפשר למשתמש קצה לחלץ בטעות קובץ בודד שנמחק, ולאפשר לאיש IT לשחזר מחשב שלם לאחר קריסת חומרה. בעבר השחזור המלא כלל החזרת עותק של מערכת ההפעלה במלואה (מכיוון שהיא לא הייתה מופרדת ל-Data ו-System). כיום, שחזור מערכת מלא עובד אחרת לגמרי בגלל ארכיטקטורת ה-SSV.

Deep Technical Architecture¶

בשחזור של קובץ בודד (דרך ממשק ה-Time Machine ב-Finder), המערכת עוגנת (Mount) את ה-Snapshot הרלוונטי מכונן הגיבוי כקריאה-בלבד ומעתיקה את הקובץ אל מערכת הקבצים הנוכחית של המשתמש. בשחזור מערכת מלא (Full System Restore) מתקלה קטסטרופלית על Mac חדש, כבר לא מבצעים "Restore" של מערכת ההפעלה מהגיבוי. הפעולה הנכונה היא להתקין macOS טרי (דרך ה-1TR Recovery Mode), ואז, בסיום ההתקנה, להשתמש ב-Migration Assistant מתוך כונן ה-Time Machine. ה-Migration Assistant יעתיק רק את ה-Data Volume (יוזרים, הגדרות, ואפליקציות צד-שלישי) מה-Synthetic Snapshot האחרון ויחבר אותו ל-System Volume החתום החדש.

Terminal Commands, Plists & Logs¶

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

כלים מרכזיים מעורבים: ה-Migration Assistant.app הממוקם ב-/System/Applications/Utilities/.

Edge Cases & Troubleshooting¶

קונפליקט חשבונות ב-Migration: טעות נפוצה היא יצירת יוזר זמני במק החדש עם אותו שם משתמש (Short Name) שהיה במק הישן, ואז הפעלת Migration Assistant מהגיבוי. נוצר התנגשות שמות. ה-Migration Assistant יבקש לשנות את שם החשבון המיובא או להחליף אותו. הדרך הנכונה היא להפעיל את ה-Migration Assistant כבר במהלך ה-Setup Assistant (OOBE) או ליצור יוזר זמני עם שם אחר לחלוטין. FileVault ו-Time Machine: המידע בתוך ה-Snapshot המקומי על ה-Data Volume שומר על רמת ההצפנה שלו. אולם, כאשר הגיבוי יוצא לכונן ה-Time Machine, חשוב לוודא שהכונן החיצוני עצמו הוצפן ב-APFS Encrypted, אחרת המידע שחולץ יישב בצורה גלויה על דיסק הגיבוי הנייד ויהווה פרצת אבטחה.

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

High-Level Theory & History¶

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

Deep Technical Architecture¶

ספקי סנכרון ענן (Cloud Sync Providers) ב-macOS המודרני מבוססים על ה-FileProvider Framework של אפל. בניגוד ל-Time Machine שעובד ברמת הבלוק (APFS Blocks) ומצלם את כל הכונן, FileProvider מייצר קבצים וירטואליים (Datalless files או "Sparse files") בתוך ה-Data Volume שמושכים את המידע מהענן רק לפי דרישה (On-Demand). שני המנגנונים לא עובדים טוב ביחד - הניסיון לגבות תיקיית OneDrive באמצעות Time Machine עשוי לגרום להורדה כפויה של כל הקבצים מהענן לדיסק המקומי כדי לגבות אותם לבלוקים הפיזיים של Time Machine, מה שיסתום את נפח הדיסק ואת רוחב הפס.

Terminal Commands, Plists & Logs¶

איש ה-IT ישתמש בפרופיל MDM (Configuration Profile) המכיל את ה-Payload של com.apple.MCX.TimeMachine עם ההגדרה: <key>restrictTimeMachine</key><true/> כדי למנוע מהמשתמשים להפעיל גיבויי Time Machine מקומיים.

כדי לבדוק מצב FileProvider במקרה של תקלות סנכרון ענן: fileproviderctl dump

Edge Cases & Troubleshooting¶

משתמשי Heavy Duty ללא ענן: צוותי עריכת וידאו, סאונד או מפתחים המחזיקים מאגרים מקומיים (Local Repositories) של מאות גיגה-בייטים וירטואליים אינם יכולים להסתמך רק על OneDrive בגלל צווארי בקבוק ברשת. עבורם, IT חייב להגדיר פתרון גיבוי Block-level. במקרים אלו מתירים שימוש ב-Time Machine לכונן NAS מקומי מהיר, או משתמשים בפתרונות Enterprise Endpoint Backup ייעודיים כמו Code42 / CrashPlan. FileProvider Sync Locks: לעיתים מנגנון ה-FileProvider של OneDrive עלול להיתקע וליצור מצב שבו הקובץ "נעול" בענן ולא מסונכרן. מכיוון שאין Time Machine, משתמש שמחק בטעות קובץ שטרם סונכרן לענן יאבד אותו לצמיתות (בניגוד ל-Local Snapshot של APFS שהיה יכול להציל אותו). זוהי הפשרה של עבודה מבוססת-ענן בלבד.