RAID 5, RAID 6 oder ZFS Multiple Drive Drop: E Crashed Synology, QNAP oder TrueNAS Array recuperéieren ouni Paritéit ze zerstéieren¶

Héieren eng Synology DiskStation, QNAP TS-Serie, TrueNAS Server oder Linux mdadm Späicherserver piept kontinuéierlech beim Bericht Volume Crashed, Pool Degraded / Faulted, oder Multiple Drives Disconnected ass en Noutfallspeicherung. Wann eng eenzeg fueren fällt aus engem RAID 5, Synology Hybrid RAID (SHR-1), oder ZFS RAIDZ1 Pool, d'Array leeft mat Null Redundanz (degraded Staat), rekonstruéiere vermësst Blocken op der Flucht andeems Dir all verbleiwen Disk parallel liest. Wann en zweeten Drive Stonnen méi spéit offline fällt, oder en Unrecoverable Liesfehler werft (URE) hallef duerch eng Rekonstruktioun op eng Ersatzdisk, brécht d'Paritéit Mathematik an de Späicherpool geet komplett offline. Panikéiert Administrateuren zerstéieren dacks Terabytes vun erhuelbaren Donnéeën an den nächste siechzeg Sekonnen andeems Dir op Initialiséieren klickt, d'Array nei erstellen mat mdadm --create, oder en direkten Online-Rekonstruktioun op falsch Hardware forcéieren. Wann Är Hardware RAID Controller Kaart selwer stierft anstatt d'Disken, schalt op RAID Controller Card Doud, auslännesch Configuratioun Import, a firwat Dir musst ni discs initialize; wann eng individuell Festplack klickt oder refuséiert ze spin an, consultéieren Festplack Echec an Daten Erhuelung oder NAS RAID Array degradéiert, Multiple Drive Feeler, an ZFS / Btrfs Erhuelung. Wann dëse Späicherfehler Spidol medizinesch Imaging deaktivéiert (PACS), Noutfallsendung oder Liewenssécherheetsinfrastruktur, rufft Är lokal Noutruffnummer un (911 an den USA a Kanada, 112 an der Europäescher Unioun, 999 a Groussbritannien) oder kuckt eise Verzeechnes vun Noutfallnummeren.

Maachen dëst elo¶

