RAID 5, RAID 6 oder ZFS Multiple Drive Drop: Wiederherstellen eines abgestürzten Synology-, QNAP- oder TrueNAS-Arrays ohne Zerstörung der Parität¶

Hören Sie eine Synology DiskStation, eine QNAP TS-Serie, einen TrueNAS-Server oder Linux mdadm Wenn der Speicherserver ununterbrochen piept und dabei Volume abgestürzt, Pool beeinträchtigt/fehlerhaft oder Mehrere Laufwerke getrennt meldet, handelt es sich um einen Speichernotfall mit hohem Risiko. Wenn ein einzelnes Laufwerk ausfällt RAID 5, Synology Hybrid RAID (SHR-1), oder ZFS RAIDZ1 Pool läuft das Array ohne Redundanz (degraded Zustand) und rekonstruiert fehlende Blöcke im laufenden Betrieb, indem jede verbleibende Festplatte parallel gelesen wird. Wenn ein zweites Laufwerk Stunden später offline geht oder einen nicht behebbaren Lesefehler auslöst (URE) In der Mitte einer Neuerstellung auf einer Ersatzfestplatte bricht die Paritätsberechnung zusammen und der Speicherpool geht vollständig offline. In Panik geratene Administratoren zerstören oft Terabytes an wiederherstellbaren Daten in den nächsten sechzig Sekunden, indem sie auf Initialisieren klicken und das Array neu erstellen mdadm --createoder das Erzwingen einer sofortigen Online-Wiederherstellung auf fehlerhafter Hardware. Wenn Ihre Hardware-RAID-Controllerkarte selbst und nicht die Festplatten ausgefallen sind, wechseln Sie zu Ausfall der RAID-Controllerkarte, Import fremder Konfigurationen und warum Sie niemals Festplatten initialisieren dürfen; Wenn eine einzelne Festplatte klickt oder sich nicht hochfahren lässt, wenden Sie sich an uns Festplattenausfall und Datenwiederherstellung oder NAS-RAID-Array beeinträchtigt, mehrere Laufwerke ausgefallen und ZFS/Btrfs-Wiederherstellung. Wenn dieser Speicherfehler die medizinische Bildgebung im Krankenhaus deaktiviert (PACS), Notrufzentrale oder Lebenssicherheitsinfrastruktur, rufen Sie Ihre örtliche Notrufnummer an (911 in den Vereinigten Staaten und Kanada, 112 in der gesamten Europäischen Union, 999 im Vereinigten Königreich) oder schauen Sie in unserem Verzeichnis nach Notrufnummern.

Tun Sie dies jetzt¶

1. STOPPEN Sie und klicken Sie NICHT auf „Initialisieren“, „Pool erstellen“, „Reparieren“ oder „Ausführen“. mdadm --create auf den gelöschten Laufwerken: Klicken Sie auf „Initialisieren“ in Synology DSM oder QNAP QTS oder führen Sie es aus mdadm --create schreibt unter Linux brandneue Superblöcke und beginnt, Paritätsstreifen auf allen Mitgliedsfestplatten auf Null zu setzen. Ein heruntergefallenes Laufwerk hält normalerweise noch 99.99% Ihrer Dateien sind intakt und werden nur durch den Ereigniszähler als nicht synchron markiert.
2. Fahren Sie das NAS oder den Server sauber herunter (oder ziehen Sie den Strom ab, wenn er sich aktiv über klickende Laufwerke hinweg wiederherstellt), um die Ereigniszähler einzufrieren: Jede Sekunde, in der das Array in einem teilweise herabgesetzten Zustand online bleibt, erhöht das Betriebssystem den Superblock Update Time und Events Zähler auf den verbleibenden Festplatten, während die gelöschte Festplatte bei einer älteren Ereignisnummer eingefroren bleibt. Wenn das NAS versucht, eine automatische Wiederherstellung auf einem Laufwerk mit fehlerhaften Sektoren durchzuführen, kann das weitere Auslesen dieses Laufwerks dazu führen, dass die Beschichtung der Magnetplatte beschädigt wird (head crash).
3. Beschriften Sie jeden Laufwerksschachtsteckplatz mit einem physischen Marker oder Klebeband (Bay 1, Bay 2, Bay 3, Bay 4), bevor Sie ein Fach herausziehen: Unter Linux mdadm, LVM2, und ZFS Verfolgen Sie die Laufwerksreihenfolge anhand der UUID in jedem Partitions-Superblock, älteren Hardware-Controllern und im Handbuch dmsetup Tabellenrekonstruktionen erfordern die genaue physische Slot-Reihenfolge (0, 1, 2, 3...).
4. Versuchen Sie niemals eine Bergung, einen gewaltsamen Zusammenbau usw fsck direkt auf den ursprünglichen Mitgliedslaufwerken; Klonen Sie jedes Laufwerk Bit für Bit mit ddrescue zuerst: Vor dem Laufen mdadm --assemble --force oder zpool import -F, schließen Sie jede Mitgliedsfestplatte über direktes SATA/SAS an eine Linux-Workstation an (niemals eine billige USB-Brücke, die sich versteckt). SMART oder SCT ERC Timeouts) und klonen Sie es mit ddrescue auf fehlerfreie Ersatzlaufwerke oder Image-Dateien.
5. Erzwingen Sie die Assemblierung des geklonten Arrays ausschließlich im READ-ONLY-Modus (--readonly oder -o readonly=on): Beim Zusammenbau mdadm Arrays, deren Ereigniszähler während eines gleichzeitigen Ausfalls mehrerer Laufwerke auseinandergedriftet sind, werden immer bestanden --readonly (mdadm --assemble --force --readonly /dev/md0 ...). Im schreibgeschützten Modus auch nicht mdadm, LVM2, ext4, Btrfs, noch ZFS kann Paritätsstreifen überschreiben oder ein destruktives Journal wiedergeben.
6. Kopieren Sie Ihre wichtigsten Daten sofort nach der schreibgeschützten Bereitstellung auf ein unabhängiges externes Sicherungslaufwerk: Evakuieren Sie Ihre Dokumente, Datenbanken, virtuellen Maschinen und Fotos zunächst auf ein separates Laufwerk, löschen Sie dann die Datenträger und testen Sie sie von Grund auf.

