RAID 5, RAID 6, או ZFS Multiple Drive Drop: שחזור מערך Synology, QNAP או TrueNAS קרס מבלי להרוס זוגיות¶

שומע Synology DiskStation, QNAP TS-series, שרת TrueNAS או Linux mdadm שרת אחסון מצפצף ברציפות תוך כדי דיווח על הנפח קרס, הבריכה פגומה / פגומה או כוננים מרובים מנותקים הוא מצב חירום לאחסון בעל סיכון גבוה. כאשר כונן בודד נושר מתוך a RAID 5, Synology Hybrid RAID (SHR-1), או ZFS RAIDZ1 מאגר, המערך פועל עם אפס יתירות (degraded מצב), שחזור בלוקים חסרים על ידי קריאת כל דיסק שנותר במקביל. אם כונן שני נופל לא מקוון שעות מאוחר יותר, או זורק שגיאת קריאה בלתי ניתנת לשחזור (URE) באמצע בנייה מחדש לדיסק חלופי, מתמטיקה השוויונית מתקלקלת ומאגר האחסון עובר למצב לא מקוון לחלוטין. מנהלי מערכת בפאניקה הורסים לעתים קרובות טרה-בייט של נתונים שניתנים לשחזור בשישים השניות הבאות על ידי לחיצה על אתחול, יצירה מחדש של המערך עם mdadm --create, או לאלץ בנייה מחדש מקוונת מיידית על חומרה כושלת. אם כרטיס בקר החומרה RAID עצמו מת ולא הדיסקים, עבור אל מוות של כרטיס בקר RAID, ייבוא ​​תצורה זרה, ומדוע לעולם אסור לאתחל דיסקים; אם כונן קשיח בודד לוחץ או מסרב להסתחרר, התייעץ כשל בכונן הקשיח ושחזור נתונים או מערך RAID של NAS פגום, כשל בכוננים מרובים ושחזור ZFS/Btrfs. אם כשל אחסון זה משבית את ההדמיה הרפואית בבית החולים (PACS), שיגור חירום או תשתית לבטיחות חיים, התקשר למספר החירום המקומי שלך (911 בארצות הברית ובקנדה, 112 ברחבי האיחוד האירופי, 999 בבריטניה) או עיין במדריך שלנו של מספרי חירום.

תעשה את זה עכשיו¶

1. עצור ואל תלחץ על "אתחול", "צור מאגר", "תיקון" או הפעל mdadm --create בכוננים שנפלטו: לחיצה על אתחול ב-Synology DSM או QNAP QTS, או הפעלה mdadm --create בלינוקס, כותב בלוקים חדשים לגמרי ומתחיל לאפס פסי זוגיות בכל הדיסקים החברים. כונן שנפל בדרך כלל עדיין מחזיק 99.99% מהקבצים שלך שלמים, מסומנים רק לא מסונכרנים על ידי מונה האירועים שלו.
2. השבת את ה-NAS או השרת בצורה נקייה (או משוך חשמל אם הוא נבנה מחדש באופן פעיל על פני כוננים לוחצים) כדי להקפיא את מוני האירועים: בכל שנייה שהמערך נשאר מקוון במצב מושפל חלקית, מערכת ההפעלה מגדילה את הסופרבלוק Update Time ו Events מונה על הדיסקים ששרדו בזמן שהדיסק שנפל נשאר קפוא במספר אירוע ישן יותר. אם ה-NAS מנסה לבנות מחדש אוטומטית על פני כונן עם סקטורים פגומים, המשך קריאה של הכונן הזה יכול להפשיט את ציפוי המגש המגנטי (head crash).
3. תייג כל חריץ של תא כונן עם טוש פיזי או סרט (Bay 1, Bay 2, Bay 3, Bay 4) לפני החלקת מגש כלשהו החוצה: בזמן לינוקס mdadm, LVM2, ו ZFS עקוב אחר סדר הכוננים לפי UUID בתוך כל סופר בלוק מחיצה, בקרי חומרה ישנים יותר ומדריך dmsetup שחזורי טבלה דורשים את סדר המשבצות הפיזי המדויק (0, 1, 2, 3...).
4. לעולם אל תנסה התאוששות, הרכבה בכוח או fsck ישירות על כונני החבר המקוריים; לשכפל כל כונן ביט אחר סיביות באמצעות ddrescue ראשון: לפני הריצה mdadm --assemble --force או zpool import -F, חבר כל דיסק חבר לתחנת עבודה לינוקס באמצעות SATA/SAS ישיר (לעולם לא גשר USB זול שמסתיר SMART או SCT ERC פסק זמן) ושכפל אותו ddrescue על כוננים רזרביים בריאים או קבצי תמונה.
5. הרכיב בכוח את המערך המשובט אך ורק במצב קריאה בלבד (--readonly או -o readonly=on): בעת ההרכבה mdadm מערכים שמוני האירועים שלהם התרחקו במהלך נפילה בו-זמנית של ריבוי כוננים, תמיד עוברים --readonly (mdadm --assemble --force --readonly /dev/md0 ...). במצב קריאה בלבד, גם לא mdadm, LVM2, ext4, Btrfs, וגם לא ZFS יכול להחליף פסי זוגיות או להשמיע מחדש יומן הרסני.
6. העתק את הנתונים הקריטיים ביותר שלך לכונן גיבוי חיצוני עצמאי מיד לאחר שהותקן לקריאה בלבד: פנה תחילה את המסמכים, מסדי הנתונים, המכונות הווירטואליות והתמונות שלך לכונן נפרד, ואז נגב ובדוק את הדיסקים מאפס.

