Was passiert bei einem RAID-Rebuild und warum ist er so riskant?

Ein RAID-Rebuild (auch Rekonstruktion oder Resynchronisation genannt) ist der Prozess, bei dem ein RAID-Array nach dem Ausfall einer Festplatte die fehlenden Daten auf eine neue Ersatzfestplatte schreibt. Dabei wird jeder einzelne Sektor der verbleibenden Festplatten gelesen und die Paritätsinformationen werden verwendet, um die fehlenden Daten zu berechnen.

Bei einem RAID 5 mit vier Festplatten à 8 TB müssen während des Rebuilds rund 24 TB an Daten von den drei verbliebenen Platten gelesen werden, um die vierte Platte zu rekonstruieren. Bei RAID 6 ist die Berechnung komplexer, da zwei Paritätsebenen (P und Q) berücksichtigt werden müssen.

Der Rebuild ist aus mehreren Gründen die gefährlichste Phase im Leben eines RAID-Arrays:

  • Alle verbleibenden Festplatten werden unter maximale Belastung gestellt
  • Der gesamte Datenbestand muss sektorgenau gelesen werden, nicht nur die belegten Bereiche
  • Die Festplatten laufen während des Rebuilds stunden- oder tagelang unter Volllast
  • Bereits vorgeschädigte Sektoren, die im Normalbetrieb nie angesprochen werden, müssen jetzt gelesen werden
  • Der RAID-Controller hat während des Rebuilds keine Redundanz mehr (bei RAID 5) oder nur noch eingeschränkte Redundanz (bei RAID 6)

Dieser Prozess kann je nach Array-Größe und Festplattengeschwindigkeit 12 bis 72 Stunden oder länger dauern. In dieser gesamten Zeit operiert das RAID ohne seinen Schutz.

Warum scheitern RAID-Rebuilds so häufig?

Unrecoverable Read Errors (URE)

Die häufigste Ursache für einen fehlgeschlagenen Rebuild sind sogenannte Unrecoverable Read Errors (URE) auf einer der verbleibenden Festplatten. Jede Festplatte hat eine vom Hersteller spezifizierte Bit Error Rate (BER), die angibt, wie viele Bits statistisch fehlerhaft gelesen werden:

FestplattentypURE-RateBedeutung
Consumer-HDD (z. B. WD Blue, Seagate Barracuda)1 pro 10^14 Bits1 Lesefehler pro 12,5 TB gelesener Daten
NAS-HDD (z. B. WD Red, Seagate IronWolf)1 pro 10^15 Bits1 Lesefehler pro 125 TB gelesener Daten
Enterprise-HDD (z. B. WD Ultrastar, Seagate Exos)1 pro 10^15 Bits1 Lesefehler pro 125 TB gelesener Daten

Die Wahrscheinlichkeit eines URE während des Rebuilds lässt sich berechnen:

Formel: P(URE) = 1 − (1 − URE-Rate)^(Anzahl der zu lesenden Bits)

Für ein RAID 5 mit vier 8-TB-Consumer-Festplatten (URE-Rate 10^14):

  • Zu lesende Datenmenge: 3 × 8 TB = 24 TB = 2,4 × 10^14 Bits × 8 = 1,92 × 10^15 Bits
  • P(URE) ≈ ca. 21 %

Das bedeutet: Bei jedem fünften Rebuild eines solchen Arrays tritt statistisch ein nicht korrigierbarer Lesefehler auf, der den Rebuild abbricht.

Ausfall einer weiteren Festplatte

Die zweit häufigste Ursache ist der Ausfall einer weiteren Festplatte während des Rebuilds. Dies ist kein Zufall, sondern hat systemische Gründe:

  • Festplatten im selben Array sind oft gleich alt und gleich stark belastet
  • Der Rebuild erzeugt extreme I/O-Last, die latente Defekte zum Vorschein bringt
  • SMART-Fehler wurden möglicherweise ignoriert oder nicht überwacht
  • Thermische Belastung steigt durch die Dauerlast, was den Verschleiß beschleunigt

Falsche Laufwerksreihenfolge oder vertauschte Platten

Wenn bei einem NAS oder Server die Festplatten physisch entfernt und in falscher Reihenfolge wieder eingesetzt werden, kann der RAID-Controller das Array nicht korrekt zusammensetzen. Ein Rebuild mit falscher Plattenreihenfolge überschreibt gültige Daten mit fehlerhaften Paritätsberechnungen.

Professionelle Datenrettung benötigt?

Jetzt: Angebot für Datenrettung anfragen.

Inkompatible Ersatzfestplatte