Entscheidungsbaum: Notfall-Triage für RAID mit mehreren Laufwerken und ZFS-Pool¶

Verwenden Sie dieses Flussdiagramm, um festzustellen, ob Ihr Array einen logischen Timeout-Abbruch erlitten hat (TLER / ERC Nichtübereinstimmung), ein echter fehlerhafter Sektorfehler auf mehreren Festplatten während der Neuerstellung oder eine ZFS-Transaktionsgruppe (TXG) Fehler:

flowchart TD
    Start["RAID 5/RAID 6/SHR/ZFS-Pool stürzte ab, nachdem mehr als 2 Laufwerke ausgefallen waren"] --> StopIO["Stoppen Sie alle Neuaufbauten und schalten Sie das NAS sofort aus"]
    StopIO --> Label["Beschriften Sie jeden Laufwerksschacht mit der Schachtnummer (Schacht 1 bis Schacht N)"]
    Label --> ConnectLinux["Verbinden Sie Mitgliedslaufwerke über Direct SATA/HBA mit dem Ubuntu Linux Rescue Host"]

    ConnectLinux --> CheckSmart["Überprüfen Sie SMART und Metadaten schreibgeschützt: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Klicken Laufwerke in dmesg, lassen sich nicht drehen oder werden sie offline geschaltet?"}

    PhysicalHealth -->|"Ja: Mechanischer Fehler/Kopffehler bei mehr als 2 Laufwerken in RAID 5"| Cleanroom["STOPPEN Sie die Stromversorgung der Festplatten -> Senden Sie sie an das Cleanroom Data Recovery Lab"]
    PhysicalHealth -->|"Nein: Alle Laufwerke starten (möglicherweise stehen fehlerhafte Sektoren oder Zeitüberschreitungen an)"| CloneAll["Klonen Sie jedes Mitgliedslaufwerk mit GNU ddrescue (Forward Pass -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["Trennen Sie die Originallaufwerke und arbeiten Sie ausschließlich mit geklonten Festplatten/Images"]
    DisconnectOrig --> ArrayType{"Welche Speicherarchitektur wird verwendet?"}

    ArrayType -->|"Synology DSM (SHR / Classic RAID)"| SynologyFlow["Untersuchen Sie Ereignisse über mdadm --examine -> Force-Assemble Read-Only -> Activate LVM2/Btrfs Read-Only"]
    ArrayType -->|"QNAP QTS (HAL LVM Thin/Thick RAID)"| QnapFlow["mdadm schreibgeschützt zusammenstellen -> DRBD-Ebene aktivieren, falls vorhanden -> Benutzerdefinierte QNAP LVM2-Superblöcke scannen"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Mirror)"| ZfsFlow["Führen Sie zpool import -d /dev/disk/by-id -> Schreibgeschützt mit Rollback importieren aus: zpool import -f -o readonly=on -F"]
    ArrayType -->|"Standard-Linux-mdadm"| LinuxFlow["Ereigniszähler vergleichen -> mdadm --assemble --force --readonly ausführen -> Dateisystem mit -o ro,noload mounten"]

Phase 1: Warum das Erzwingen einer Neuerstellung Daten zerstört (Die URE- und Same-Batch-Kaskade)¶

Um zu verstehen, warum das Klicken auf Reparieren/Neuaufbau oder das Ersetzen eines Laufwerks und das Warten von 36 Stunden oft zu einem Totalabsturz des Arrays führt, müssen Sie verstehen, wie die Paritätsrekonstruktion alternde magnetische Medien belastet und warum Consumer-Desktop-Laufwerke aus NAS-Gehäusen herausfallen.

1. Die mathematische Realität nicht behebbarer Lesefehler (UREs) während einer RAID 5- oder RAIDZ1-Neuerstellung¶

Im 4er-Antrieb RAID 5 oder ZFS RAIDZ1 Pool-, Daten- und Paritätsblöcke (P) werden mithilfe eines Exklusiv-ODER () über alle vier Festplatten verteilt.XOR) Berechnung (D1 XOR D2 XOR D3 = P). Wenn Laufwerk 2 vollständig ausfällt, hat das Array keine verbleibende Redundanz. Um Laufwerk 2 auf einer brandneuen Ersatzfestplatte wiederherzustellen, muss das NAS jeden einzelnen Sektor von Byte 0 bis zum Ende der Festplatte auf Laufwerk 1, Laufwerk 3 und Laufwerk 4 gleichzeitig lesen (Reconstructed D2 = D1 XOR D3 XOR P).

