בקצרה: רשמו hash כשאתם כותבים קובץ, והשוו אותו אחר כך. אם ה-hash שונה ושום דבר לא ערך את הקובץ, הבייטים השתנו מתחתיכם.
שום דבר אחר לא מוצא את זה. דיסק עם השחתה שקטה עובר את "עזרה ראשונה", מדווח SMART תקין, ומתחבר בצורה מושלמת.
אחסון הוא פיזי. תחומים מגנטיים בדיסק מסתובב נחלשים. מטען דולף מהתאים בזיכרון flash, מהר יותר כשחם ומהר עוד יותר כשהכונן יושב בלי חשמל זמן רב. כבל יכול להפיל ביט בדרך. לקושחה יש באגים.
כוננים מתקנים את רוב זה בעצמם, עם קודים לתיקון שגיאות ועל ידי העברת סקטורים שהם מוצאים שמתקלקלים. ההשחתה שחשובה היא החלק שעובר את זה: קריאה שמחזירה בייטים שונים מאלה שנכתבו, ומדווחת הצלחה.
השם שאנשים מתווכחים עליו. יש שקוראים לזה bit rot, יש שקוראים לזה השחתת נתונים שקטה, ויש שקוראים לזה התדרדרות נתונים. לצרכים שלנו זה אותו דבר: הקובץ שונה ושום דבר לא אמר.
זה החלק ששווה להבין, כי הוא מסביר למה כל כלי שהייתם פונים אליו הוא הכלי הלא נכון.
cp ו-Finder קוראים בייטים וכותבים בייטים. אם הקריאה החזירה בייטים שגויים, הם כותבים בנאמנות את הבייטים השגויים.אז העמדה הכנה היא: ל-Mac שלכם אין מנגנון שיגיד לכם. התסמין הראשון הוא תמונה עם פס של זבל לרוחבה, ארכיון שלא נפתח, או סרטון שנעצר באמצע.
נדיר לכל קובץ, ולא נדיר באוסף גדול לאורך זמן, וזה המקרה שגיבוי נועד לו. שני דברים מעלים את הסיכוי באופן ניכר:
הסיבה שזה חשוב יותר בגיבוי מאשר בדיסק העבודה שלכם היא שקובץ עבודה נפתח, וקובץ פגום שנפתח הוא השחתה שגיליתם. גיבוי נכתב פעם אחת ולא נקרא אף פעם, כלומר השחתה בגיבוי מתגלה ביום שצריכים את הגיבוי.
רשמו מה כתבתם:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtואז, חודשים אחר כך, בדקו אם הוא עדיין אותו דבר:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'כל מה שמודפס הוא קובץ שהבייטים שלו השתנו. אם לא ערכתם אותו, זו התשובה שלכם.
שתי הערות מעשיות. שמרו את קובץ ה-hash במקום שאינו הכונן שהוא מתאר, אחרת תאבדו את שניהם יחד. וזה לוקח כמו קריאת הכונן כולו, אז תזמנו את זה ללילה.
כל מה שלמעלה הוא הסיבה שהאפליקציה קיימת בצורה שבה היא קיימת. היא שומרת כל חלק של גיבוי תחת ה-hash של התוכן שלו, ואז קוראת את הגיבוי חזרה לפי לוח זמנים ובודקת כל חלק מול ה-hash שתחתיו נשמר.
לכן אי התאמה היא הוכחה: הבייטים אינם הבייטים שנכתבו, ואין שום פרשנות שבה זה בסדר. חלק שנמחק מתחת לגיבוי מדווח כחסר. והציון במסך הראשי סופר רק את מה שאומת לאחרונה, ולכן הוא נמוך ממה שאנשים מצפים, וזו בדיוק הנקודה.
מיקום שני חשוב כאן יותר מבכל מקום אחר באתר. השחתה בעותק אחד היא אי נוחות כשיש שניים, והיא סוף הקובץ כשיש אחד.
לא. "עזרה ראשונה" בודקת את מבנה מערכת הקבצים, לא את התוכן של הקבצים שלכם. כונן עם קבצים שהושחתו בשקט עובר אותה בלי בעיה, וזה בדיוק מה שהופך את הבעיה הזו למה שהיא.
לא לצורך הזה. SMART מדווח על שגיאות שהכונן הבחין בהן ותיקן או העביר. השחתה שקטה היא בדיוק הסוג שהוא לא הבחין בו. עדיין כדאי לבדוק אותו בכונן שהולך ומתקלקל, שזו בעיה אחרת וגלויה יותר.
היא מחשבת checksum למטא-נתונים שלה, לא לנתוני הקבצים שלכם. ZFS ו-Btrfs מחשבות checksum לתוכן הקבצים ויכולות לתקן מעותק עודף, ואף אחת מהן לא זמינה כנפח אתחול או נפח חיצוני רגיל ב-macOS. הפער הזה הוא הסיבה שבדיקה ברמת האפליקציה שווה.
בתדירות מספקת כדי שעותק פגום יתגלה כל עוד עותק תקין עדיין קיים. רבעוני סביר לארכיון; חודשי אם זה העותק היחיד של משהו שאין לו תחליף. התשובה הנכונה היא מה שבאמת לא תדלגו עליו, וזה טיעון בעד שזה יהיה אוטומטי.
לא. אימות אומר לכם שעותק התקלקל. הוא לא יכול להחזיר את הקובץ. זיהוי שימושי רק כשיש עותק שני לשחזר ממנו, וזה כל הטיעון בעד כלל 3-2-1.
קשור: איך בודקים שגיבוי קריא, פורמט המאגר, וכלל 3-2-1.