בחודשיים האחרונים התברכתי במגוון תקלות מופלאות בכוננים קשיחים, דיסק אחד קיבל לי מגזרים רעים (bad sectors) דיסק שני קיבל, וחזר בו אחרי שהנתונים שבו הושמדו סופית.
מכל הסיפורים האלו, הפכתי למומחה לא קטן לשיחזורים של מידע מדיסקים אבודים.
לא שהיו לי אחוזי הצלחה טובים מדי, לעזזל, על הדיסק הראשון אני עדיין עובד, אחרי חודשיים (!), אבל בכל זאת, הנסיון הוא המורה הכי טוב, וכרגע יש ל י נסיון בערך כמו לאיזו מעבדת שחזורים קטנה.
אז כמה פנינות חוכמה, מבעל נסיון:
1. עצה מספר 1, בלי פאניקה – זו העצה הכי חשובה. אם אתם רוצים לגמור את כל העניין מהר, תכנסו לפאניקה. תוך עשר דקות רבע שעה הנתונים יהיו אבודים ותוכלו ללכת לראות טלוויזיה או לחתוך וורידים.
2. תתרחקו מLVM. אם אין לכם נסיון, זמן, סבלנות מפלדה, וגיבויים, פשוט אל תגעו. השחזור של דיסק LVM שקרס הוא משימה קשה הרבה הרבה יותר מאשר שחזור של נתונים מממחיצה רגילה. יש כמה בעיות עם LVM :
- אם יש לכם מחיצה לוגית שנפרשת על כמה דיסקים, ואחד מהם קרס, כל המחיצה הלכה.
- גם אם התכוננתם ודאגתם שכל מחיצה לוגית תשב על דיסק אחד בלבד, ואחד מהדיסקים הלך, יש סיכוי שהVolume-group כולו ילך קפוט אם אחד הדיסקים יקרוס.
- LVM פשוט לא מוכן, גם אם יש פונקציה שהכלים שלו אמורים לתת, הרבה פעמים תתאכזבו ברגע האמת.
אז מה נשאר? להשתמש בLVM בתוך אותו דיסק בלבד, לדאוג שלכל דיסק יהיה volume group משלו, ושלא יהיה יותר מדיסק אחד בתוך כל volume group. זו תצורה די בטוחה, אבל היא משאירה אתכם עם רווח מאוד שולי מהLVM: תוכלו לשנות דינמית את הגודל של המחיצות בתוך הדיסק.ביננו, אפשר לעשות את זה גם בלי LVM אם מאוד רוצים, ולכן המסקנה : עזבו את זה, זה לא שווה את הכאב הרב שזה יוצר.
ותאמינו לי, זה יוצר כבר, אני יושב בערוץ הIRC של LVM כבר שבוע, וכל מה שאני רואה זה קורבנות שבאים ומבקשים עזרה בשחזור. ולא, אף אחד לא עונה להם.
אז מה עושים?
דיסק שלכם קיבל מגזרים רעים? הדבר הראשון לעשות זה להרים את העוגן, מה שנקרא בלשון העם unmount. אתם לא רוצים שהמערכת הפעלה תתעסק עם הדיסק הזה בזמן שאתם מנסים לשחזר אותו. אם זה הדיסק הראשי שלכם תזמינו גרר מעכשיו. (דיסק בוט של קנופיקס הוא מאוד שימושי בזמנים כאלו).
מגזרים רעים הם בדרך כלל בעיה פיזית, נדיר שהיא נגרמת מתוכנה, אבל קיים. כמעט כל כונן קשיח היום מצוייד במערכת אוטומטית למיפוי מחדש של מגזרים רעים. זה אומר שאם סקטור מסויים נדפק, לא תדעו מזה כי הדיסק ימפה את הנתונים שעליו לסקטור אחר, שהוא שומר במחסן למקרה כזה בדיוק, ויפסיק לגשת לסקטור השבור.
ברגע שאתם מתחילים להרגיש את הבעיה, המצב כבר בקרשים – כי כל הספיירים שהדיסק שמר נגמרו, מה שאומר שהדיסק מחורבן לגמרי, ובדרך כלל במצב הזה הסקטורים הרעים רק מתרבים מיום ליום.
הסיבה שאני עובד כל כך הרבה זמן על שחזור של הדיסק הראשון שנדפק לי לפני חודשיים היא בדיוק זו. אני סורק את השטח שלו, מסמן את הסקטורים הרעים, ואז עובר שוב, והופה – יש עוד שלא תפסתי במעבר הקודם. ממש כמו הידרה – תורידו ראש אחד, יצמחו 2 במקום. בנוסף, הסריקה הזו מאוד איטית כי ברגע שהדיסק לא תקין קריאה של סקטור בודד יכולה לקחת דקה עד שמגיעה השגיאה המיוחלת.
ללינוקס כלי פשוט לסימון סקטורים רעים: badblocks.
לbadblocks שני מצבי סריקה מרכזיים:
קריאה-כתיבה לא הרסני.
כתיבה הרסני.
הראשון איטי, השני מהיר. אל תשתמשו בשני כי הוא משמיד את הנתונים, אלא אם – כמובן, אין נתונים, למשל אם הדיסק חדש ואתם רוצים לבדוק אותו.
badblocks לא עושה לדיסק שום דבר חוץ מלקרוא ולכתוב עליו, הוא לא מסמן את הסקטורים הרעים בשום מקום, במקום זה הוא יוצר קובץ שאליו הוא כותב את המספרים של הסקטורים הרעים. הקובץ הזה משמש כקלט לתוכניות לתיקון מערכת הקבצים (ככה הן יודעות על איזה סקטורים לא כדאי להן לדרוך). וזה מביא אותנו למוקש:
מה קורה אם badblocks חושב שגודל בלוק הוא 1024 בתים והתוכנית לתיקון מערכת הקבצים, נניח reiserfsck חושבת שגודל בלוק הוא 4096 בתים?
זה בדיוק המצב אם לא תגידו לbadblocks להשתמש בגודל בלוק הנכון, אז לשים לב.
אחרת יקרה לכם מה שקרה לי : תסרקו את הדיסק שבועיים, רק כדי לגלות שצריך להתחיל מחדש.
עוד משהו, בגלל הטבע הנבזי והחמקני של בלוקים רעים, אתם רוצים לסרוק כמה פעמים לפני שתכריזו על סיום. בשביל זה יש לbadblocks פרמטר שאומר לה כמה מעברים נקיים היא צריכה לפני שהיא מסיימת.
badblocks -vsno badblocks-output-file -p 4 -b 4096 /dev/sda1
אז ככה :
v- זה בשביל שbadblocks תדפיס הרבה (זה משעמם לחכות שבועיים בלי לקבל הדפסות).
s- זה בשביל לקבל הדפסת התקדמות.
n- זה בשביל מצב קריאה-כתיבה לא הרסני.
o- זה בשביל קובץ פלט.
p- זה בשביל מספר המעברים הנקיים לפני שמסיימים.
b- זה בשביל גודל הבלוק, ברירת המחדל היא 1024, אבל לפחות עבור reiserfs היא לא מתאימה (תבדקו במערכת הקבצים שלכם מה הגודל הנכון).
ואחרון זה השם של ההתקן לבדוק.
אחרי שהחלטתי סוף סוף שסרקתי מספיק את הדיסק (לקח לי חודש וחצי, ומצאתי בו בסביבות 50,000 בלוקים רעים), ניסיתי לתקן את מערכת הקבצים עם reiserfsck.
reiserfsck –rebuild-tree -B badblocks–output-file /dev/sda1
אפשר לראות שכפרמטר אני מעביר אם הקובץ שיצרה badblocks.
הבעיה היא, כמו שהסתבר לי, שהדיסק היה רע מדי מכדי שreiserfsck תצליח לתקן את הנתונים עליו. כבר כמעט וויתרתי על הכל, אבל חיפוש קצר בגוגל גילה שיש תקווה.
קוראים לתקווה dd_rescue.
dd, למי שלא מכיר, היא תוכנה קטנה ושימושית שמעתיקה בלוקים. הבעיה איתה, שכמו כל תוכנה טובה, היא מדווחת ברגע שיש לה בעיה, ומפסיקה את הפעולה. רק שזה לא טוב לנו פה. אם ננסה להעתיק את הנתונים של הדיסק למקום אחר כדי לנסות לשחזר אותם שם, dd תפסיק להעתיק ברגע שהיא תדרוך על סקטור רע.
ומי בה להצלה? ניחשתם, dd_rescue.
הפקודה להעתקה של הנתונים היא מאוד פשוטה :
dd_rescue /dev/data_vg/data /mnt/data.img
רק מה, באופן טבעי הפעולה לוקחת זמן לפחות כמו סריקה עם badblocks, וכמו שאמרתי, לסרוק דיסק דפוק לוקח ימבה זמן.
אז נשאלת השאלה, למה להשתמש בbadblocks בכלל, אם אפשר ישר להעתיק את הנתונים למקום אחד ולבנות את מערכת הקבצים שם מחדש?
השאלה מצויינת, ואם הייתי שואל את עצמי אותה לפני חודשיים אולי כבר הייתי משחזר את הנתונים ושולח את הדיסק המזויין להחלפה.
בקיצור, התהליך המומלץ הוא להשתמש בdd_rescue קודם כל, כדי להעתיק את הנתונים (ברמת הבלוקים) למקום בטוח ויציב, ורק אז לנסות לשחזר.
כמובן שצריך מקום פנוי בגודל של המחיצה שאתם רוצים להעתיק.
יש עוד הרבה מה להגיד על הנושא, אבל אני אעצור פה.
אם הנתונים קריטיים לכם ואת מוכנים לשלם הרבה, לכו לחברה שמתמחה בזה.
אם הנתונים פחות קריטיים, אבל אתם לא רוצים לשלם הרבה, אני מוכן לנסות לשחזר אותם במחיר זול יחסית לכמה שזה יעלה בחברה מתמחה.
השחזור לא מוגבל ללינוקס, כמובן. באותם כלים (או דומים) אפשר להשתמש כדי לשחזר גם דיסקים עם מערכות קבצים של חלונות.