RAIDZ1 vs RAID 5: Was passiert wirklich bei der Datenwiederherstellung?

Wenn jemand einen Datenrettungsdienst wegen eines ausgefallenen Arrays kontaktiert, bestimmt die Antwort auf die Frage „Welches RAID‑Level ist das?“ alles Weitere. RAIDZ1 und RAID 5 beruhen zwar auf demselben Grundprinzip — Parität über die Laufwerke zu verteilen, sodass ein einzelnes Laufwerk ausfallen kann, ohne dass Daten verloren gehen — doch ihr Verhalten unter Belastung unterscheidet sich erheblich. Diese Unterschiede werden besonders greifbar, sobald man ein degradiertes Array vor sich hat. Dieser Artikel beleuchtet, welche Auswirkungen die architektonischen Unterschiede auf Ausfallwahrscheinlichkeit, Wiederherstellungsaufwand und auf die jeweils geeigneten Tools für die Datenrettung (z. B. ZFS‑Utilities, mdadm) haben.

Inhalt

1. Tatsächlicher Aufbau der einzelnen Arrays
2. Das Write‑Hole‑Problem und stille Datenkorruption
3. Kapazität und Leistung
4. Vergleich von Ausfallszenarien
5. Wiederaufbau‑Risiko bei großen Laufwerken
6. Datenwiederherstellung aus RAID‑Z1
7. Datenrettung bei RAID 5
8. RS RAID Retrieve: Softwarebasierte Wiederherstellung für beide Konfigurationen
9. Welche Option wählen — und wann sie für die Wiederherstellung relevant ist

Beide Konfigurationen tolerieren den Ausfall eines einzelnen Laufwerks. Die Ähnlichkeit endet jedoch hier — insbesondere in dem Moment, in dem etwas schiefgeht.

Tatsächlicher Aufbau der einzelnen Arrays

RAID 5 verteilt Daten und Parität in Streifen fester Breite über alle Mitgliedslaufwerke — üblicherweise 64 KB oder 128 KB, vom Controller festgelegt und nicht veränderbar. Jeder Schreibzugriff, der weniger als einen vollständigen Stripe betrifft, löst den klassischen Read‑Modify‑Write‑Zyklus aus: alte Daten lesen, alte Parität lesen, neue Parität berechnen und beides zurückschreiben.

Dieser Zyklus ist die Hauptursache für das Write‑Hole und für mehrere weitere, unten erläuterte Probleme wie zum Beispiel stille Datenkorruption.

RAIDZ1 ist ein vdev‑Typ innerhalb von ZFS — die Pool‑Ebene ist untrennbar mit dem Dateisystem verbunden. ZFS gruppiert die Blöcke jeder Aufzeichnung (Record) in einen Streifen variabler Breite, der sich gleichzeitig über alle Datenträger erstreckt. Es gibt keine partiellen Stripe‑Schreibvorgänge; jeder Schreibvorgang entspricht einem vollständigen Stripe. Dadurch entfällt der Read‑Modify‑Write‑Zyklus vollständig und das Write‑Hole wird vermieden.

Ein RAIDZ1‑vdev kann nach der Erstellung nicht erweitert werden. Sie können dem Pool ein neues vdev hinzufügen, das ursprüngliche vdev bleibt jedoch unverändert. RAID 5 erlaubt in vielen Implementierungen eine Online‑Erweiterung — ein Flexibilitätsvorteil, der gelegentlich zu neuer Datenkorruption führen kann.

Das Write‑Hole‑Problem und stille Datenkorruption

Das Write‑Hole‑Problem ist spezifisch für RAID 5: Wird die Stromversorgung zwischen dem Schreiben neuer Daten und dem Aktualisieren der Parität unterbrochen, stimmen Datenblöcke und Parität nicht mehr überein. Die meisten Controller akzeptieren diese Inkonsistenz beim nächsten Systemstart stillschweigend und melden das Array als gesund — die Parität für den betroffenen Stripe ist dann einfach falsch. Das fällt oft erst auf, wenn während eines Rebuilds ein zweites Laufwerk ausfällt; in diesem Fall lässt sich der Stripe nicht rekonstruieren und es kommt ohne Vorwarnung zu Datenverlust.

ZFS vermeidet dieses Problem durch seine Copy‑on‑Write‑Semantik: Daten werden niemals über vorhandene Blöcke hinweg überschrieben. Fällt die Stromversorgung während eines Schreibvorgangs aus, verwirft ZFS die unvollständige Transaktion beim nächsten Einhängen. Das Dateisystem ist ab dem Zeitpunkt, an dem es wieder online geht, konsistent.

