Wenn der Rebuild schiefgeht – aus dem Laboralltag einer echten RAID-Rettung

Es gibt Momente im Labor, die man nie vergisst.
Vergangene Woche kam ein RAID-5-System zu uns, das so viele typische Fehler vereinte, dass es fast als Lehrbeispiel durchgehen könnte.
Ein mittelständisches Unternehmen aus Niederösterreich – Buchhaltungssoftware, mehrere virtuelle Maschinen, täglicher Betrieb.
Nach einem Stromausfall startete das System nicht mehr.
Zwei Festplatten wurden als „degraded“ gemeldet, die dritte als „failed“.
Ein klassischer Fall – und leider auch ein klassischer Fehlschritt.

Was passiert ist

Der zuständige Administrator wollte, verständlicherweise, schnell reagieren.
Er entfernte die vermeintlich defekte Platte, setzte eine neue ein und startete den automatischen Rebuild.
Das System begann zu synchronisieren – und nach rund 30 Prozent brach alles ab.
Danach: kein Zugriff mehr auf das Array, kein Volume sichtbar, kein Backup.

Ein einziger falscher Klick, und das ursprüngliche Paritätsverhältnis war zerstört.
Der Controller hatte nun falsche Metadaten über die Reihenfolge und Blockgröße geschrieben, sodass die ursprüngliche Paritätslogik nicht mehr rekonstruiert werden konnte.

Ab diesem Punkt war klar: Ohne Laborarbeit geht nichts mehr.

Rettung im Labor

Wir haben zunächst sämtliche Laufwerke sektorweise geklont, um keine weiteren Risiken einzugehen.
Danach folgte die logische Analyse – Rekonstruktion des ursprünglichen RAID-Schemas anhand von Stripe-Muster, Paritätsverlauf und Sektoroffsets.

Schnell zeigte sich: Das System war ursprünglich korrekt als RAID-5 mit 128 kB Stripe-Size konfiguriert.
Der Rebuild hatte jedoch begonnen, Paritätsblöcke im falschen Offset zu überschreiben.
Dadurch lag die Hälfte der Nutzdaten in einem „verschobenen“ logischen Rahmen – ein Albtraum für jede Wiederherstellung.

Nach manueller Blockanalyse, Paritätsprüfung und automatischer XOR-Rekonstruktion über ein angepasstes Toolset (PC-3000 RAID + proprietäre Skripte) gelang uns die virtuelle Wiederherstellung der ursprünglichen Struktur.
Es dauerte drei Tage – aber am Ende konnten über 96 Prozent der Daten konsistent wiederhergestellt werden.

Was wir daraus gelernt haben – und was andere vermeiden sollten

Viele Administratoren handeln aus Routine: Platte tauschen, Rebuild starten, fertig.
Aber ein RAID ist kein sicheres Backup.
Sobald mehr als ein Laufwerk betroffen ist oder unklare Statusmeldungen auftreten, sollte der Rebuild nicht automatisch angestoßen werden.

Ein paar Grundregeln helfen, das Desaster zu vermeiden:

1. Keine Eile beim Rebuild. Erst prüfen, welche Laufwerke wirklich betroffen sind – SMART-Werte, Logfiles, Controller-Status.

2. Kein Hot-Swap ohne vollständige Diagnose. Der Austausch falscher Laufwerke ist der häufigste Fehler.

3. Kein Rebuild bei unklaren Paritätszuständen. Wenn das Array schon inkonsistent ist, überschreibt der Rebuild oft die letzten intakten Daten.

4. Immer ein 1:1-Image erstellen, bevor Änderungen vorgenommen werden. Nur so kann später noch rekonstruiert werden, was verloren ging.

Ein Wort zur Verantwortung

Wir verstehen den Druck, unter dem IT-Verantwortliche stehen.
Ein Server steht, der Chef fragt, das Backup ist älter als gedacht – da greift man schnell selbst ein.
Aber: Jeder Schreibvorgang im falschen Moment kann monatelange Arbeit vernichten.

Deshalb lautet unser Rat: Lieber einmal zu früh anrufen als einmal zu spät.
Eine Ferndiagnose oder ein kurzes Telefonat kann oft schon verhindern, dass aus einem logischen Problem ein physischer Totalschaden wird.

Technischer Hintergrund für Interessierte

Bei einem RAID-5-Verbund verteilen sich Nutzdaten und Parität über mehrere Laufwerke.
Wenn eines ausfällt, kann der Controller die fehlenden Blöcke anhand der Parität rekonstruieren.
Fällt jedoch während oder nach dem Rebuild eine weitere Platte aus – oder wird die Reihenfolge vertauscht –, stimmen die Paritätsreferenzen nicht mehr.

Ab dann interpretiert der Controller gültige Daten als fehlerhaft und überschreibt sie.
Das erklärt, warum viele Datenverluste erst durch den Rebuild selbst entstehen, nicht durch den ursprünglichen Fehler.

Der Fall aus Niederösterreich endete gut – aber er hätte leicht in einem Totalverlust münden können.
Das zeigt, wie schmal der Grat zwischen Routine und Risiko ist.

Ein RAID ist ein großartiges Werkzeug für Ausfallsicherheit, aber kein Ersatz für Backups – und kein Selbstläufer bei der Wiederherstellung.

Wir bei Datenrettung RAID Austria helfen regelmäßig Unternehmen, bei denen der automatische Rebuild zum größten Feind wurde.
Mit Erfahrung, Spezialtechnik und einem klaren Ziel: Daten retten, nicht nur Festplatten.