עץ ההחלטות: RAID מרובה כוננים וניסוי חירום בריכת ZFS¶

השתמש בתרשים זרימה זה כדי לקבוע אם המערך שלך סבל מירידה לוגית של פסק זמן (TLER / ERC חוסר התאמה), כשל אמיתי במגזר רע של ריבוי דיסקים במהלך בנייה מחדש, או קבוצת עסקאות ZFS (TXG) תקלה:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS Pool קרס לאחר נפילת 2 כוננים ומעלה"] --> StopIO["עצור את כל השחזורים והשבתת NAS באופן מיידי"]
    StopIO --> Label["סמן כל מגש כונן לפי מספר מפרץ (מפרץ 1 עד מפרץ N)"]
    Label --> ConnectLinux["חבר כונני חבר ל-Ubuntu Linux Rescue Host באמצעות Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["בדוק את SMART ומטא נתונים לקריאה בלבד: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"האם כוננים כלשהם לוחצים, מסרבים להסתובב או נושרים במצב לא מקוון ב-dmesg?"}

    PhysicalHealth -->|"כן: כשל מכאני/ראש ב-2+ כוננים ב-RAID 5"| Cleanroom["הפסק להפעיל דיסקים -> שלח למעבדת שחזור נתונים בחדר נקי"]
    PhysicalHealth -->|"לא: כל הכוננים מסתובבים (ייתכן שיש סקטורים פגומים בהמתנה או ירידה בתפוגה)"| CloneAll["שיבוט כונן כל חבר באמצעות GNU ddrescue (Forward Pass -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["נתק כוננים מקוריים ועבוד בקפדנות על דיסקים / תמונות משובטים"]
    DisconnectOrig --> ArrayType{"באיזו ארכיטקטורת אחסון משתמשים?"}

    ArrayType -->|"Synology DSM (SHR / RAID קלאסי)"| SynologyFlow["בדוק אירועים באמצעות mdadm --examine -> כפה הרכבה לקריאה בלבד -> הפעל את LVM2 / Btrfs לקריאה בלבד"]
    ArrayType -->|"QNAP QTS (HAL LVM דק / RAID עבה)"| QnapFlow["הרכיב את mdadm לקריאה בלבד -> הפעל שכבת DRBD אם קיימת -> סרוק QNAP LVM2 Superblocks מותאמים אישית"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["הפעל את zpool import -d /dev/disk/by-id -> ייבוא ​​לקריאה בלבד עם החזרה: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Linux mdadm רגיל"| LinuxFlow["השווה מונים אירועים -> הפעל mdadm --assemble --force --readonly -> הר קבצים עם -o ro,noload"]

שלב 1: מדוע אילוץ בנייה מחדש הורס נתונים (The URE ו-Same-Batch Cascade)¶

כדי להבין מדוע לחיצה על תיקון / בנייה מחדש או החלפת כונן אחד והמתנה של 36 שעות גורמת לרוב לקריסה מוחלטת של מערך, עליך להבין כיצד שחזור זוגיות מדגיש מדיה מגנטית מזדקנת ומדוע כוננים שולחניים של צרכנים נושרים ממארזי NAS.

1. המציאות המתמטית של שגיאות קריאה בלתי ניתנות לשחזור (UREs) במהלך בנייה מחדש של RAID 5 או RAIDZ1¶

ב-4 כוננים RAID 5 או ZFS RAIDZ1 בלוקים של מאגר, נתונים ושוויון (P) מפוספסים על פני כל ארבעת הדיסקים באמצעות OR בלעדי (XOR) חישוב (D1 XOR D2 XOR D3 = P). אם כונן 2 מת לחלוטין, למערך נותרה אפס יתירות. כדי לבנות מחדש את כונן 2 על גבי דיסק חלופי חדש לגמרי, ה-NAS חייב לקרוא כל סקטור בודד מבית 0 עד סוף הדיסק בכונן 1, כונן 3 וכונן 4 בו זמנית (Reconstructed D2 = D1 XOR D3 XOR P).

שקול מה קורה כאשר כוננים אלה הם ארבעה כוננים קשיחים של 12 טרה-בייט (12,000 גיגה-בייט) שנרכשו מאותה אצווה ייצור לפני ארבע שנים: - בנייה מחדש של 12 טרה-בייט דורשת קריאה 36 terabytes (2.88 x 1014 ביטים בודדים) ברציפות במשך 24 עד 48 שעות בעומס תרמי ומכני מרבי. - כוננים קשיחים לצרכנים נושאים בדרך כלל שגיאת קריאה בלתי ניתנת לשחזור (URE) מפרט של 1 error in 1014 bits (12.5 terabytes), וכוננים מזדקנים מפתחים שגיאות סקטור סמויות שקטות (Current_Pending_Sector) באזורים קרים של הדיסק שלא נקראו שנים. - הרגע שבו כונן 3 פוגע בסקטור לא קריא בודד של 4 קילובייט (0.004 מגה-בייט) בעוד שכונן 2 עדיין חסר או נבנה מחדש למחצה, XOR למשוואה יש שני לא ידועים (D2 ו D3).

2. למה כוננים שולחניים בלי TLER / SCT ERC להעיף לגמרי על מגזר רע אחד¶

הנה המלכודת שגורמת לנפילות קטסטרופליות של ריבוי כוננים ב-Synology, QNAP ולינוקס mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

שימו לב מה קרה בפועל: כונן 3 לא מת. יש לזה 99.999999% סקטורים בריאים ורק 1 או 2 סקטורים של 4 קילובייט בלתי קריאים (8 kilobytes מִתוֹך 12 terabytes). ובכל זאת בגלל mdadm הוציא את Drive 3 מהמערך עקב פסק זמן של 30 שניות לפקודה, כל עוצמת הקול מופיעה כ-Crashed. אם תשכפל את Drive 3 עם ddrescue (שמדלג בחן על 8 הקילו-בייט של סקטורים גרועים ומעתיק את שאר 12 הטרה-בייט) והרכבה בכוח של המערך לקריאה בלבד, אתה משחזר כמעט 100 אחוז מהקבצים שלך.

3. למה אסור לך אף פעם לרוץ mdadm --create או לחץ על "אתחול"¶

כאשר מערך קורס, שני מיתוסים הרסניים מסתובבים ברשת: - מיתוס 1: "צור מחדש את המערך עם אותו סדר כונן בדיוק באמצעות mdadm --create." אפילו עם --assume-clean, גרסאות מודרניות של mdadm ברירת המחדל לשונה Data Offset ערכים בהתאם לקרנל ו mdadm שחרר (2048 sectors לעומת 262144 sectors). כַּאֲשֵׁר mdadm --create כותב גרסה חדשה 1.2 סופרבלוק בהיסט שגוי או עם גודל נתח לא תואם, הוא מחליף את LVM2 כותרת נפח פיזית או ext4 סופרבלוק בקדמת הכרך. - מיתוס 2: "משוך את הכונן השני שזה עתה נפל, חבר אותו בחזרה ולחץ על תקן." אם כונן 1 נשר לפני שלושה ימים (כך שהנתונים שלו מיושנים ב-3 ימים) וכונן 3 נפל לפני 10 דקות (כך שהנתונים שלו עדכניים), משיכה והכנסה מחדש של הכונן השגוי או אילוץ בנייה מחדש עם כונן 1 מסומן "פעיל" ו-כונן 3 מסומן "חסיל" גורם ל-NAS לעדכן את ה-3-יום ** פסי זוגיות מיושנים**, משחיתים כל ספרייה וקובץ ששונו ב-72 השעות האחרונות.

שלב 2: בדיקת סופרבלוקים ו Event מונה בבטחה על מארח הצלה של לינוקס¶

כדי להציל מערך Synology, QNAP, TrueNAS או Linux שתרסק בבטחה, הסר את כל הכוננים החברים (לאחר תיוג מספרי המפרץ שלהם) וצרף אותם למחשב שולחני או לשרת המריצים את Ubuntu 22.04 LTS / 24.04 LTS (אפילו אתחול ממקל USB Live).

שלב 1: התקן את ערכת הכלים לחילוץ משפטי באובונטו¶

פתח מסוף במחשב ההצלה של אובונטו שלך והתקן את כלי השירות הנדרשים:

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

שלב 2: מיפוי כל אות כונן, מספר סידורי ופריסת מחיצה¶

רשום את כל התקני החסימה המחוברים ומספרי החומרה הסידוריים שלהם, כך שלעולם לא תבלבל דיסק הצלה עם דיסק מקור NAS:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

עיין בטבלת המחיצות של כונן Synology DSM, QNAP או TrueNAS טיפוסי:

שלב 3: בדוק mdadm --examine כדי לראות מדוע המערך קרס (The Event Counter Matrix)¶

ב-Synology, QNAP או Linux mdadm מערך, בדוק את המטא נתונים של RAID במחיצות נתוני המשתמש (לדוגמה, מחיצה 3 פועלת /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) מבלי להרכיב או לשנות דבר:

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

השווה את הפלט בכל ארבעת הכוננים:

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

קרא בעיון את הסיפור המשפטי הזה: 1. /dev/sdc3 (Device Role 1) יש Events ספירה של 479012 מלפני יומיים (Oct 29). הכונן הזה ירד לראשונה, לפני יומיים, ומאז הוא לא מקוון. 2. /dev/sdb3 (Role 0) ו/dev/sde3 (Role 3) לשניהם יש Events : 482190 ב 14:12:09. 3. /dev/sdd3 (Role 2) יש Events : 482188 ב 14:12:04, רק 5 שניות ו-2 אירועים מאחור sdb3 ו sde3. 4. מסקנה: עליך לשחזר את המערך באמצעות sdb3 (Role 0), sdd3 (Role 2), ו sde3 (Role 3) (שדלפקי האירועים שלהם מרוחקים רק 2 תקתוקים), בזמן עזיבה sdc3 (Role 1) החוצה לגמרי.

שלב 3: שיבוט כל כונן ביט אחר סיביות GNU ddrescue¶

לפני הריצה mdadm --assemble --force או zpool import -F, לשכפל כל כונן נדרש (במיוחד את הכונן שנשר לאחרונה עקב סקטורים לא טובים, כגון /dev/sdd בדוגמה שלמעלה) אל כונן ריק בריא בעל קיבולת שווה או גדולה יותר, או אל כונן גולמי .img קובץ בנפח אחסון גדול.

שלב 1: למה ddrescue עם mapfile זה חובה¶

סטנדרטי dd מפיל על המגזר הרע הראשון, או עם conv=noerror,sync מבזבז שעות לטחון את ראשי הקריאה שלו על מסלול פגום תוך מילוי אפס מגה-בייט של נתונים טובים סמוכים. GNU ddrescue עובד במעברים מרובים שלבים אינטליגנטיים: 1. מעבר 1 (שלב ההעתקה): מעתיק את כל האזורים הבריאים והמגיבים במהירות של הדיסק במהירות רציפה מלאה (150 MB/s ל 250 MB/s), דילוג מייד מעל כל בלוקים איטיים או בלתי קריאים כך שהכונן לא יתחמם יתר על המידה או ימות לפני שתקבל את 99.99% נתונים טובים. 2. מעבר 2 (שלב חיתוך): קורא ממש עד הקצוות המדויקים של כל בלוק רע הן מלפנים והן מאחור (reverse direction) כדי לבודד את האזור הפגוע עד למגזר החומרה המדויק של 4 קילובייט. 3. מעבר 3 (שלב הגרידה): מנסה מחדש את הסקטורים הפגועים בעדינות מבלי לאפס את האוטובוס שלא לצורך.

שלב 2: הפעל את 2 השלבים ddrescue פקודת שיבוט¶

ציין תמיד קובץ מפה (sdd_rescue.map). אם כונן המקור הגווע מתנתק ודורש מחזור חשמל, ddrescue קורא את קובץ המפה ומתחדש ב-byte המדויק שבו הוא הפסיק מבלי לקרוא מחדש קטע אחד שכבר הועתק:

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

שלב 4: בנייה מחדש של Synology DSM (SHR-1 / SHR-2 / RAID קלאסי), QNAP ולינוקס mdadm¶

לאחר שהכוננים המשובטים שלך (או התקני לולאה לקריאה בלבד) מוכנים וכונני ה-NAS המקוריים מנותקים בבטחה, עקוב אחר רצף ההרכבה הלא הרסני המדויק עבור הפלטפורמה שלך.

תרחיש א': לינוקס רגילה mdadm או Synology Classic RAID (RAID 5 / RAID 6)¶

1. עצור כל חלק md מערך שאולי אובונטו ניסתה להפעיל:

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. הרכבת בכוח את המחיצות המשובטות (sdb3, sdd3, sde3, משמיט את המתים מזמן sdc3) במצב קריאה בלבד:

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   צפו בפלט: mdadm ידווח forcing event count in /dev/sdd3(2) from 482188 up to 482190 ו mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. ודא שהמערך פעיל ומסומן (auto-read-only) או (read-only):

   cat /proc/mdstat
   

תרחיש ב': Synology Hybrid RAID (SHR-1 ו SHR-2) עם LVM2 ו Btrfs / ext4¶

SHR של Synology (Synology Hybrid RAID) הוא 100 אחוז לינוקס סטנדרטי mdadm + LVM2 (Logical Volume Manager): - כאשר כל הכוננים במאגר SHR הם באותו גודל (לדוגמה, ארבעה כוננים של 8 טרה-בייט), Synology יוצרת יחיד mdadm מחיצת RAID 5 (md2 על מחיצה 3 של כל כונן) וממקם an LVM2 קבוצת נפח (vg1000 או vg1) על גבי md2. - כאשר לכוננים במאגר SHR יש גדלים מעורבים (לדוגמה, שני כוננים של 8 טרה-בייט ושני כוננים של 16 טרה-בייט), Synology יוצרת שני כוננים נפרדים mdadm מערכים: md2 על פני מחיצה 5 (8 TB פרוסה בכל 4 הכוננים ב-RAID 5) ו md3 על פני מחיצה 6 (הנותרים 8 TB לחתוך על שני כונני 16 TB ב-RAID 1), ואז מצטרף md2 + md3 לתוך סינגל LVM2 קבוצת נפח (vg1000).

להרכבת אמצעי אחסון Synology SHR לקריאה בלבד באובונטו לאחר הרכבה בכוח /dev/md2 (ו /dev/md3 אם SHR בגודל מעורב): 1. סרוק את הנפחים הפיזיים וקבוצות הנפח של Synology LVM2:

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

תרחיש C: Synology DSM 7+ הצפנת נפח או הצפנת תיקייה משותפת (eCryptfs)¶

• הצפנת תיקיה משותפת (@sharename@ תיקיות המכילות ECRYPTFS_FNEK_ENCRYPTED... שמות קבצים): תעתיק את כולו @encrypted_share@ התיקיה כבויה /mnt/synology_rescue ראשית, לאחר מכן התקן ופענח אותו באובונטו באמצעות סיסמת ההצפנה שלך Synology או .key קובץ:

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• DSM 7.2+ הצפנת נפח מלא (LUKS): אם /dev/vg1000/lv מופעים TYPE="crypto_LUKS" ב blkid, בטל את נעילתו לקריאה בלבד באמצעות ה .rkey קובץ מפתח השחזור שהורד בעת יצירת אמצעי האחסון:

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

תרחיש D: QNAP QTS (LVM2 Thin Provisioning ו DRBD שכבה)¶

יחידות QNAP NAS מודרניות (QTS 4.3+ / 5.x) הכנס צומת יחיד פנימי DRBD מכשיר (/dev/drbd1) בין /dev/md1 ואת LVM2 קבוצת נפח (vg1). 1. תחילה הרכיבו בכוח את מחיצות הנתונים של QNAP (/dev/sd[b-e]3) לקריאה בלבד לתוך /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

שלב 5: הצלת TrueNAS ולינוקס ZFS בריכות (RAIDZ1, RAIDZ2, RAIDZ3)¶

אם שרת האחסון שלך פועל TrueNAS CORE, TrueNAS SCALE, Proxmox VE או Ubuntu ZFS, השחזור אינו משתמש mdadm. במקום זאת, ZFS משלב את מנהל הנפח והעתקה על כתיבה (CoW) מערכת קבצים לארכיטקטורת טרנזקציות אחת הבנויה סביב Uberblocks וקבוצות עסקאות עוקבות (TXGs).

שלב 1: בדוק את 4 תוויות ZFS vdev (L0, L1, L2, L3) בכל דיסק משובט¶

כל מחיצה של חבר ZFS מאחסנת ארבעה עותקים זהים של תצורת הבריכה ומערך של 128 Uberblocks האחרונים (שתי תוויות בקדמת המחיצה, L0 ו L1, ושתי תוויות ממש בסוף, L2 ו L3). לָרוּץ zdb -l בכל מחיצה משוכפלת כדי לבדוק את מצב המאגר ואת קבוצת העסקאות המחויבות הגבוהה ביותר (txg):

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

השווה את txg: מספרים בכל הכוננים המשובטים. ממש כמו mdadmשל Events counter, אם דיסק אחד נשמט 5 דקות לפני הפסקת חשמל או נפילת דיסק שני, זה txg יהיה מעט נמוך יותר מהדיסקים הנותרים.

שלב 2: ייבא את מאגר ZFS במצב קריאה בלבד (-o readonly=on)¶

תחילה בדוק בריכות לייבוא ​​מבלי להתקין דבר באמצעות sudo zpool import -d /dev/disk/by-id. לעולם אל תייבא מאגר ZFS פגום או שנפל מרובה דיסקים במצב קריאה-כתיבה. כאשר מיובא עם -o readonly=on, ZFS אינו מנסה להפעיל resilver, אינו כותב Uberblocks חדשים, ואינו יכול להיכנס לפאניקה של הליבה אם מפת שטח פגומה (spacemap) נתקל במהלך הקצאת כתיבה:

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

שלב 3: אם zpool import נכשל עם I/O error או corrupted data, השתמש ב-TXG Rollback (-F ו -T)¶

אם שני כוננים נשמטו תוך שניות אחד מהשני במהלך פרץ כתיבה כבד, קבוצת העסקאות העדכנית ביותר (TXG N) עשוי להיות לא שלם על פני פסי הזוגיות השורדים, בעוד TXG N-1 או TXG N-2 (נכתב 5 עד 15 שניות קודם לכן) שלם ב-100 אחוז בתוך מאגר הטבעות של Uberblock.

1. בדוק תצוגה מקדימה לא הרסנית של ריצה יבשה (-F -n):

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   אם ZFS מדווח Would be able to return pool to its state as of <timestamp>, הפעל את ייבוא ​​החזרה לקריאה בלבד ללא -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. אם -F עדיין לא יכול לעלות את Uberblocks העדכניים ביותר, רשום עם מספרי Uberblock TXG היסטוריים zdb וייבא TXG ישן יותר ספציפי (-T):

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   בחר א txg מספר בין 30 ל-60 שניות לפני ההתרסקות (לדוגמה, txg = 9481020) וייבא את הבריכה קפואה באותה נקודת זמן בדיוק במצב קריאה בלבד:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

שלב 6: אימות לאחר התאוששות ומניעת מפלי בנייה מחדש עתידיים¶

לאחר שהעתקת 100 אחוז מהנתונים המשוחזרים שלך מ /mnt/synology_rescue או /mnt/zfs_rescue על יעד גיבוי עצמאי, עקוב אחר רשימת חומרה ותצורה זו לפני שתחזיר את ה-NAS שלך לשירות:

• לעולם אל תקנה את כל כונני ה-NAS מאותו קמעונאי באותו יום: כוננים מאותו מגרש ייצור חולקים אצווה ראש וקושחה זהים, מה שגורם להם להיכשל תוך שעות אחד מהשני במהלך בנייה מחדש. מערבבים קבוצות או יצרנים (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• השתמש רק בכונני NAS/Enterprise עם TLER / SCT ERC מופעל (או העלה את לינוקס mdadm פסק זמן של SCSI עבור כוננים שולחניים): עבור כוננים לצרכנים בלינוקס mdadm, השתמש ב- a udev כלל להעלות /sys/block/sdX/device/timeout מ 30 שניות ל 180 שניות כך mdadm ממתין למיפוי מחדש של המגזר הפנימי במקום להפיל את הכונן.
• העברה של מערכים עם כוננים גדולים מ- 8 TB מ RAID 5 / SHR-1 / RAIDZ1 ל RAID 6 / SHR-2 / RAIDZ2: עם 12 TB ל 24 TB כוננים, זמני בנייה מחדש של זוגיות אחת עולים על 30 שעות, מה שהופך זוגיות כפולה (RAID 6 / SHR-2 / RAIDZ2) חשוב לשרוד מגזר רע במהלך ריסוס מחדש.
• לוח זמנים חודשי Data Scrubbing (mdadm check / zpool scrub) ומורחב SMART בדיקות: קרצוף חודשי מתקן שגיאות סקטור סמויות (Current_Pending_Sector) בזמן שכל הכוננים מחוברים.
• זכור ש-RAID הוא זמינות גבוהה, אף פעם לא גיבוי: עקוב אחר אסטרטגיית גיבוי 3-2-1 עם עותק לא מקוון.

מספרי חירום אזוריים ופרוטוקולי סוכנות¶

הפסקות אחסון המשפיעות על רשתות שירותי בריאות, תקשורת חירום או רשומות אישיות סטטוטוריות דורשות הסלמה מיידית:

• ארצות הברית וקנדה: חייגו 911 אם קריסת אחסון משביתה את המערכות הקליניות של בית החולים (EHR / PACS) או שליחה. דווח על תוכנות כופר ממוקדות NAS (DeadBolt, LockBit, Akira) ל-CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), או המרכז הקנדי לאבטחת סייבר (1-833-CYBER-88).
• בריטניה: חייגו 999 למקרי חירום המשפיעים על בטיחות החיים או טיפול חריף של NHS. תחת GDPR של בריטניה, העריכו אם אובדן נתונים אישיים לא מגובה לצמיתות מחייב להודיע ​​ל-ICO (0303 123 1113) תוך 72 שעות.
• האיחוד האירופי: חייגו 112 ברחבי האיחוד האירופי. ישויות במסגרת הדירקטיבה NIS2 חייבות לדווח על הפסקות תפעול גדולות ל-CSIRT הלאומי שלהם בתוך 24 שעות, ואובדן זמינות של נתונים אישיים קבועים גורם לדיווח של GDPR סעיף 33 תוך 72 שעות.
• אוסטרליה וניו זילנד: חייגו 000 באוסטרליה או 111 בניו זילנד; דווח על תקריות NAS של תשתית או תוכנות כופר ל-ACSC (1300 CYBER1) או CERT NZ (0800 237 869).
• הודו ואסיה-פסיפיק: חייגו 112 בהודו לתגובת חירום; דווח על תקריות אחסון תשתית ל-CERT-In (incident@cert-in.org.in) בתוך חלון החובה של 6 שעות.

שאלות נפוצות¶

למה עשה mdadm --assemble --force מסרב להפעיל את מערך ה-RAID 5 שלי not enough to start the array?¶

ב-4 כוננים RAID 5 מערך, לפחות 3 מתוך 4 כוננים יש להעביר ל mdadm --assemble --force. לָרוּץ sudo mdadm --examine /dev/sd[a-z]3 כדי לבדוק מדוע הכונן השלישי נדחה: או שהעברת את כל הדיסק במקום את המחיצה (/dev/sdd במקום /dev/sdd3), הסופרבלוק שלו סומן כ-a נוֹסָף על ידי בנייה מחדש מופרעת, או שה-auto-assembler של אובונטו נעל כונן אחד לתוך לא פעיל /dev/md127 מכשיר (הפעלה sudo mdadm --stop --scan תחילה, ואז הפעל מחדש mdadm --assemble --force --read-only).

מה אם כונן התחיל לבנות מחדש (Recovery = 12%) לפני שהכונן השני נשמט?¶

אם כונן 2 מת, הכנסת כונן 2 חלופי, ובשעה 12% התקדמות הבנייה מחדש כונן 3 ירד במצב לא מקוון עקב סקטור רע, אל תשתמש בכונן 2 החלופי שנבנה מחדש ב-12%.. במקום זאת, שכבו את המקור כונן 3 עם ddrescue. מכיוון שכונן 3 היה עדכני לחלוטין עד שהבנייה מחדש נעצרה ב-12%, הרכבה בכוח את המערך לקריאה בלבד באמצעות כונן 1, ddrescue שיבוט של Drive 3, ו-Drive 4 (משאיר את Drive 2 בחוץ) נותן לך מערך עקבי.

האם אוכל להכניס את כונני ה-Synology או ה-QNAP שלי למארז NAS חדש לגמרי אם ספק הכוח או הלוח של NAS מתים?¶

כן, גם סינולוגיה (העברת HDD) ו-QNAP (העברת NAS ישירה) אחסן את תצורת ה-RAID בכוננים עצמם. אוּלָם, אם שני כוננים או יותר כבר נשרו (`Volume Crashed`) לפני שהמארז מת, אין לאתחל אותם בתוך מארז NAS חדש, מכיוון שאשף ההגירה עשוי להחליף מחיצות או להפעיל בנייה מחדש הרסנית. תחילה הצל את הנתונים לקריאה בלבד באובונטו.

איך אני יודע אם כונן שנפל בטוח לשכפול איתו ddrescue לעומת צורך במעבדת חדר נקי?¶

חבר את הכונן ל-SATA, הפעל אותו והאזין במשך 10 שניות תוך כדי צפייה sudo dmesg -w. אם הכונן משמיע צלילי נקישה, גירוד או זמזום קצביים, מסתובב למעלה ומסתובב חזרה למטה, או מדווח על קיבולת 0 ב / 4.1 ג'יגה-בייט ב lsblk, ראשי הקריאה/כתיבה נכשלו פיזית: נתק מיד את החשמל והשתמש במעבדת חדר נקי. אם הכונן מסתובב בצורה חלקה, מראה את מלוא הקיבולת שלו פנימה lsblk, ורק יומנים Current_Pending_Sector או שגיאות זמן קצוב, לשכפל אותו ddrescue.

מהו "חור הכתיבה של RAID 5" וכיצד ZFS או Btrfs להימנע מכך בזמן הפסקת חשמל?¶

במסורת RAID 5 / RAID 6 ללא יומן, עדכון פס מצריך כתיבת בלוק הנתונים ובלוק הזוגיות לשני דיסקים בו זמנית. אם הספק נכשל באמצע הכתיבה, הנתונים והשוויון אינם תואמים יותר (ה כתוב חור). ZFS (`RAIDZ`) ו Btrfs הסר את חור הכתיבה באמצעות Copy-on-Write (`CoW`), כתיבת כל פס חדש לבלוקים שאינם בשימוש ועדכון מצביע Uberblock/root רק לאחר שהפס המלא נמצא בדיסק.

האם אני יכול להשתמש dmsetup שכבות לבדיקת פרמטרי RAID מבלי לשנות את הכוננים המשובטים?¶

כן, אתה יכול ליצור Copy-on-Write (`CoW`) שכבות על גבי התקני לולאה לקריאה בלבד (`losetup --read-only`) באמצעות לינוקס dmsetup (`snapshot` target) מגובה בקבצים דלילים ב /tmp. כל כתיבה מ mdadm --assemble --force או fsck -y להיכנס לחד פעמי /tmp קובץ שכבת-על, המאפשר לך לאפס תוך שנייה אחת במידת הצורך.

מדריכים קשורים¶

• מערך RAID של NAS פגום, כשל בכוננים מרובים ושחזור ZFS/Btrfs
• מוות של כרטיס בקר RAID, ייבוא ​​תצורה זרה, ומדוע לעולם אסור לאתחל דיסקים
• כשל בכונן קשיח ושחזור נתונים
• מצב קריאה פתאומי של SSD ו-NVMe, 0% חסימות חילוף ו-TRIM השבתת הצלה
• 'rm -rf' או 'Shift+Delete' בטעות ב-Linux, macOS או Windows: הפעלה מחדש מיידית לקריאה בלבד
• גיבוי מחשבים, אסטרטגיית 3-2-1, והתאוששות מאסון
• מספרי חירום לפי מדינה

מקורות והדרכה רשמית¶

• Linux Raid Wiki (raid.wiki.kernel.org) וארגון ליבת לינוקס: שחזור RAID תוכנה כושל (mdadm --assemble --force --readonly ואי-התאמות מונה אירועים).
• קרן תוכנה חופשית (GNU Project): גנו ddrescue מדריך: שחזור נתונים משפטיים ממדיה כושלת.
• תיעוד OpenZFS (openzfs.github.io): שחזור ייבוא ​​מאגר ZFS (zpool import -F, יבוא לקריאה בלבד ו zdb בְּדִיקָה).
• Synology Inc.: מרכז הידע של Synology: כיצד אוכל להשתמש במחשב כדי לשחזר נתונים כאשר ה-Synology NAS שלי מתקלקל (mdadm + LVM2 הַרכָּבָה).
• המכון הלאומי לתקנים וטכנולוגיה (NIST) (ארצות הברית): פרסום מיוחד 800-209: הנחיות אבטחה לתשתית אחסון.