Das zweite Integritätsproblem ist die stille Datenkorruption (Bitrot). Laufwerke liefern gelegentlich fehlerhafte Daten zurück, ohne einen Fehlerstatus zu melden. RAID‑5 verfügt nicht über Prüfsummen zur Validierung und akzeptiert ungeprüft, was das Laufwerk zurückgibt. ZFS berechnet beim Schreiben für jeden Block eine Prüfsumme und validiert diese beim Lesen — schlägt die Prüfung fehl, rekonstruiert ZFS den Block aus der Parität und schreibt die korrigierten Daten zurück. In einem RAID‑5‑Verbund hingegen gelangt dieselbe Korruption unbemerkt bis zur Anwendung.

Stille Datenkorruption tritt auf Arrays, die drei oder mehr Jahre betrieben werden, häufiger auf als erwartet. RAID‑5‑Arrays mit älteren Laufwerken zeigen dieses Verhalten oft erst bei einer Wiederherstellung: Dabei treten Paritätsabweichungen über Dutzende von Stripes zutage — ohne dass der Controller vorher eine Warnung ausgegeben hätte.

Kapazität und Leistung

Beide RAID‑Konfigurationen verwenden dieselbe Kapazitätsformel: (N − 1) × drive size, bei mindestens drei Laufwerken. Fünf 8‑TB‑Laufwerke ergeben in beiden Konfigurationen 32 TB nutzbaren Speicher. Unterschiede bestehen im Schreibverhalten:

• RAID 5 mit batteriegestütztem Hardware‑Cache bewältigt gemischte Workloads gut — der Cache puffert Lastspitzen und verlagert den Read‑Modify‑Write‑Zyklus aus dem kritischen Pfad. Ohne diesen Cache steigt die Schreiblatenz bei kleinen, zufälligen Schreibvorgängen spürbar an.
• RAIDZ1 liefert gute Performance bei sequentiellen Workloads mit großen Record‑Größen — Medienarchivierung, Backups, VM‑Images. Schwachpunkt sind kleine, zufällige Schreibzugriffe: Jeder Schreibvorgang bildet einen vollständigen Stripe, weshalb IOPS‑intensive Workloads wie Datenbanken ohne L2ARC und SLOG auf schnellem NVMe weniger geeignet sind.
• Sequentieller Lesedurchsatz ist in etwa vergleichbar — beide Arrays lesen parallel von mehreren Laufwerken, sodass hier keiner der beiden eine nennenswerte Vorteile bei Durchsatz und Lesegeschwindigkeit hat.

Vergleich von Ausfallszenarien

Die folgende Tabelle beschreibt Szenarien, die bei der praktischen Datenwiederherstellung (ZFS vs. RAID5) am häufigsten auftreten.

Wiederaufbau‑Risiko bei großen Laufwerken

Bei Laufwerken größer als etwa 4–8 TB wird ein Schutz mit Einzelparität zu einem ernstzunehmenden Betriebsrisiko. Der Wiederaufbauprozess liest jeden Sektor aller verbliebenen Laufwerke — bei einem 16–20‑TB‑Laufwerk dauert das viele Stunden unter erhöhter I/O‑Last. Enterprise‑Laufwerke geben eine URE‑Rate von ~1 Fehler pro 10¹⁵ Bit an; Consumer‑Modelle liegen etwa um den Faktor zehn darüber. Bei einem Vier‑Laufwerk‑Array mit 12‑TB‑Laufwerken liest ein Rebuild rund ~36 TB — das Auftreten eines URE ist plausibel, nicht selten.

ZFS bietet einen kleinen, aber relevanten Vorteil: Resilvering liest nur zugewiesene Blöcke. Bei einem zu 40 % gefüllten Array werden entsprechend nur etwa 40 % der Daten neu eingelesen. Ein RAID‑5‑Wiederaufbau liest hingegen stets die volle Laufwerkskapazität, unabhängig von der belegten Datenmenge — ein deutlicher Unterschied in Zeitaufwand und Risiko bei teilweise gefüllten Arrays.

Datenwiederherstellung aus RAID‑Z1

Die Wiederherstellung von RAID‑Z1 profitiert von der selbstbeschreibenden Natur von ZFS. Jede Festplatte enthält vier Label‑Kopien mit der Pool‑GUID, der vdev‑Konfiguration und der Transaktionsgruppen‑Nummer. Schließen Sie die Platten an einen beliebigen Rechner mit ZFS an; zpool import erkennt und mountet das Pool — Kenntnisse über das ursprüngliche System sind nicht erforderlich. Ein Controller‑Ausfall, der ein RAID‑5‑Array lahmlegt, hat keinen Einfluss auf ein ZFS‑Pool, solange die Datenträger physisch zugänglich sind.