Bedenken Sie, was passiert, wenn es sich bei diesen Laufwerken um vier 12-Terabyte-Festplatten (12.000 Gigabyte) handelt, die vor vier Jahren aus derselben Produktionscharge gekauft wurden: - Für die Wiederherstellung von 12 Terabyte ist ein Lesen erforderlich 36 terabytes (2.88 x 1014 einzelne Bits) kontinuierlich über 24 bis 48 Stunden bei maximaler thermischer und mechanischer Belastung. - Bei Consumer-Festplatten tritt in der Regel ein nicht behebbarer Lesefehler auf (URE) Spezifikation von 1 error in 1014 bits (12.5 terabytes) und alternde Laufwerke entwickeln stille latente Sektorfehler (Current_Pending_Sector) in kalten Bereichen der Festplatte, die seit Jahren nicht gelesen wurden. - In dem Moment, in dem Laufwerk 3 auf einen einzigen unlesbaren fehlerhaften Sektor von 4 Kilobyte (0,004 Megabyte) trifft, während Laufwerk 2 noch fehlt oder zur Hälfte neu erstellt wurde, wird der XOR Gleichung hat zwei Unbekannte (D2 und D3).

2. Warum Desktop-Laufwerke ohne TLER / SCT ERC Werde über einen fehlerhaften Sektor hinaus komplett rausgeschmissen¶

Hier ist die Falle, die bei Synology, QNAP und Linux zu katastrophalen Ausfällen mehrerer Laufwerke führt 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.                 |
+-------------------------------------------------------------------------+

Beachten Sie, was tatsächlich passiert ist: Laufwerk 3 ist nicht tot. Es hat 99.999999% fehlerfreie Sektoren und nur 1 oder 2 nicht lesbare 4-Kilobyte-Sektoren (8 kilobytes aus 12 terabytes). Doch weil mdadm Laufwerk 3 aufgrund eines Befehls-Timeouts von 30 Sekunden aus dem Array geworfen hat, wird das gesamte Volume als abgestürzt angezeigt. Wenn Sie Laufwerk 3 mit klonen ddrescue (wodurch die 8 Kilobyte fehlerhafter Sektoren elegant übersprungen und die anderen 12 Terabyte kopiert werden) und das Array zwangsweise schreibgeschützt zusammenzustellen, stellen Sie praktisch 100 Prozent Ihrer Dateien wieder her.

3. Warum Sie NIEMALS rennen dürfen mdadm --create oder klicken Sie auf „Initialisieren“¶

Wenn ein Array ausfällt, kursieren im Internet zwei destruktive Mythen: - Mythos 1: „Erstellen Sie das Array mit genau derselben Laufwerksreihenfolge neu mit mdadm --create." Sogar mit --assume-clean, moderne Versionen von mdadm Standardmäßig ist es anders Data Offset Werte abhängig vom Kernel und mdadm Veröffentlichung (2048 sectors vs 262144 sectors). Wann mdadm --create schreibt eine neue Version 1.2 Superblock mit dem falschen Offset oder mit einer nicht übereinstimmenden Blockgröße überschreibt den LVM2 physischer Datenträger-Header oder ext4 Superblock an der Vorderseite des Volumens. - Mythos 2: „Ziehen Sie das zweite Laufwerk heraus, das gerade heruntergefallen ist, schließen Sie es wieder an und klicken Sie auf „Reparieren.“ Wenn Laufwerk 1 vor drei Tagen ausgefallen ist (seine Daten sind also 3 Tage veraltet) und Laufwerk 3 vor 10 Minuten ausgefallen ist (seine Daten sind also aktuell), führt das Ziehen und erneute Einsetzen des falschen Laufwerks oder das Erzwingen einer Neuerstellung mit Laufwerk 1 als „aktiv“ und Laufwerk 3 als „Ersatz“ dazu, dass das NAS das aktuelle Array mit 3 Tage alten veralteten Paritätsstreifen überschreibt, wodurch jedes Verzeichnis und jede Datei beschädigt wird in den letzten 72 Stunden geändert.