Eine Ersatzfestplatte kann den Rebuild zum Scheitern bringen, wenn sie:

  • Eine kleinere Kapazität hat als die ausgefallene Platte
  • Sektorgrößen-Inkompatibilitäten aufweist (512 Bytes vs. 4K nativ)
  • Firmware-bedingte Timeouts produziert, die der Controller als Fehler wertet
  • Physische Defekte aufweist (auch neue Festplatten können DOA sein)

Firmware-Bugs und Controller-Probleme

In seltenen Fällen scheitert ein Rebuild aufgrund von Firmware-Fehlern im RAID-Controller. Dies betrifft besonders ältere Controller-Modelle, die mit modernen, sehr großen Festplatten nicht korrekt umgehen können. Weitere Informationen zu Controller-Problemen finden Sie unter Was tun, wenn der RAID-5-Controller defekt ist?.

Die Mathematik des Risikos: Wie wahrscheinlich ist ein Rebuild-Fehler?

Die folgende Tabelle zeigt die statistische Wahrscheinlichkeit eines URE während eines RAID-5-Rebuilds für verschiedene Array-Konfigurationen:

Array-KonfigurationZu lesende DatenmengeP(URE) Consumer-HDDP(URE) Enterprise-HDD
3 × 4 TB (RAID 5)8 TB~6,2 %~0,6 %
4 × 8 TB (RAID 5)24 TB~17,5 %~1,9 %
5 × 12 TB (RAID 5)48 TB~32,1 %~3,7 %
6 × 16 TB (RAID 5)80 TB~47,2 %~6,2 %
8 × 18 TB (RAID 5)126 TB~63,6 %~9,6 %
Erkenntnis: Bei großen RAID-5-Arrays mit Consumer-Festplatten ist ein fehlgeschlagener Rebuild wahrscheinlicher als ein erfolgreicher. Dies ist einer der Gründe, warum RAID 5 für Arrays ab 4 TB Plattengröße nicht mehr empfohlen wird.

Bei RAID 6 sind zwei Paritätsebenen vorhanden, sodass ein einzelner URE den Rebuild nicht sofort abbricht. Allerdings arbeitet das Array dann nur noch mit einfacher Redundanz, vergleichbar mit einem RAID 5 mit einer defekten Platte. Auch bei RAID 6 können zwei gleichzeitige Ausfälle zum vollständigen Datenverlust führen.

Was sollten Sie nach einem fehlgeschlagenen Rebuild auf keinen Fall tun?

Nach einem fehlgeschlagenen RAID-Rebuild ist die Situation kritisch. Die folgenden Aktionen können den Schaden irreversibel verschlimmern:

  • Rebuild nicht erneut starten: Ein wiederholter Rebuild-Versuch belastet die ohnehin geschwächten Festplatten weiter und kann zusätzliche Sektoren beschädigen.
  • Festplatten nicht umstecken oder tauschen: Die physische Reihenfolge der Festplatten darf nicht verändert werden. Fotografieren Sie die aktuelle Anordnung.
  • RAID-Controller nicht zurücksetzen: Ein Reset des Controllers kann die gespeicherte RAID-Konfiguration löschen.
  • Array nicht neu initialisieren: Eine Neuinitialisierung überschreibt alle Daten auf allen Festplatten mit Nullen oder neuen Paritätsdaten.
  • Kein Firmware-Update durchführen: Ein Firmware-Update des Controllers während eines fehlerhaften Zustands kann die Metadaten überschreiben.
  • Keine Datenrettungssoftware direkt auf den betroffenen Platten ausführen: Software-Schreibvorgänge auf den RAID-Mitgliedsfestplatten können die Daten weiter beschädigen.
  • Nicht auf eigene Faust im Internet nach Lösungen suchen und diese ausprobieren: Gut gemeinte Ratschläge aus Foren sind oft veraltet oder auf andere Controller-Modelle bezogen und können fatale Folgen haben.

Was Sie stattdessen tun sollten

  1. System sofort herunterfahren und die Festplatten nicht mehr ansprechen
  2. Alle verfügbaren Informationen dokumentieren: RAID-Level, Controller-Modell, Firmware-Version, Festplattentypen und -seriennummern, Fehlermeldungen, Timeline der Ereignisse
  3. Festplatten in den Slots belassen und die Reihenfolge fotografieren
  4. Professionellen Datenrettungsdienst kontaktieren und die Situation schildern

Wie rettet ein Profi Daten nach einem fehlgeschlagenen Rebuild?