Gängige RAID‑Z1‑Wiederherstellungsszenarien, geordnet nach steigender Schwierigkeit:

• Prüfsummen‑ oder I/O‑Fehler während eines Scrubs — ZFS kennzeichnet das vdev als degraded und stellt betroffene Blöcke aus der Parität wieder her. Ersetzen Sie die degradierte Platte mit zpool replace und führen Sie anschließend zpool scrub aus. Das Resilver rekonstruiert nur die betroffenen Blöcke.
• Beschädigte ZFS‑Metadaten (Uberblock, MOS, Objektverzeichnis) — ZFS hält mehrere Kopien der Metadaten und kann auf eine frühere Transaktionsgruppe zurückrollen. Das Dienstprogramm zdb gibt Einblick in den internen Pool‑Zustand und ist der Ausgangspunkt für die forensische Analyse.
• Pool lässt sich überhaupt nicht importieren (zwei oder mehr ausgefallene Laufwerke oder auf mehreren Datenträgern beschädigte Labels) — hier werden spezielle Software‑Wiederherstellungstools erforderlich. Diese Werkzeuge müssen ZFS‑Blockzeiger, Kompression und die variable Streifenbreite (variable stripe geometry) verstehen; ein Tool, das das Array als generisches Gerät mit fester Stripe‑Geometrie behandelt, ist ungeeignet.

Für eine detaillierte Schritt‑für‑Schritt‑Anleitung zur ZFS‑Pool‑Wiederherstellung in TrueNAS‑Umgebungen siehe How to Recover Data from a RAID‑Z Array in TrueNAS.

Datenrettung bei RAID 5

Die Schwierigkeit einer RAID‑5‑Wiederherstellung variiert stark, weil Array‑Parameter nicht in einem einheitlich lesbaren Format gespeichert werden. Hardware‑Controller legen Plattenreihenfolge, Stripe‑Größe, Paritätsalgorithmus und Block‑Offset in proprietären Metadaten oder internem NVRAM ab. Fällt der Controller aus, benötigt man entweder ein identisches Ersatzgerät (teilweise mit exakt gleicher Firmware‑Version) oder Software, die die Konfiguration aus Rohdaten der Festplatten rekonstruieren kann. Software‑RAID 5 mit mdadm ist deutlich portabler — der Superblock auf jeder Member‑Disk enthält die Array‑Parameter. Genau der Superblock ist jedoch eine Schwachstelle: Wird er überschrieben, ist der Wiederaufbau komplett manuell erforderlich.

Die wichtigsten Schritte für jede RAID‑5‑Wiederherstellung, in der richtigen Reihenfolge:

• Erstellen Sie sektor‑für‑sektor Abbilder aller Platten, bevor Sie etwas anfassen. Arbeiten mit Abbildern statt mit Live‑Disks erlaubt es, Fehler durch Zurücksetzen auf den ursprünglichen Zustand zu korrigieren. Dies ist der wichtigste Schritt bei jeder RAID‑5‑Datenrettung.
• Verhindern Sie, dass der Controller automatisch einen Rebuild startet. Tritt während eines automatischen Neuaufbaus auf einer verbliebenen Platte ein nicht korrigierbarer Lesefehler (URE) auf, geht der betroffene Stripe unwiederbringlich verloren. Deaktivieren Sie den Auto‑Rebuild, bis Sie Abbilder erstellt haben.
• Rekonstruiere(n) Sie die Plattenreihenfolge — eine falsche Reihenfolge erzeugt ein optisch gültiges, aber beschädigtes Array. Das Paritätsrotationsmuster beim links‑symmetrischen RAID‑5 erlaubt eine Verifikation ohne Zufallsversuche.
• Ermitteln Sie die Stripe‑Größe — gängige Werte sind 64 KB, 128 KB und 256 KB. Bei korrekter Stripe‑Größe erscheinen erkennbare Dateisystem‑Signaturen an den erwarteten Offsets. Recovery‑Software automatisiert diesen Vorgang vollständig.

Für eine detaillierte Aufschlüsselung von Ausfallszenarien, einschließlich Vorgehensweise, wenn ein Controller nach einem Laufwerkstausch das Array fehlkonfiguriert, siehe How to Recover Data from RAID 5.