Phase 2: Inspektion von Superblöcken und Event Zähler sicher auf einem Linux-Rescue-Host installieren¶

Um ein abgestürztes Synology-, QNAP-, TrueNAS- oder Linux-Array sicher zu retten, entfernen Sie alle Mitgliedslaufwerke (nachdem Sie ihre Schachtnummern beschriftet haben) und schließen Sie sie an einen Desktop-PC oder Server an, auf dem Ubuntu 22.04 LTS / 24.04 LTS ausgeführt wird (auch wenn Sie von einem Live-USB-Stick gebootet haben).

Schritt 1: Installieren Sie das forensische Rettungs-Toolkit in Ubuntu¶

Öffnen Sie ein Terminal auf Ihrer Ubuntu-Rettungsmaschine und installieren Sie die erforderlichen Dienstprogramme:

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

Schritt 2: Ordnen Sie jeden Laufwerksbuchstaben, jede Seriennummer und jedes Partitionslayout zu¶

Listen Sie alle angeschlossenen Blockgeräte und ihre Hardware-Seriennummern auf, damit Sie eine Rettungsdiskette nie mit einer Quell-NAS-Festplatte verwechseln:

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

Schauen Sie sich die Partitionstabelle eines typischen Synology DSM-, QNAP- oder TrueNAS-Laufwerks an:

Schritt 3: Überprüfen mdadm --examine um zu sehen, warum das Array abgestürzt ist (The Event Counter Matrix)¶

Auf einer Synology, QNAP oder Linux mdadm Array, untersuchen Sie die RAID-Metadaten auf den Benutzerdatenpartitionen (z. B. Partition 3 auf /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) ohne etwas zu montieren oder zu verändern:

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

Vergleichen Sie die Ausgabe aller vier Laufwerke:

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

Lesen Sie diese forensische Geschichte sorgfältig durch: 1. /dev/sdc3 (Device Role 1) hat eine Events Anzahl von 479012 von vor zwei Tagen (Oct 29). Dieses Laufwerk fiel vor zwei Tagen aus und ist seitdem offline. 2. /dev/sdb3 (Role 0) und /dev/sde3 (Role 3) beide haben Events : 482190 bei 14:12:09. 3. /dev/sdd3 (Role 2) hat Events : 482188 bei 14:12:04, nur 5 Sekunden und 2 Ereignisse dahinter sdb3 und sde3. 4. Schlussfolgerung: Sie müssen das Array mit ** rekonstruierensdb3 (Role 0), sdd3 (Role 2), und sde3 (Role 3)** (deren Ereigniszähler nur 2 Ticks voneinander entfernt sind), beim Gehen sdc3 (Role 1) komplett aus.

Phase 3: Klonen jedes Laufwerks Bit für Bit mit GNU ddrescue¶

Vor dem Laufen mdadm --assemble --force oder zpool import -F, klonen Sie jedes erforderliche Laufwerk (insbesondere das Laufwerk, das aufgrund fehlerhafter Sektoren als letztes ausgefallen ist, z /dev/sdd im obigen Beispiel) auf ein fehlerfreies leeres Laufwerk mit gleicher oder größerer Kapazität oder in ein Rohlaufwerk .img Datei auf einem großen Speichervolumen.

Schritt 1: Warum ddrescue mit einem Mapfile ist zwingend erforderlich¶

Standard dd bricht beim ersten fehlerhaften Sektor ab, oder mit conv=noerror,sync verschwendet Stunden damit, seine Leseköpfe über eine beschädigte Spur zu schleifen, während Megabyte angrenzender guter Daten mit Nullen aufgefüllt werden. GNU ddrescue arbeitet in intelligenten mehrstufigen Durchgängen: 1. Durchlauf 1 (Kopierphase): Kopiert alle fehlerfreien, schnell reagierenden Bereiche der Festplatte mit voller sequenzieller Geschwindigkeit (150 MB/s zu 250 MB/s) und überspringt sofort alle langsamen oder unlesbaren Blöcke, damit das Laufwerk nicht überhitzt oder abstürzt, bevor Sie das erhalten 99.99% gute Daten. 2. Durchlauf 2 (Trimmphase): Liest bis zu den genauen Kanten jedes fehlerhaften Blocks sowohl von der Vorder- als auch von der Rückseite (reverse direction), um den beschädigten Bereich bis auf den genauen 4-Kilobyte-Hardwaresektor zu isolieren. 3. Durchlauf 3 (Scraping-Phase): Versucht die beschädigten Sektoren sanft erneut, ohne den Bus unnötig zurückzusetzen.