Ein professioneller Datenrettungsdienst geht bei einem fehlgeschlagenen RAID-Rebuild grundlegend anders vor als der RAID-Controller. Statt den Rebuild-Prozess zu wiederholen, wird das RAID ohne den Controller in einer sicheren Softwareumgebung rekonstruiert. Der allgemeine Ablauf einer professionellen Datenrettung ist unter Wie läuft eine professionelle Datenrettung ab? beschrieben.

Schritt 1: Forensisches Imaging

Jede einzelne Festplatte wird mit spezialisierten Hardware-Imagern (z. B. DeepSpar DDI, PC-3000) sektorgenau auf ein Zielmedium geklont. Diese Imager können:

  • Fehlerhafte Sektoren überspringen und später erneut versuchen
  • Die Lesestrategie dynamisch an den Zustand der Platte anpassen
  • Heads einzeln ansprechen und so auch bei teildefekten Platten Daten auslesen
  • Den Klonvorgang bei Verschlechterung des Plattenzustands pausieren

Der entscheidende Unterschied zum Controller-Rebuild: Der Imager liest tolerant gegenüber einzelnen Lesefehlern. Ein URE führt nicht zum Abbruch, sondern wird übersprungen und die entsprechende Stelle wird markiert.

Schritt 2: RAID-Parameter-Analyse

Aus den geklonten Images werden die RAID-Metadaten analysiert:

  • Stripe-Größe (typischerweise 64 KB, 128 KB oder 256 KB)
  • Festplattenreihenfolge im Array
  • Paritätsalgorithmus und -verteilung (left-symmetric, left-asymmetric etc.)
  • Start-Offset der Datenpartition
  • RAID-Level und -Konfiguration

Bei NAS-Systemen wie QNAP oder Synology werden zusätzlich die proprietären Verwaltungsschichten über mdadm analysiert.

Schritt 3: Virtuelle RAID-Rekonstruktion

Das RAID wird in einer Softwareumgebung virtuell zusammengesetzt. Tools wie R-Studio, UFS Explorer oder Runtime RAID Reconstructor ermöglichen die Rekonstruktion auch mit fehlenden oder teilweise defekten Festplatten. Fehlende Sektoren werden, soweit möglich, aus den Paritätsdaten berechnet.

Schritt 4: Dateisystem-Analyse und Datenextraktion

Das rekonstruierte RAID-Volume wird auf Dateisystemebene analysiert. Je nach Betriebssystem handelt es sich um ext4, XFS, Btrfs, NTFS oder VMFS. Beschädigte Dateisystemstrukturen werden repariert und alle wiederherstellbaren Daten auf ein neues Medium kopiert.

Welche RAID-Level sind besonders anfällig für Rebuild-Fehler?

Nicht alle RAID-Level sind gleich anfällig für Rebuild-Probleme:

RAID-LevelRebuild-RisikoErklärung
RAID 0Kein Rebuild möglichKeine Redundanz, jeder Plattenausfall bedeutet Datenverlust. Siehe RAID-0-Datenrettung
RAID 1GeringRebuild ist ein einfacher Kopiervorgang, kein Paritätsberechnung nötig. Siehe RAID-1-Ausfall
RAID 5HochEine Festplatte Redundanz, URE bricht Rebuild ab
RAID 6MittelZwei Festplatten Redundanz, verträgt einen URE, aber nicht zwei
RAID 10GeringRebuild betrifft nur den gespiegelten Partner, nicht das gesamte Array. Siehe RAID-10-Datenrettung
Empfehlung: Für Arrays mit Festplatten ab 4 TB Kapazität sollte mindestens RAID 6 oder RAID 10 verwendet werden. RAID 5 bietet bei modernen Festplattengrößen keine ausreichende Sicherheit mehr.

Welche Besonderheiten gelten bei NAS-Systemen wie Synology und QNAP?

Bei NAS-Systemen gelten zusätzliche Besonderheiten, die den Rebuild und die Datenrettung beeinflussen:

Proprietäre RAID-Implementierungen

Die meisten NAS-Hersteller verwenden Linux mdadm als Basis für ihre RAID-Implementierung, erweitern diese aber um eigene Verwaltungsschichten:

  • Synology SHR (Synology Hybrid RAID): Erlaubt unterschiedlich große Festplatten im Array. Die RAID-Berechnung unterscheidet sich von Standard-mdadm, was die Rekonstruktion erschwert. Zur Datenrettung bei Synology-Systemen haben wir einen separaten Ratgeber: Synology-NAS-Datenrettung.
  • QNAP: Verwendet mdadm mit eigenen Volume-Management-Schichten. Details zur QNAP-Datenrettung finden Sie unter QNAP-NAS-Datenrettung.
  • Asustor, TerraMaster: Ebenfalls mdadm-basiert, aber mit eigener Firmware-Integration.