RS RAID Retrieve: Softwarebasierte Wiederherstellung für beide Konfigurationen

Wenn sich das Array nicht vom Betriebssystem reassemblieren lässt — weil der Controller ausgefallen ist, der Superblock beschädigt wurde oder die Laufwerke aus einem NAS in einen anderen Rechner verbracht wurden — ist eine softwarebasierte RAID-Rekonstruktion / RAID-Wiederherstellung der richtige nächste Schritt, bevor die Laufwerke an ein Datenrettungslabor gesendet werden.

RS Raid Retrieve

Datenwiederherstellung von beschädigten RAID-ArraysWiederherstellung jeder Art von RAID-Array

Herunterladen

Verfügbar für: Windows, macOS, Linux

RS RAID Retrieve unterstützt beide Array-Typen, ohne dass der Anwender die Parameter vorher kennen muss. Wesentliche Funktionen für die Datenrettung und RAID-Rekonstruktion:

• Automatische Parametererkennung für RAID 5 — die Software testet Kandidatenkonfigurationen (Laufwerksreihenfolge, Stripe-Größen, Paritätsalgorithmen) und zeigt die Konfiguration an, die ein konsistentes, mountbares Dateisystem liefert. Das beseitigt das Rätselraten, das bei ungeprüften Parametern zu weiterer Korruption führen kann.
• ZFS-Pool-Rekonstruktion für RAIDZ1 — liest Pool-Labels von allen Laufwerken, identifiziert Pool-GUID und vdev-Konfiguration und rekonstruiert die Array-Geometrie. Die Rekonstruktion gelingt auch bei teilbeschädigten Labels, solange ein Quorum lesbarer Labels vorhanden ist.
• Partielle Extraktion jenseits der Fehlertoleranz — bei RAID 5- oder RAID 6-Arrays mit mehr ausgefallenen Laufwerken als durch die Parität gedeckt sind, extrahiert die Software die Blöcke, die auf den verbleibenden Laufwerken vorhanden sind. Praktisch lässt sich so oft der Großteil der Daten aus einem scheinbaren Totalverlust retten.
• Unterstützung für Festplatten-Images — die Arbeit auf forensischen Kopien (Festplatten-Images) eliminiert das Risiko eines weiteren Ausfalls während des Wiederherstellungsversuchs und ist Best Practice bei der Datenrettung.

Welche Option wählen — und wann sie für die Wiederherstellung relevant ist

Die Entscheidung hat Auswirkungen auf die Datenwiederherstellung, die über die reine Architektur hinausgehen. Wählen Sie abhängig von Ihrer Umgebung:

• RAIDZ1 wählen, wenn bereits ZFS im Einsatz ist (TrueNAS, Proxmox, eigenes Linux). Integrierte Prüfsummen, Copy-on-Write-Konsistenz und unabhängige Portabilität gegenüber RAID-Controllern verringern die Wahrscheinlichkeit eines nicht wiederherstellbaren Zustands. Ein ausgefallener Controller ist für einen ZFS-Pool unkritisch.
• RAID 5 wählen, wenn Ihre Umgebung einen Hardware-RAID-Controller nutzt und keine ZFS-Infrastruktur vorhanden ist. Führen Sie regelmäßige Konsistenzprüfungen durch, überprüfen Sie vor jedem Rebuild die SMART-Werte aller Laufwerke und halten Sie eine aktuelle Sicherung vor — vergewissern Sie sich, dass das Backup gültig ist, bevor Sie einen Rebuild starten.

Für beide Konfigurationen ist der entscheidende Faktor für den Wiederherstellungserfolg das Verhalten in der ersten Stunde. Schreibzugriffe sofort einstellen. Initialisieren, neu formatieren oder fsck / chkdsk auf den Rohlaufwerken ausführen ist tabu. Erstellen Sie zunächst Abbilder der Laufwerke — beurteilen Sie anschließend, ob eine Software-Wiederherstellung ausreichend ist oder ein Datenrettungslabor hinzugezogen werden muss, abhängig von der Anzahl ausgefallener Laufwerke und vorhandenem physischen Schaden.

Sowohl RAIDZ1 als auch RAID 5 teilen dasselbe Grundrisiko: ein zweiter Laufwerksausfall während des Rebuilds führt zum Datenverlust. Bei Laufwerken > 8 TB oder bei wirklich unwiederbringlichen Daten bieten Dual-Paritäts-Konfigurationen — RAIDZ2 oder RAID 6 — eine Sicherheitsreserve, die einfache Parität nicht bieten kann.