1. ** STOPPEN a klickt NET op "Initialiséieren", "Schafe Pool", "Reparéieren" oder lafen mdadm --create op den erofgefallen Drive**: Klickt op Initialiséieren an Synology DSM oder QNAP QTS, oder lafen mdadm --create am Linux, schreift fuschneie Superblocks a fänkt un Paritéitsstreifen iwwer all Memberdiskussiounen un. E gefallene Drive hält normalerweis nach ëmmer 99.99% vun Äre Fichieren intakt, nëmmen ausser-synchroniséiert duerch säin Event Konter markéiert.
2. ** Maacht d'NAS oder d'Server propper erof (oder zitt d'Kraaft wann et aktiv iwwer klickende Drive nei opbaut) fir d'Evenementzähler ze afréieren **: All Sekonn bleift d'Array online an engem deelweis degradéierten Zoustand, erhéicht de Betribssystem de Superblock Update Time an Events Konter op déi iwwerliewend Scheiwen, während de gefallene Scheif bei enger méi aler Eventnummer gefruer bleift. Wann d'NAS eng automatiséiert Neiopbau iwwer e Drive mat schlechte Secteuren probéiert, weider ze liesen, datt de Drive d'Magnéitplackbeschichtung aussträichen (head crash).
3. ** Label all Drive Bay Slot mat engem physeschen Marker oder Band (Bay 1, Bay 2, Bay 3, Bay 4) ier Dir all Schacht eraus rutscht **: Wärend Linux mdadm, LVM2,an an ZFS Streck Drive Uerdnung duerch UUID bannent all Partition Superblock, eeler Hardware Controller an Handbuch dmsetup Dësch Rekonstruktiounen erfuerderen déi exakt kierperlech Slotuerdnung (0, 1, 2, 3...).
4. ** Ni Versuch eng Erhuelung, Kraaft-Versammlung, oder fsck direkt op der original Member fiert; klone all Drive bit-fir-bit benotzt ddrescue éischt **: Virun Lafen mdadm --assemble --force oder zpool import -F, befestegt all Member Disk op eng Linux Workstation iwwer direkt SATA / SAS (ni eng bëlleg USB Bréck déi verstoppt SMART oder SCT ERC Timeouts) a klon et mat ddrescue op gesond Ersatzstécker oder Bilddateien.
5. ** Forcéiere de gekloonten Array strikt am READ-ONLY Modus (--readonly oder -o readonly=on)**: Beim Montage mdadm Arrays deenen hir Eventzähler während enger simultaner Multi-Drive Drop ausernee gedriwwe sinn, passéieren ëmmer --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Am Lies-nëmmen Modus, weder mdadm, LVM2, ext4, Btrfs, nach ZFS kann Paritéitstreifen iwwerschreiwe oder en zerstéierende Journal widderhuelen.
6. **Kopieert Är kriteschst Donnéeën direkt op en onofhängegen externen Backup-Laufwerk soubal se just liest montéiert sinn **: Evakuéiert Är Dokumenter, Datenbanken, virtuell Maschinnen a Fotoen fir d'éischt op en getrennten Drive, wëschen an testt d'Disken vun Null un.

Decisioun Bam: Multi-fueren RAID an ZFS Pool Noutfall Triage¶

Benotzt dëse Flowchart fir ze bestëmmen ob Är Array e logesche Timeout drop huet (TLER / ERC mismatch), e richtege Multi-Disk schlechte Secteur Feeler beim Opbau, oder eng ZFS Transaktiounsgrupp (TXG) Feeler:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS Pool Crashed No 2+ Drive gefall"] --> StopIO["STOP All Rebuilds & Power Down NAS direkt"]
    StopIO --> Label["Label All Drive Schacht no Buchtnummer (Bay 1 bis Bay N)"]
    Label --> ConnectLinux["Connect Member Drives zu Ubuntu Linux Rescue Host iwwer Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["Inspect SMART & Metadaten Read-Only: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Ginn all Drive Klicken, Refuséieren ze spin, oder Offline falen an dmesg?"}

    PhysicalHealth -->|"Jo: Mechanesch / Kappfehler op 2+ Drive am RAID 5"| Cleanroom["STOP Powering Disks -> Schéckt op Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Nee: All Drive Spin Up (Kënne pendend schlecht Secteuren oder Timeout Drops hunn)"| CloneAll["Klon all Member Drive mat GNU ddrescue (Forward Pass -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["Trennt d'Original Drive a schafft strikt op gekloonten Disken / Biller"]
    DisconnectOrig --> ArrayType{"Wéi eng Späicherarchitektur gëtt benotzt?"}

    ArrayType -->|"Synology DSM (SHR / Classic RAID)"| SynologyFlow["Inspektéiert Eventer iwwer mdadm --examine -> Force-Assemble Read-Only -> Aktivéiert LVM2 / Btrfs Read-Only"]
    ArrayType -->|"QNAP QTS (HAL LVM Thin / Thick RAID)"| QnapFlow["Assemble mdadm Read-Only -> Aktivéiert DRBD Layer wann präsent -> Scan Custom QNAP LVM2 Superblocks"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["Run zpool import -d /dev/disk/by-id -> Import Read-Only with Rollback: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standard Linux mdadm"| LinuxFlow["Vergläichen Event Counters -> Run mdadm --assemble --force --readonly -> Mount Dateisystem mat -o ro,noload"]

Phase 1: Firwat en Neibau forcéieren zerstéiert Daten (D'URE a Same-Batch Cascade)¶

Fir ze verstoen firwat klickt **Reparéieren / Neibauen ** oder ersetzt een Drive a waart 36 Stonnen dacks e ganzen Array Crash verursaacht, musst Dir verstoen wéi d'Paritéitsrekonstruktioun alternd magnetesch Medien betount a firwat Konsument Desktop Drive aus NAS-Gehäuse falen.

1. Déi mathematesch Realitéit vun Unrecoverable Liesfehler (UREs) während enger RAID 5 oder RAIDZ1 Opbau¶

An engem 4-fueren RAID 5 oder ZFS RAIDZ1 Pool, Daten a Paritéitsblocken (P) sinn iwwer all véier Disken gestreift mat engem Exklusiv ODER (XORBerechnung (D1 XOR D2 XOR D3 = P). Wann Drive 2 komplett stierft, huet d'Array null Rescht Redundanz. Fir Drive 2 op e fuschneie Ersatzdisk ze nei opzebauen, muss d'NAS all eenzel Secteur vum Byte 0 bis zum Enn vun der Disk op Drive 1, Drive 3, an Drive 4 gläichzäiteg liesen (Reconstructed D2 = D1 XOR D3 XOR P).

Bedenkt wat geschitt wann dës Drive véier 12 Terabyte (12.000 Gigabyte) Festplazen sinn, déi aus der selwechter Fabrikatiounsbatch viru véier Joer kaaft goufen: - 12 Terabytes nei opzebauen erfuerdert Liesen 36 terabytes (2.88 x 1014 eenzel Bits) kontinuéierlech iwwer 24 bis 48 Stonnen bei maximaler thermescher a mechanescher Belaaschtung. - Konsument Festplazen droen typesch en Unrecoverable Liesfehler (URE) Spezifizéierung vun 1 error in 1014 bits (12.5 terabytes), an alternd Drive entwéckelen stille latente Sektorfehler (Current_Pending_Sector) a kale Gebidder vun der Scheif, déi zënter Joren net gelies goufen. - De Moment Drive 3 en eenzegen onliesbaren 4 Kilobyte (0,004 Megabyte) schlechte Secteur trëfft, während Drive 2 nach ëmmer fehlt oder hallef nei opgebaut ass, den XOR Equatioun huet zwee Onbekannten (D2 an D3).

2. Firwat Desktop fiert ouni TLER / SCT ERC ganz iwwer 1 schlecht Secteur erausgehäit¶

Hei ass d'Fal déi katastrophal Multi-Drive Drops op Synology, QNAP a Linux verursaacht 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.                 |
+-------------------------------------------------------------------------+

Notéiert wat tatsächlech geschitt ass: Drive 3 ass net dout. Et huet 99.999999% gesond Secteuren an nëmmen 1 oder 2 onliesbar 4 Kilobyte Secteuren (8 kilobytes aus 12 terabytes). Trotzdem well mdadm huet Drive 3 aus der Array erausgeschloen wéinst engem 30-Sekonne Kommando-Timeout, de ganze Volume weist als ** Crashed **. Wann Dir Klon Drive 3 mat ddrescue (wat graziéis déi 8 Kilobyte vu schlechte Secteuren iwwerspréngt an déi aner 12 Terabytes kopéiert) a Kraaft-assembléiert d'Array nëmme liesen, recuperéiert Dir quasi 100 Prozent vun Äre Dateien.

3. Firwat Dir musst ni lafen mdadm --create oder klickt "Initialiséieren"¶

Wann eng Array ofbriechen, zirkuléieren zwee destruktiv Mythen online: - ** Mythos 1: "Erstellt d'Array nei mat der exakt selwechter Drive-Uerdnung mat mdadm --create."** Och mat --assume-clean, modern Versiounen vun mdadm Standard op verschiddene Data Offset Wäerter ofhängeg vum Kärel a mdadm Fräisetzung (2048 sectors vs 262144 sectors). Wéini mdadm --create schreift eng nei Versioun 1.2 superblock op déi falsch Offset oder mat engem Mëssverständis Chunk Gréisst, et iwwerschreift der LVM2 kierperlech Volume Header oder ext4 Superblock virun der Volumen. - Mythos 2: "Pull den zweeten Drive eraus, dee just erofgefall ass, Plug et erëm an a klickt op Reparéieren." Wann Drive 1 virun dräi Deeg erausgefall ass (also seng Donnéeën 3 Deeg al sinn) an Drive 3 virun 10 Minutten erausgefall sinn (sou datt seng Donnéeën aktuell sinn), zitt de falschen Drive an nei asetzt oder e Rekonstruktioun forcéiert mat Drive 1 markéiert "aktiv" an Drive 3 markéiert "Ersatz" verursaacht den NAS 3Dag up-towritear stale Paritéitsstreifen **, korrupt all Verzeechnes a Fichier déi an de leschten 72 Stonnen geännert goufen.

Phase 2: Inspektioun superblocks an Event Konter sécher op engem Linux Rettungshost¶

Fir e ofgebrach Synology, QNAP, TrueNAS oder Linux Array sécher ze retten, huelt all Member Drive (nodeems hir Buchtnummere gezeechent hunn) a befestegt se op en Desktop PC oder Server deen Ubuntu 22.04 LTS / 24.04 LTS leeft (souguer vun engem Live USB Stick gestart).

Schrëtt 1: Installéiert de forensesche Rettungstoolkit an Ubuntu¶

Öffnen en Terminal op Ärer Ubuntu Rettungsmaschinn an installéieren déi erfuerderlech Utilities:

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

Schrëtt 2: Kaart all Drive Bréif, Serien Zuel, a Partitur Layout¶

Lëscht all verbonne Blockgeräter an hir Hardware Seriennummeren sou datt Dir ni eng Rettungsdiskussioun mat enger Quell NAS Disk verwiesselt:

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

Kuckt d'Partitionstabel vun engem typesche Synology DSM, QNAP oder TrueNAS Drive:

Schrëtt 3: Check mdadm --examine fir ze kucken firwat d'Array erofgefall ass (The Event Counter Matrix)¶

Op enger Synology, QNAP oder Linux mdadm Array, ënnersicht d'RAID Metadaten op de Benotzerdatenpartitionen (zum Beispill Partition 3 op /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) ouni eppes ze montéieren oder z'änneren:

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

Vergläicht d'Ausgab iwwer all véier Drive:

/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)

Liest dës forensesch Geschicht virsiichteg: 1. /dev/sdc3 (Device Role 1) huet eng Events zielen vun 479012 vun ** virun zwee Deeg (Oct 29). Deen Drive ass fir d'éischt erausgaang, virun zwee Deeg, an ass zënterhier offline. 2. /dev/sdb3 (Role 0) an /dev/sde3 (Role 3) béid hunn Events : 482190 op 14:12:09. 3. /dev/sdd3 (Role 2) huet Events : 482188 op 14:12:04, just 5 Sekonnen an 2 Eventer hannendrun sdb3 an sde3. 4. Conclusioun: Dir musst d'Array rekonstruéieren mat sdb3 (Role 0), sdd3 (Role 2), an sde3 (Role 3) (deem hir Event counters sinn nëmmen 2 Ticken ausser), iwwerdeems ** verloossen sdc3 (Role 1) komplett aus.

Phase 3: Klon all fueren bëssen-fir-bëssen mat GNU ddrescue¶

Virun Lafen mdadm --assemble --force oder zpool import -F, klon all erfuerderlechen Drive (besonnesch den Drive, deen d'lescht ausgaang ass wéinst schlechte Secteuren, wéi z. /dev/sdd am Beispill hei uewen) op eng gesond eidel Fuert mat gläicher oder méi grousser Kapazitéit, oder an eng Matière .img Datei op engem grousse Späichervolumen.

Schrëtt 1: Firwat ddrescue mat enger Mapfile ass obligatoresch¶

Standard dd ofbriechen op déi éischt schlecht Secteur, oder mat conv=noerror,sync verschwënnt Stonnen, déi seng Lieskäpp iwwer eng beschiedegt Streck schleifen, während d'Megabyte vu bascht gutt Daten null fëllt. GNU ddrescue Wierker an intelligent Multi-Etapp Passë: 1. Pass 1 (Kopieerphase): Kopéiert all gesond, séier reagéierend Regioune vun der Disk op voller sequenziell Geschwindegkeet (150 MB/s zu 250 MB/s), sprangen direkt iwwer all luesen oder onliesbare Blocks sou datt den Drive net iwwerhëtzt oder stierft ier Dir de 99.99% gutt daten . 2. **Pass 2 (Trimmphase) **: Liest bis op déi exakt Kante vun all schlechte Block vu béide vir an hannen (reverse direction) fir dat beschiedegt Gebitt bis op de genauen 4 Kilobyte Hardware Secteur ze isoléieren. 3. ** Pass 3 (Scraping Phase) **: Probéiert déi beschiedegt Secteuren sanft ouni de Bus onnéideg ze resetten.

Schrëtt 2: Run der 2-Etapp ddrescue Klonen Kommando¶

Gitt ëmmer eng mapfile (sdd_rescue.map). Wann de stierwende Quell Drive trennt an e Kraaftzyklus erfuerdert, ddrescue liest d'Kaartdatei a fuert op de genaue Byte wou et opgehalen huet ouni en eenzege scho kopéierte Secteur nei ze liesen:

# 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

Phase 4: Synology DSM rekonstruéieren (SHR-1 / SHR-2 / Classic RAID), QNAP, a Linux mdadm¶

Wann Är gekloonten Drive (oder Read-only Loop-Geräter) fäerdeg sinn an déi ursprénglech NAS-Laufwerke sécher ausgeschloss sinn, befollegt déi exakt net-zerstéierend Assemblée Sequenz fir Är Plattform.

Szenario A: Standard Linux mdadm oder Synology Classic RAID (RAID 5 / RAID 6)¶

1. Stop all partiell md Array datt Ubuntu probéiert hätt ze starten:

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

2. Force-assembléiert déi gekloonten Partitionen (sdb3, sdd3, sde3, déi laang Verstuerwen ausgoen sdc3) am ** streng liesbare Modus**:

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

   Kuckt d'Ausgab: mdadm wäert mellen forcing event count in /dev/sdd3(2) from 482188 up to 482190 an mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Vergewëssert Iech datt d'Array aktiv a markéiert ass (auto-read-only) oder (read-only):

   cat /proc/mdstat
   

Szenario B: Synology Hybrid RAID (SHR-1 an SHR-2) mat LVM2 an Btrfs / ext4¶

Synology's SHR (Synology Hybrid RAID) ass 100 Prozent Standard Linux mdadm + LVM2 (Logical Volume Manager)*: - Wann all Drive an engem SHR-Pool déiselwecht Gréisst sinn (zum Beispill véier 8 Terabyte Drive), erstellt Synology eng eenzeg mdadm RAID 5 Partition (md2 op Partitur 3 vun all fueren) a Plazen eng LVM2 Volume Grupp (vg1000 oder vg1) uewen op md2. - Wann Drive an engem SHR Pool gemëschte Gréissten hunn (zum Beispill zwee 8 Terabyte Drive an zwee 16 Terabyte Drive), erstellt Synology zwee separat mdadm Arrays: md2 iwwer Partition 5 (8 TB Slice op all 4 fiert am RAID 5) an md3 iwwer Partition 6 (déi reschtlech 8 TB Slice op déi zwee 16 TB fiert am RAID 1), dann bäitrieden md2 + md3 an eng eenzeg LVM2 Volume Group (vg1000).

Fir e Synology SHR Volumen nëmmen liest op Ubuntu ze montéieren no der Kraaftversammlung /dev/md2 (an /dev/md3 wann gemëscht Gréisst SHR): 1. Scan fir d'Synology LVM2 Physikalesch Volumen a Volumengruppen:

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

Szenario C: Synology DSM 7+ Volume Verschlësselung oder Shared Folder Encryption (eCryptfs)¶

• ** Shared Folder Verschlësselung (@sharename@ Classeure mat ECRYPTFS_FNEK_ENCRYPTED... Dateinumm)**: Kopie déi ganz @encrypted_share@ Dossier aus /mnt/synology_rescue Als éischt, montéiert et dann op Ubuntu mat Ärem Synology Verschlësselungspasswuert oder .key Datei:

  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+ Vollvolumen Verschlësselung (LUKS)*: Wann /dev/vg1000/lv weist TYPE="crypto_LUKS" an blkid, Spär et nëmme liest mat der .rkey Erhuelungsschlëssel Datei erofgeluede wann de Volume erstallt gouf:

  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
  

Szenario D: QNAP QTS (LVM2 Thin Provisioning an DRBD Layer)¶

Modern QNAP NAS Eenheeten (QTS 4.3+ / 5.x) en internen eenzegen Node setzen DRBD Apparat (/dev/drbd1) zwischen /dev/md1 an den LVM2 Volume Group (vg1). 1. Éischt Kraaft-assembléiert d'QNAP Datepartitionen (/dev/sd[b-e]3) nëmmen liesen an /dev/md1:

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

Phase 5: TrueNAS a Linux retten ZFS Poolen (RAIDZ1, RAIDZ2, RAIDZ3)¶

Wann Äre Späicherserver TrueNAS CORE, TrueNAS SCALE, Proxmox VE oder Ubuntu ZFS leeft, gëtt d'Erhuelung net benotzt mdadm. Amplaz kombinéiert ZFS de Volume Manager a Copy-on-Write (CoW) Dateisystem an eng eenzeg Transaktiounsarchitektur gebaut ronderëm Uberblocks a sequentiell Transaktiounsgruppen (TXGs).

Schrëtt 1: Kontrolléiert déi 4 ZFS vdev Etiketten (L0, L1, L2, L3) op all gekloonten Disk¶

All ZFS Member Partition späichert véier identesch Exemplare vun der Poolkonfiguratioun an eng Array vun de leschten 128 Uberblocks (zwee Etiketten virun der Partition, L0 an L1, an zwee Etiketten um Enn, L2 an L3). Lafen zdb -l op all gekloonten Partition fir de Poolstaat an héchst engagéierten Transaktiounsgrupp z'inspektéieren (txg):

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

Vergläichen de txg: Zuelen iwwer all gekloonten Drive. Just wéi mdadm's Events Géigewier, wann een Scheif gefall eraus 5 Minutte virun engem Muecht Verloscht oder zweet Scheif Lëscht, seng txg wäert e bësse méi niddereg sinn wéi déi verbleiwen Disken.

Schrëtt 2: Import den ZFS Pool am strikt Read-Only Modus (-o readonly=on)¶

Éischt kontrolléieren importable Pool ouni Montéierung eppes via sudo zpool import -d /dev/disk/by-id. Ni importéiert e beschiedegten oder Multi-Disk erofgefall ZFS Pool am Lies-Schreifmodus. Wann importéiert mat -o readonly=on, ZFS probéiert net e Resilver ze initiéieren, schreift keng nei Uberblocks, a kann de Kernel net panikéieren wann eng korrupt Raumkaart (spacemap) gëtt während der Schreifallokatioun begéint:

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

Schrëtt 3: Wann zpool import klappt mat I/O error oder corrupted data, benotzt TXG Rollback (-F an -T)¶

Wann zwee Drive bannent Sekonne vunenee wärend engem schwéiere Schreifplatz erausgefall sinn, ass déi lescht Transaktiounsgrupp (TXG N) kann iwwer déi iwwerliewend Paritéitstreifen onkomplett sinn, während TXG N-1 oder TXG N-2 (5 bis 15 Sekonnen virdru geschriwwen) ass 100 Prozent intakt am Uberblock Ringbuffer.

1. ** Test eng net-zerstéierend dréchen-run Rollback Virschau (-F -n)***:

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

   Wann ZFS Rapporten Would be able to return pool to its state as of <timestamp>, lafen de read-only rollback Import ouni -n:

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

2. ** Wann -F nach kann net déi lescht Uberblocks Montéierung, Lëscht historeschen Uberblock TXG Zuelen mat zdb an importéiert e spezifescht eeler TXG (-T)***:

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

   Wielt a txg Zuel vun 30 bis 60 Sekonnen virum Crash (z.B. txg = 9481020) an importéiert de Pool gefruer op deem genauen Zäitpunkt am Read-only Modus:

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

Phase 6: Post-Erhuelung Verifizéierung an zukünfteg Kaskaden opzebauen¶

Wann Dir 100 Prozent vun Äre recuperéierten Donnéeën kopéiert hutt /mnt/synology_rescue oder /mnt/zfs_rescue op en onofhängegt Backup-Zil, befollegt dës Hardware- a Konfiguratiounschecklëscht ier Dir Är NAS erëm an de Service setzt:

• ** Kaaft ni all NAS Drive vum selwechten Händler am selwechten Dag **: Drive vun der selwechter Fabrikatiounslot deelen identesch Kappbatches a Firmware, sou datt se innerhalb vun Stonnen noenee während enger Rekonstruktioun falen. Mix Chargen oder Hiersteller (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• ** Benotzt nëmmen NAS / Enterprise fiert mat TLER / SCT ERC aktivéiert (oder Linux erhéijen mdadm SCSI Timeouts fir Desktop Drive) **: Fir Konsumenten an Linux mdadm, benotzt a udev Regel ze erhéijen /sys/block/sdX/device/timeout vun 30 Sekonnen ze 180 Sekonnen also mdadm waart op intern Secteur remapping amplaz vun der fueren erofzesetzen.
• ** Migréieren Arrays mat Drive méi grouss wéi 8 TB vun RAID 5 / SHR-1 / RAIDZ1 zu RAID 6 / SHR-2 / RAIDZ2**: mat 12 TB zu 24 TB fiert, Single-Paritéit Neiopbauzäiten iwwerschreiden 30 Stonnen, mécht Dual-Parity (RAID 6 / SHR-2 / RAIDZ2) wichteg fir e schlechte Secteur während der Resilvering ze iwwerliewen.
• ** Zäitplang all Mount Data Scrubbing (mdadm check / zpool scrub) an erweidert SMART Tester **: monatlecht Scrubbing reparéiert latente Sektorfehler (Current_Pending_Sector) während all Drive online sinn.
• ** Erënneren, datt RAID héich Disponibilitéit ass, ni e Backup **: Follegt der 3-2-1 Backupsatellit Strategie mat enger offline Kopie.

Regional Noutfallnummeren an Agenturprotokoller¶

Späicherausfall, déi Gesondheetsnetzwierker, Noutkommunikatioun oder gesetzlech perséinlech records beaflossen, erfuerderen direkt Eskalatioun:

• Vereenegt Staaten a Kanada: Wielt 911 wann e Stockage Crash Spidol klinesch Systemer auszeschalten (EHR / PACS) oder verschéckt. Rapport NAS-geziilt Ransomware (DeadBolt, LockBit, Akira) zu CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), oder den Canadian Center for Cyber Security (1-833-CYBER-88).
• Vereenegt Kinnekräich: Wielt 999 fir Noutfäll déi d'Liewenssécherheet oder akuter NHS Betreiung beaflossen. Ënnert UK GDPR, beurteelen ob permanent net-gebackupte perséinlechen Dateverloscht d'Notifikatioun vum ICO erfuerdert (0303 123 1113) bannent 72 Stonnen.
• Europäesch Unioun: Wielt 112 an der EU. Entitéite ënner der NIS2-Direktiv musse gréisser operationell Ausbréch op hiren nationalen CSIRT bannent 24 Stonnen mellen, a permanente Verloscht vu perséinlechen Datenverfügbarkeet triggert GDPR Artikel 33 Bericht bannent 72 Stonnen.
• Australien an Neuseeland: Wielt 000 an Australien oder 111 an Neuseeland; Rapport Infrastruktur oder Ransomware NAS Tëschefäll un den ACSC (1300 CYBER1) oder CERT NZ (0800 237 869).
• Indien an Asien-Pazifik: Wielt 112 an Indien fir Noutfall Äntwert; mellt Infrastrukturspäicherzfäll un CERT-In (incident@cert-in.org.in) bannent der obligatorescher 6-Stonne Fënster.

Oft gestallte Froen¶

Firwat gemaach mdadm --assemble --force refuséieren meng RAID 5 Array ze starten mat not enough to start the array?¶

An engem 4-fueren RAID 5 Array, op d'mannst 3 vun 4 fiert muss weiderginn mdadm --assemble --force. Lafen sudo mdadm --examine /dev/sd[a-z]3 fir z'iwwerpréiwen firwat den drëtten Drive refuséiert gouf: entweder Dir hutt de ganzen Disk passéiert amplaz vun der Partition (/dev/sdd amplaz /dev/sdd3), säi Superblock gouf als e markéiert Ersatz duerch eng ënnerbrach Opbau, oder den Auto-Assembler vun Ubuntu gespaart een Drive an en inaktiven /dev/md127 Apparat (run sudo mdadm --stop --scan éischt, dann nees lafen mdadm --assemble --force --readonly).

Wat wann en Drive ugefaang nei opzebauen (Recovery = 12%) ier den zweeten Drive erausgefall ass?¶

Wann Drive 2 gestuerwen ass, hutt Dir en Ersatz Drive 2 agefouert, an um 12% de Fortschrëtt nei opzebauen Drive 3 ass offline erofgaang wéinst engem schlechte Secteur, benotzt net den 12% opgebauten Ersatz Drive 2. Amplaz, klon d'Original Fuert 3 mat ddrescue. Well den Drive 3 komplett aktuell war bis d'Rekonstruktioun bei 12% gestoppt ass, d'Array ze liese-nëmme mat Drive 1 zesummesetzen, ddrescue Klon vum Drive 3, an Drive 4 (loosst Drive 2 eraus) gëtt Iech eng konsequent Array.

Kann ech meng Synology oder QNAP Drive an e fuschneie NAS Chassis setzen wann d'NAS Energieversuergung oder Board stierft?¶

Jo, souwuel Synology (HDD Migratioun) und QNAP (Direkt NAS Migratioun) späichert d'RAID Konfiguratioun op den Drive selwer. Allerdéngs, wann zwee oder méi Drive scho gefall sinn (`Volume Crashed`) ier de Chassis gestuerwen ass, boot se net an engem neien NAS Chassis, well de Migratiounswizard Partitionen iwwerschreiwe kann oder eng zerstéierend Neiopbau ausléisen. Retten d'Donnéeën nëmmen op Ubuntu als éischt.

Wéi weess ech ob e erofgeluede Drive sécher ass fir ze klonen ddrescue versus engem Cleanroom Labo brauchen?¶

Connect den Drive op SATA, schalt et un a lauschtert 10 Sekonnen wärend Dir kuckt sudo dmesg -w. Wann den Drive rhythmesch Klick, Schrauwen oder Buzzende Kläng mécht, dréint erop a dréit zréck erof, oder mellt Kapazitéit als 0 B / 4,1 GB an lsblk, d'Lies-/Schreifkäpp hunn physesch gescheitert: d'Kraaft direkt ofschneiden an e Cleanroom Labo benotzen. Wann de Drive glat dréint, weist seng voll Kapazitéit an lsblk, an nëmmen Logbicher Current_Pending_Sector oder Timeout Feeler, klon et mat ddrescue.

Wat ass de "RAID 5 Write Hole", a wéi mécht ZFS oder Btrfs vermeit et während engem Stroumausfall?¶

An traditionell RAID 5 / RAID 6 ouni Journal, d'Aktualiséierung vun enger Sträif erfuerdert d'Dateblock an d'Paritéitsblock op zwou Disken gläichzäiteg ze schreiwen. Wann d'Muecht an der Mëtt vum Schreiwen feelt, passen d'Donnéeën an d'Paritéit net méi (den Schreift Hole). ZFS (`RAIDZ`) an Btrfs eliminéiert d'Schreiflach mam Copy-on-Write (`CoW`), Schreift all nei Sträif an onbenotzten Blocken an aktualiséiert den Uberblock / Root Pointer nëmmen nodeems de komplette Sträif op der Disk ass.

Kann ech benotzen dmsetup Iwwerlagerungen fir RAID-Parameteren ze testen ouni de gekloonten Drive ze änneren?¶

Jo, Dir kënnt Copy-on-Write erstellen (`CoW`) Iwwerlagerungen uewen op liesbare Loop-Geräter (`losetup --read-only`) benotzt Linux dmsetup (`snapshot` Zil) ënnerstëtzt vu sparse Dateien an /tmp. All schreift aus mdadm --assemble --force oder fsck -y gitt an de Wegwerf /tmp overlay Datei, léisst Iech an 1 Sekonn zrécksetzen wann néideg.

Zesummenhang Guiden¶

• NAS RAID Array degradéiert, Multiple Drive Feeler, an ZFS / Btrfs Erhuelung
• RAID Controller Card Doud, auslännesch Configuratioun Import, a firwat Dir musst ni discs initialize
• Festplack Echec an Daten Erhuelung
• SSD an NVMe plötzlech Liesmodus, 0% Ersatzblocken, an TRIM desaktivéiere Rettung
• Accidental rm -rf oder Shift+Delete op Linux, macOS oder Windows: direkt liesen-nëmmen Remount
• Computer Backups, d'3-2-1 Strategie, a Katastrophen Erhuelung
• Noutfall Zuelen no Land

Quellen an offiziell Orientatioun¶

• Linux Raid Wiki (raid.wiki.kernel.org) & D'Linux Kernel Organisatioun: Recuperéieren e Failed Software RAID (mdadm --assemble --force --readonly an Event Counter Mismatches).
• Free Software Foundation (GNU Project): GNU ddrescue Handbuch: Forensic Data Recovery from Failing Media.
• OpenZFS Dokumentatioun (openzfs.github.io): ZFS Pool Import Erhuelung (zpool import -F, Read-Only Imports, an zdb Inspektioun).
• Synology Inc.: Synology Knowledge Center: Wéi kann ech e PC benotzen fir Daten ze recuperéieren wann meng Synology NAS Fehlfunktiounen (mdadm + LVM2 Montage).
• National Institut fir Standards an Technologie (NIST) (Vereenegt Staaten): * Spezial Publikatioun 800-209: Sécherheet Richtlinnen fir Stockage Infrastruktur *.