Automatischer Rebuild

Viele NAS-Systeme starten den Rebuild automatisch, sobald eine Ersatzfestplatte (oder Hot-Spare) erkannt wird. Dies kann problematisch sein, wenn:

  • Die Ersatzfestplatte Defekte aufweist
  • Eine zweite Platte bereits latente Fehler hat
  • Der Administrator den Rebuild gar nicht starten wollte

Verschlüsselung

Wenn das NAS eine Volume-Verschlüsselung (z. B. eCryptfs bei Synology oder LUKS bei QNAP) nutzt, muss bei der Datenrettung zusätzlich der Verschlüsselungsschlüssel vorliegen. Ohne den Schlüssel sind die Daten auch nach erfolgreicher RAID-Rekonstruktion nicht lesbar.

Wie kann man Rebuild-Fehler in Zukunft vermeiden?

Präventive Maßnahmen sind der wirksamste Schutz gegen die Risiken eines RAID-Rebuilds:

  • Enterprise-Festplatten verwenden: NAS- oder Enterprise-Festplatten haben eine zehnmal niedrigere URE-Rate als Consumer-Platten. Die Investition rechnet sich bei kritischen Daten immer.
  • RAID 6 oder RAID 10 statt RAID 5: Bei Festplatten ab 4 TB ist RAID 5 ein inakzeptables Risiko. RAID 6 verträgt zwei gleichzeitige Ausfälle, RAID 10 bietet schnellere Rebuilds.
  • SMART-Monitoring aktivieren: Überwachen Sie die Festplatten kontinuierlich auf SMART-Fehler. Tauschen Sie Festplatten proaktiv bei ersten Warnzeichen.
  • Hot-Spare konfigurieren: Eine ungenuzte Festplatte im Array ermöglicht den sofortigen Rebuild ohne manuelle Intervention, was die Rebuild-Dauer und damit das Risikofenster verkürzt.
  • Regelmäßige Backup-Tests: Kein RAID ersetzt ein Backup. Implementieren Sie die 3-2-1-Backup-Strategie und testen Sie die Wiederherstellung regelmäßig.
  • Festplatten gestaffelt tauschen: Ersetzen Sie Festplatten nicht alle gleichzeitig, sondern zeitversetzt. So vermeiden Sie, dass alle Platten gleichzeitig das Ende ihrer Lebensdauer erreichen.
  • Rebuild-Priorität konfigurieren: Stellen Sie die Rebuild-Priorität auf dem Controller auf „Hoch", um die Rebuild-Dauer zu minimieren. Bedenken Sie, dass dies die Performance im Produktivbetrieb reduziert.
  • Datenvolumen im Blick behalten: Bevor Sie ein RAID-Array vergrößern, prüfen Sie, ob das gewählte RAID-Level noch angemessen ist. Der Artikel Wie lange dauert eine professionelle Datenrettung? gibt Aufschluss über Zeiträume, die bei einer Rettung zu erwarten sind.

Was kostet die Datenrettung nach einem fehlgeschlagenen RAID-Rebuild?

Die Kosten hängen von mehreren Faktoren ab und lassen sich nicht pauschal benennen:

SzenarioTypische KostenTypische Dauer
Rebuild-Fehler durch URE, alle Platten physisch intakt800–2.000 Euro3–7 Werktage
Rebuild-Fehler plus eine physisch defekte Platte1.500–3.000 Euro5–10 Werktage
Rebuild-Fehler plus zwei physisch defekte Platten2.000–4.000 Euro7–14 Werktage
Rebuild-Fehler bei NAS mit Verschlüsselung1.200–2.500 Euro5–10 Werktage
Express-BearbeitungAufschlag 30–50 %Reduzierte Dauer

Seriöse Datenrettungsunternehmen bieten eine transparente Kostenschätzung vor Beginn der Arbeiten. Informationen darüber, warum professionelle Datenrettung ihren Preis hat, finden Sie unter Warum sind Datenrettungskosten oft so hoch?. Tipps zur Auswahl eines vertrauenswürdigen Anbieters bietet der Artikel Woran erkennt man einen seriösen Datenretter?.

Wenn Ihr RAID-Rebuild fehlgeschlagen ist, handeln Sie schnell und lassen Sie die Festplatten unberührt. Je weniger am System verändert wird, desto höher sind die Chancen auf eine vollständige Datenrettung.

Angebot für Datenrettung anfragen

Professionelle Datenrettung benötigt?

Jetzt: Angebot für Datenrettung anfragen.