Schritt 2: Führen Sie die 2-Stufe aus ddrescue Klonbefehl¶

Geben Sie immer eine Mapfile an (sdd_rescue.map). Wenn das sterbende Quelllaufwerk die Verbindung trennt und einen Aus- und Wiedereinschaltvorgang erfordert, ddrescue liest die Mapdatei und setzt genau dort fort, wo sie aufgehört hat, ohne einen einzigen bereits kopierten Sektor erneut zu lesen:

# 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: Rekonstruktion von Synology DSM (SHR-1 / SHR-2 / Classic RAID), QNAP und Linux mdadm¶

Sobald Ihre geklonten Laufwerke (oder schreibgeschützten Loop-Geräte) bereit sind und die ursprünglichen NAS-Laufwerke sicher vom Stromnetz getrennt sind, befolgen Sie die genaue zerstörungsfreie Montagesequenz für Ihre Plattform.

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

1. Stoppen Sie jede teilweise md Array, das Ubuntu möglicherweise zu starten versucht hat:

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

2. Erzwingen Sie den Zusammenbau der geklonten Partitionen (sdb3, sdd3, sde3, das längst Verstorbene weglassend sdc3) im streng schreibgeschützten Modus:

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

   Sehen Sie sich die Ausgabe an: mdadm werde berichten forcing event count in /dev/sdd3(2) from 482188 up to 482190 und mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Stellen Sie sicher, dass das Array aktiv und markiert ist (auto-read-only) oder (read-only):

   cat /proc/mdstat
   

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

SHR von Synology (Synology Hybrid RAID) ist 100 Prozent Standard-Linux mdadm + LVM2 (Logical Volume Manager): - Wenn alle Laufwerke in einem SHR-Pool die gleiche Größe haben (z. B. vier 8-Terabyte-Laufwerke), erstellt Synology ein einziges mdadm RAID 5-Partition (md2 auf Partition 3 jedes Laufwerks) und platziert eine LVM2 Datenträgergruppe (vg1000 oder vg1) oben drauf md2. - Wenn Laufwerke in einem SHR-Pool unterschiedliche Größen haben (z. B. zwei 8-Terabyte-Laufwerke und zwei 16-Terabyte-Laufwerke), erstellt Synology zwei separate mdadm Arrays: md2 über Partition 5 (8 TB Slice auf allen 4 Laufwerken in RAID 5) und md3 über Partition 6 (die restlichen 8 TB Slice auf den beiden 16-TB-Laufwerken in RAID 1) und verbindet sich dann md2 + md3 in eine einzige LVM2 Volumengruppe (vg1000).

So mounten Sie ein Synology SHR-Volume schreibgeschützt unter Ubuntu nach der erzwungenen Assemblierung /dev/md2 (und /dev/md3 bei gemischter SHR-Größe): 1. Suchen Sie nach den physischen Synology LVM2-Volumes und Volume-Gruppen:

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 Freigabeordner-Verschlüsselung (eCryptfs)¶

• Verschlüsselung freigegebener Ordner (@sharename@ Ordner mit ECRYPTFS_FNEK_ENCRYPTED... Dateinamen): Kopieren Sie das Ganze @encrypted_share@ Ordner aus /mnt/synology_rescue Zuerst mounten und entschlüsseln Sie es dann unter Ubuntu mit Ihrem Synology-Verschlüsselungskennwort 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+ Full Volume Encryption (LUKS): Wenn /dev/vg1000/lv zeigt TYPE="crypto_LUKS" in blkid, entsperren Sie es schreibgeschützt mit dem .rkey Wiederherstellungsschlüsseldatei, die beim Erstellen des Volumes heruntergeladen wurde:

  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 und DRBD Schicht)¶

Moderne QNAP NAS-Geräte (QTS 4.3+ / 5.x) einen internen Einzelknoten einfügen DRBD Gerät (/dev/drbd1) zwischen /dev/md1 und die LVM2 Volumengruppe (vg1). 1. Zuerst die QNAP-Datenpartitionen zwangsweise zusammensetzen (/dev/sd[b-e]3) schreibgeschützt in /dev/md1:

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

Phase 5: Rettung von TrueNAS und Linux ZFS Pools (RAIDZ1, RAIDZ2, RAIDZ3)¶

Wenn auf Ihrem Speicherserver TrueNAS CORE, TrueNAS SCALE, Proxmox VE oder Ubuntu ZFS ausgeführt wird, wird die Wiederherstellung nicht verwendet mdadm. Stattdessen kombiniert ZFS den Volume-Manager und Copy-on-Write (CoW) Dateisystem in eine einzige Transaktionsarchitektur, die auf Uberblocks und sequentiellen Transaktionsgruppen (TXGs).

