Was passiert, wenn ein Rebuild fehlschlägt?
Manchmal beginnt ein schwerwiegender Datenverlust mit einer gut gemeinten Entscheidung.
Vor kurzem erreichte uns ein RAID-5-System aus Deutschland, das nach einem Stromausfall nicht mehr startete.
Drei Festplatten, davon zwei „degraded“ und eine „failed“.
Der Administrator wollte das Problem schnell lösen – ein Laufwerk ersetzt, Rebuild gestartet – und plötzlich war das gesamte Array verschwunden.
Ein klassischer Fall, den wir bei Datenrettung-RAID.com regelmäßig sehen: Ein automatischer Rebuild, der mehr zerstört als repariert.
Der Vorfall
Das betroffene System war ein Windows-Server mit virtuellen Maschinen und Geschäftsdaten.
Nach dem Ausfall meldete der Controller einen Degradierungszustand.
Anstatt die Laufwerke einzeln zu prüfen, wurde sofort ein Rebuild gestartet – und zwar mit einem Laufwerk, das noch fehlerhafte Sektoren enthielt.
Nach etwa einem Drittel der Synchronisation brach der Vorgang ab.
Das Volume war unzugänglich, das RAID nicht mehr initialisierbar.
Der Controller hatte Teile der Parität und der Nutzdaten überschrieben – ein Worst-Case-Szenario für jede Wiederherstellung.
Analyse und Vorgehen im Labor
Im Labor wurde das System zunächst komplett dupliziert – jede einzelne Festplatte wurde sektorweise geklont, um keine weiteren Änderungen zu riskieren.
Anschließend analysierten unsere Techniker die ursprüngliche Konfiguration anhand von Stripe-Mustern, Paritätsrotation und Blockgrößen.
Ergebnis: Das ursprüngliche Setup war korrekt als RAID-5 mit 128-kB-Stripe konfiguriert.
Der Rebuild hatte jedoch Paritätsinformationen mit falschem Offset neu geschrieben.
Damit waren ganze Datenbereiche logisch verschoben – vergleichbar mit einem Puzzle, dessen Teile an falscher Stelle kleben.
Mithilfe unserer Spezialtools (PC-3000 RAID Edition und eigener Analyse-Software) konnten wir das Array virtuell nachbilden, die fehlerhaften Paritätsblöcke isolieren und die Nutzdaten schrittweise rekonstruieren.
Nach rund 72 Stunden stand fest: 96 % der Daten waren wiederherstellbar – darunter alle geschäftskritischen Dateien und virtuellen Laufwerke.
Warum RAID-Rebuilds so oft scheitern
Ein Rebuild funktioniert nur dann zuverlässig, wenn der Controller exakte Informationen über Laufwerksreihenfolge, Parität und Synchronität hat.
Sind mehrere Laufwerke bereits fehlerhaft oder enthalten inkonsistente Daten, schreibt der Controller die Parität falsch – und zerstört damit die noch intakten Bereiche.
Häufige Ursachen:
-
falsche Laufwerksreihenfolge nach Austausch
-
beschädigte Metadaten auf mehreren Platten
-
Firmware- oder Controllerfehler
-
defekte Sektoren, die während des Rebuilds „übersehen“ werden
-
automatischer Rebuild nach Stromausfall ohne Konsistenzprüfung
Empfehlungen für Administratoren und Techniker
-
Keine voreiligen Rebuilds starten.
Erst prüfen, welche Laufwerke tatsächlich fehlerhaft sind – SMART-Werte, Logs, Controllerstatus. -
Immer 1:1-Images anlegen.
Bevor ein Laufwerk ersetzt oder rekonstruiert wird, muss ein vollständiges Abbild existieren. -
Automatische Rebuilds deaktivieren.
Manuelle Kontrolle verhindert, dass der Controller unbemerkt gültige Daten überschreibt. -
Konsistenz prüfen, bevor geschrieben wird.
Wenn mehr als ein Laufwerk betroffen ist, darf kein Rebuild erfolgen, bevor die Parität validiert wurde. -
Im Zweifel: System stilllegen.
Jeder weitere Schreibzugriff verringert die Chancen auf eine erfolgreiche Datenrettung erheblich.
Dieser Fall zeigt deutlich, wie schmal der Grat zwischen Routine und Datenverlust ist.
Ein Rebuild ist kein Reparaturtool, sondern ein riskanter Prozess, der nur bei klarer Diagnose gestartet werden darf.
Wir bei Datenrettung-RAID.com rekonstruieren regelmäßig Systeme, bei denen der automatische Wiederaufbau mehr Schaden angerichtet hat als der eigentliche Ausfall.
Mit forensischer Analyse, speziell entwickelten Tools und jahrzehntelanger Erfahrung stellen wir verlorene Strukturen wieder her – auch dann, wenn der Controller längst aufgegeben hat.
Denn unser Ziel bleibt immer dasselbe:
Daten retten. Nicht nur Festplatten.