Schritt 1: Überprüfen Sie die 4 ZFS-vdev-Beschriftungen (L0, L1, L2, L3) auf jeder geklonten Festplatte¶

Jede ZFS-Mitgliedspartition speichert vier identische Kopien der Poolkonfiguration und ein Array der letzten 128 Uberblocks (zwei Etiketten an der Vorderseite der Partition, L0 und L1, und zwei Etiketten ganz am Ende, L2 und L3). Lauf zdb -l auf jeder geklonten Partition, um den Poolstatus und die höchste festgeschriebene Transaktionsgruppe zu überprüfen (txg):

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

Vergleichen Sie die txg: Zahlen auf allen geklonten Laufwerken. Genau wie mdadm's Events Zähler: Wenn eine Festplatte 5 Minuten vor einem Stromausfall oder einem Ausfall der zweiten Festplatte ausgefallen ist, ist dies der Fall txg wird etwas niedriger sein als die der übrigen Festplatten.

Schritt 2: Importieren Sie den ZFS-Pool im ausschließlich schreibgeschützten Modus (-o readonly=on)¶

Überprüfen Sie zunächst importierbare Pools, ohne etwas über zu mounten sudo zpool import -d /dev/disk/by-id. Importieren Sie niemals einen beschädigten oder auf mehreren Festplatten gelöschten ZFS-Pool im Lese-/Schreibmodus. Beim Import mit -o readonly=on, ZFS versucht nicht, einen Resilver zu initiieren, schreibt keine neuen Uberblocks und kann den Kernel nicht in Panik versetzen, wenn eine beschädigte Space Map (spacemap) wird während der Schreibzuweisung angetroffen:

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

Schritt 3: Wenn zpool import scheitert mit I/O error oder corrupted data, verwenden Sie TXG Rollback (-F und -T)¶

Wenn zwei Laufwerke während eines starken Schreibstoßes innerhalb von Sekunden ausgefallen sind, wird die allerneueste Transaktionsgruppe (TXG N) kann über die verbleibenden Paritätsstreifen hinweg unvollständig sein, während TXG N-1 oder TXG N-2 (5 bis 15 Sekunden früher geschrieben) ist im Uberblock-Ringpuffer zu 100 Prozent intakt.

1. Testen Sie eine zerstörungsfreie Probelauf-Rollback-Vorschau (-F -n):

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

   Wenn ZFS meldet Would be able to return pool to its state as of <timestamp>, führen Sie den schreibgeschützten Rollback-Import ohne aus -n:

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

2. Wenn -F Die neuesten Uberblocks können immer noch nicht gemountet werden. Listen Sie historische Uberblock-TXG-Nummern mit auf zdb und importieren Sie eine bestimmte ältere TXG (-T):

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

   Wählen Sie ein txg Zahl von 30 bis 60 Sekunden vor dem Absturz (z. B. txg = 9481020) und importieren Sie den zu genau diesem Zeitpunkt eingefrorenen Pool im schreibgeschützten Modus:

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

Phase 6: Überprüfung nach der Wiederherstellung und Verhinderung zukünftiger Wiederherstellungskaskaden¶

Sobald Sie 100 Prozent Ihrer wiederhergestellten Daten kopiert haben /mnt/synology_rescue oder /mnt/zfs_rescue auf ein unabhängiges Backup-Ziel kopieren möchten, befolgen Sie diese Hardware- und Konfigurationscheckliste, bevor Sie Ihr NAS wieder in Betrieb nehmen:

• Kaufen Sie niemals alle NAS-Laufwerke am selben Tag beim selben Händler: Laufwerke aus derselben Produktionscharge haben identische Kopfchargen und Firmware, was dazu führt, dass sie bei einem Wiederaufbau innerhalb weniger Stunden ausfallen. Chargen oder Hersteller mischen (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Verwenden Sie nur NAS/Enterprise-Laufwerke mit TLER / SCT ERC aktiviert (oder Linux hochfahren). mdadm SCSI-Timeouts für Desktop-Laufwerke): Für Consumer-Laufwerke unter Linux mdadm, verwenden Sie a udev Regel zu erhöhen /sys/block/sdX/device/timeout von 30 Sekunden zu 180 Sekunden also mdadm wartet auf die Neuzuordnung des internen Sektors, anstatt das Laufwerk zu löschen.
• Arrays mit Laufwerken migrieren, die größer sind als 8 TB von RAID 5 / SHR-1 / RAIDZ1 zu RAID 6 / SHR-2 / RAIDZ2: Mit 12 TB zu 24 TB Bei Festplatten übersteigen die Wiederherstellungszeiten bei Single-Parity 30 Stunden, sodass Dual-Parity (RAID 6 / SHR-2 / RAIDZ2) wichtig, um einen fehlerhaften Sektor während der Neuversilberung zu überstehen.
• Planen Sie monatlich Data Scrubbing (mdadm check / zpool scrub) und Erweitert SMART Tests: Monatliches Scrubben repariert latente Sektorfehler (Current_Pending_Sector), während alle Laufwerke online sind.
• Denken Sie daran, dass es sich bei RAID um Hochverfügbarkeit und niemals um ein Backup handelt: Befolgen Sie die 3-2-1-Backup-Strategie mit einer Offline-Kopie.

Regionale Notrufnummern und Behördenprotokolle¶

Speicherausfälle, die Gesundheitsnetzwerke, Notfallkommunikation oder gesetzlich vorgeschriebene persönliche Daten betreffen, erfordern eine sofortige Eskalation:

• USA und Kanada: Wählen Sie 911 wenn ein Speicherabsturz die klinischen Systeme des Krankenhauses lahmlegt (EHR / PACS) oder Versand. Auf NAS ausgerichtete Ransomware melden (DeadBolt, LockBit, Akira) bis CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov) oder das Canadian Center for Cyber Security (1-833-CYBER-88).
• Vereinigtes Königreich: Wählen Sie 999 für Notfälle, die die Lebenssicherheit oder die akute NHS-Versorgung beeinträchtigen. Beurteilen Sie gemäß der britischen DSGVO, ob ein dauerhafter, nicht gesicherter Verlust personenbezogener Daten eine Benachrichtigung des ICO erfordert (0303 123 1113) innerhalb von 72 Stunden.
• Europäische Union: Wählen Sie 112 EU-weit. Unternehmen im Rahmen der NIS2-Richtlinie müssen größere Betriebsausfälle innerhalb von 24 Stunden an ihr nationales CSIRT melden, und ein dauerhafter Verlust der Verfügbarkeit personenbezogener Daten löst eine Meldung gemäß DSGVO Artikel 33 innerhalb von 72 Stunden aus.
• Australien und Neuseeland: Wählen Sie 000 in Australien oder 111 in Neuseeland; Melden Sie Infrastruktur- oder Ransomware-NAS-Vorfälle dem ACSC (1300 CYBER1) oder CERT NZ (0800 237 869).
• Indien und Asien-Pazifik: Wählen Sie 112 in Indien für Notfallmaßnahmen; Melden Sie Infrastrukturspeichervorfälle an CERT-In (incident@cert-in.org.in) innerhalb des obligatorischen 6-Stunden-Fensters.

Häufig gestellte Fragen¶

Warum? mdadm --assemble --force Ich weigere mich, mein RAID 5-Array damit zu starten not enough to start the array?¶

Im 4er-Antrieb RAID 5 Array, zumindest 3 von 4 Laufwerken muss weitergegeben werden mdadm --assemble --force. Lauf sudo mdadm --examine /dev/sd[a-z]3 Um zu überprüfen, warum das dritte Laufwerk abgelehnt wurde: Entweder haben Sie die gesamte Festplatte statt der Partition übergeben (/dev/sdd statt /dev/sdd3), sein Superblock wurde als a markiert Ersatz durch eine unterbrochene Neuerstellung oder durch den automatischen Assembler von Ubuntu wurde ein Laufwerk in einen inaktiven Zustand gesperrt /dev/md127 Gerät (ausführen sudo mdadm --stop --scan Zuerst, dann erneut ausführen mdadm --assemble --force --readonly).

Was passiert, wenn ein Laufwerk mit der Wiederherstellung beginnt (Recovery = 12%), bevor das zweite Laufwerk ausfiel?¶

Wenn Laufwerk 2 ausgefallen ist, haben Sie ein Ersatzlaufwerk 2 eingesetzt und bei 12 % Fortschritt beim Wiederherstellen. Laufwerk 3 ist aufgrund eines fehlerhaften Sektors offline gegangen. Verwenden Sie nicht das zu 12 % überholte Ersatzlaufwerk 2. Klonen Sie stattdessen das Original Laufwerk 3 mit ddrescue. Da Laufwerk 3 bis zum Stoppen der Wiederherstellung bei 12 % vollständig aktuell war, wurde die schreibgeschützte Zusammenstellung des Arrays unter Verwendung von Laufwerk 1 erzwungen ddrescue Klon von Laufwerk 3 und Laufwerk 4 (wobei Laufwerk 2 weggelassen wird) erhalten Sie ein konsistentes Array.

Kann ich meine Synology- oder QNAP-Laufwerke in ein brandneues NAS-Gehäuse einbauen, wenn das NAS-Netzteil oder die Platine defekt ist?¶

Ja, sowohl Synology (HDD-Migration) und QNAP (Direkte NAS-Migration) speichern die RAID-Konfiguration auf den Laufwerken selbst. Allerdings wenn bereits zwei oder mehr Laufwerke ausgefallen sind (`Volume Crashed`), bevor das Gehäuse kaputt ist, starten Sie sie nicht in einem neuen NAS-Gehäuse, da der Migrationsassistent möglicherweise Partitionen überschreibt oder eine destruktive Neuerstellung auslöst. Speichern Sie die Daten zunächst schreibgeschützt unter Ubuntu.

Woher weiß ich, ob ein gelöschtes Laufwerk sicher zum Klonen geeignet ist? ddrescue im Gegensatz zur Notwendigkeit eines Reinraumlabors?¶

Schließen Sie das Laufwerk an SATA an, schalten Sie es ein und hören Sie beim Anschauen 10 Sekunden lang zu sudo dmesg -w. Wenn das Laufwerk rhythmische Klick-, Kratz- oder Summgeräusche von sich gibt, sich hoch- und runterdreht oder die Kapazität als meldet 0 B / 4,1 GB in lsblk, die Lese-/Schreibköpfe sind physisch ausgefallen: Schalten Sie sofort die Stromversorgung aus und wenden Sie sich an ein Reinraumlabor. Wenn sich das Laufwerk reibungslos dreht, zeigt es seine volle Kapazität an lsblk, und nur Protokolle Current_Pending_Sector oder Timeout-Fehler, klonen Sie es mit ddrescue.

Was ist das „RAID 5 Write Hole“ und wie funktioniert es? ZFS oder Btrfs während eines Stromausfalls vermeiden?¶

Auf traditionell RAID 5 / RAID 6 Ohne Journal erfordert die Aktualisierung eines Stripes das gleichzeitige Schreiben des Datenblocks und des Paritätsblocks auf zwei Festplatten. Wenn die Stromversorgung während des Schreibens ausfällt, stimmen Daten und Parität nicht mehr überein (die Schreiben Sie Loch). ZFS (`RAIDZ`) und Btrfs Beseitigen Sie die Schreiblücke mit Copy-on-Write (`CoW`), jeden neuen Stripe in ungenutzte Blöcke schreiben und den Uberblock/Root-Zeiger erst aktualisieren, nachdem der vollständige Stripe auf der Festplatte ist.

Kann ich verwenden dmsetup Overlays zum Testen von RAID-Parametern, ohne die geklonten Laufwerke zu ändern?¶

Ja, Sie können Copy-on-Write erstellen (`CoW`) Overlays über schreibgeschützten Loop-Geräten (`losetup --read-only`) unter Linux dmsetup (`snapshot` target), unterstützt durch Sparse-Dateien in /tmp. Jeder schreibt von mdadm --assemble --force oder fsck -y Gehen Sie in den Einwegartikel /tmp Overlay-Datei, sodass Sie bei Bedarf in 1 Sekunde zurücksetzen können.

Verwandte Leitfäden¶

• NAS-RAID-Array beeinträchtigt, mehrere Laufwerke ausgefallen und ZFS/Btrfs-Wiederherstellung
• Ausfall der RAID-Controllerkarte, Import fremder Konfigurationen und warum Sie niemals Festplatten initialisieren dürfen
• Festplattenausfall und Datenwiederherstellung
• Plötzlicher SSD- und NVMe-Nur-Lese-Modus, 0 % Ersatzblöcke und TRIM-Deaktivierung der Rettung
• Versehentliches „rm -rf“ oder „Umschalt+Entf“ unter Linux, macOS oder Windows: sofortiges schreibgeschütztes Remounten
• Computer-Backups, die 3-2-1-Strategie und Disaster Recovery
• Notrufnummern nach Ländern

Quellen und offizielle Anleitung¶

• Linux-Raid-Wiki (raid.wiki.kernel.org) & Die Linux-Kernel-Organisation: Wiederherstellen eines ausgefallenen Software-RAID (mdadm --assemble --force --readonly und Nichtübereinstimmungen der Ereigniszähler).
• Free Software Foundation (GNU Project): GNU ddrescue Handbuch: Forensische Datenwiederherstellung von fehlerhaften Medien.
• OpenZFS-Dokumentation (openzfs.github.io): ZFS-Pool-Importwiederherstellung (zpool import -F, schreibgeschützte Importe und zdb Inspektion).
• Synology Inc.: Synology Knowledge Center: Wie kann ich einen PC verwenden, um Daten wiederherzustellen, wenn mein Synology NAS nicht richtig funktioniert (mdadm + LVM2 Montage).
• Nationales Institut für Standards und Technologie (NIST) (Vereinigte Staaten): Sonderpublikation 800-209: Sicherheitsrichtlinien für die Speicherinfrastruktur.