RAID 5 Rebuild abgebrochen: Ursachen und Datenrettung

Ein RAID-5-Rebuild scheitert selten an einem exotischen Controller-Bug. Meist scheitert er an einer Rechnung, die im Alltag lange gut aussieht und im Krisenmoment kippt: Eine Platte ist bereits ausgefallen, die verbliebenen Datenträger müssen nun unter Dauerlast vollständig gelesen werden – und genau dabei trifft der Controller auf einen nicht korrigierbaren Lesefehler oder eine zweite angeschlagene Platte.

Bei großen SATA-Arrays kann ein Rebuild unter realer Last deutlich länger als 24 Stunden laufen. In dieser Zeit konkurrieren Produktivzugriffe, Cache-Flushes, Vibrationen im Chassis und die kontinuierliche Rekonstruktion um dieselben Ressourcen. Das Marketing verkauft RAID 5 als Schutz gegen den Ausfall einer Festplatte. Korrekt. Es verkauft aber nicht mit, wie teuer diese eine Toleranzstufe wird, wenn Kapazität, Plattenalter und Wiederherstellungsfenster aus dem Ruder laufen.

Ein Fall „RAID 5 Rebuild abgebrochen Datenrettung“ ist daher zunächst kein Fall für hektische Controller-Menüs. Er ist ein Schadensereignis. Wer jetzt blind weiterklickt, kann aus einem technisch rettbaren Array einen Fall für die forensische Rekonstruktion mit erheblich schlechteren Erfolgsaussichten machen.

Ein abgebrochener Rebuild ist kein Auftrag, den Controller entschlossener zu bedienen. Er ist ein Signal, jeden weiteren Schreibzugriff zu stoppen.

Warum ein RAID-5-Rebuild ausgerechnet beim Wiederaufbau scheitert

RAID 5 verteilt Nutzdaten und Paritätsinformationen über mindestens drei Festplatten. Fällt ein Laufwerk aus, kann der Controller die fehlenden Blöcke aus den Daten der übrigen Platten und den Paritätsinformationen berechnen. Das funktioniert, solange sämtliche für die Rekonstruktion benötigten Sektoren lesbar bleiben.

Der Rebuild ist deshalb keine harmlose Hintergrundaufgabe. Er verlangt von allen noch aktiven Laufwerken einen vollständigen, weitgehend sequenziellen Lesevorgang. Eine Platte, die im Normalbetrieb mit gelegentlichen Lesefehlern, schwebenden Sektoren oder trägen Antwortzeiten noch unauffällig blieb, wird unter dieser Last plötzlich zum Engpass.

Die zwei typischen Ursachen sind klar voneinander zu trennen.

Der berüchtigte URE-Fehler – „Unrecoverable Read Error“, also ein nicht korrigierbarer Lesefehler – ist dabei kein theoretischer Randfall. Für typische NAS- und Consumer-Festplatten werden Lesefehlerraten von etwa einem Fehler pro 10^14 gelesenen Bits angegeben. Enterprise-Modelle liegen häufig bei etwa einem Fehler pro 10^15 Bits. Das ist keine Garantie gegen Probleme, sondern eine Größenordnung für die Beschaffungsrechnung.

Je größer die Platten, desto mehr Daten müssen beim Rebuild gelesen werden. Und je mehr Daten gelesen werden, desto weniger überzeugt die bequeme Annahme, dass alle verbliebenen Laufwerke diesen Marathon fehlerfrei überstehen. Das ist keine Verurteilung von RAID 5. Kleine, gut überwachte Arrays mit passenden Kapazitäten und sauberem Backup-Konzept können wirtschaftlich sinnvoll sein. Problematisch wird es, wenn ein historisch gewachsenes RAID 5 mit großen, gleich alten Festplatten plötzlich als kritischer Primärspeicher behandelt wird.

Warum gleich alte Festplatten die Risikorechnung verschärfen

Im Einkauf wird oft ein komplettes Set identischer Laufwerke in einem Vorgang beschafft. Das vereinfacht Allokation, Lagerhaltung, Firmware-Freigaben und Gewährleistungsabwicklung. Operativ ist es bequem. Im Fehlerfall bedeutet es aber auch: Alle Platten haben eine sehr ähnliche Laufzeit, ähnliche Temperaturhistorie und dieselbe Belastung hinter sich.

Fällt eine erste Platte nach Jahren Dauerbetrieb aus, sind die übrigen Laufwerke nicht automatisch frisch und belastbar. Sie stammen häufig aus derselben Charge und wurden im selben Schachtverbund denselben thermischen und mechanischen Bedingungen ausgesetzt. Der Rebuild zwingt sie dann in eine Lastsituation, die im normalen Betrieb kaum vorkommt.

Hier entsteht der klassische Ablauf bei „RAID 5 Rebuild fehlgeschlagen zweite Platte“:

1. Eine Festplatte meldet Fehler oder fällt vollständig aus.

2. Der Administrator ersetzt sie und startet den Rebuild.

3. Alle verbliebenen Laufwerke werden über viele Stunden massiv gelesen.

4. Ein schwacher Sektor erzeugt einen URE, oder eine weitere Platte antwortet nicht mehr zuverlässig.

5. Der Controller bricht ab, markiert das virtuelle Laufwerk als ausgefallen oder nimmt es offline.

6. Der Versuch, das Array schnell wieder online zu zwingen, verschlechtert die Ausgangslage.

Der Fehler liegt nicht zwangsläufig in einer falschen Bedienung. Die falsche Bedienung beginnt oft erst nach dem Abbruch.

Puncturing, Force Online und andere teure Controller-Ideen

Nicht jeder RAID-Controller reagiert gleich auf einen URE während des Rebuilds. Einige LSI-basierte Controller verwenden ein Verfahren, das häufig als „Puncturing“ bezeichnet wird. Der betroffene Bereich wird dabei als nicht lesbar markiert, damit der Rebuild fortgesetzt werden kann. Das kann im Einzelfall den Verbund wieder verfügbar machen – aber es ist keine kostenlose Rettung.

Der Preis kann ein beschädigter Datenbereich sein: eine defekte Datenbankseite, ein unlesbares Archiv, ein kaputtes virtuelles Maschinenabbild oder ein fehlerhafter Dateisystemblock. Ob die Anwendung damit leben kann, entscheidet nicht der RAID-Controller. Er verwaltet Blöcke, keine Geschäftsdaten und keine Konsistenz von Datenbanken.

Andere Controller stoppen den Vorgang konsequenter und nehmen das Array offline. Das wirkt unfreundlich, ist aber technisch nachvollziehbar: Fehlt ein Baustein für die Berechnung eines Stripes, kann der Controller nicht seriös so tun, als sei die Rekonstruktion vollständig.

Besonders riskant ist die Funktion „Force Online“. Sie klingt nach einem pragmatischen Notfallhebel, ist in Wahrheit aber ein Eingriff mit hohem Kollateralschadenpotenzial. Wird ein zuvor ausgefallenes Laufwerk zwangsweise wieder online genommen, kann der Controller Schreibvorgänge gegen einen inkonsistenten Paritätszustand ausführen. Danach sind möglicherweise nicht nur einzelne Sektoren problematisch, sondern die zeitliche Reihenfolge und Konsistenz der Stripe-Daten.

Der Controller hat dann zwar wieder Aktivität. Das ist nicht dasselbe wie Datenintegrität. In der Praxis wird diese Verwechslung regelmäßig teuer.

„Online“ ist ein Status im Controller. „Konsistent“ ist eine Eigenschaft der Daten. Wer beides gleichsetzt, kauft Verfügbarkeit auf Kredit.

Was bei einem abgebrochenen Rebuild ausdrücklich nicht passieren darf

Bei einem RAID 5 offline nach Plattenwechsel ist der Drang zum Selbstversuch verständlich. Das System steht, die Fachabteilung wartet, und die Ersatzplatte liegt bereits im Rack. Genau das ist die gefährliche Mischung aus Betriebsdruck und vermeintlich einfacher Technik.

Folgende Maßnahmen sind nach einem Rebuild-Abbruch regelmäßig kontraproduktiv:

• Den Rebuild mehrfach neu starten: Jeder neue Versuch erzeugt zusätzliche Lese- und gegebenenfalls Schreiblast auf ohnehin auffälligen Laufwerken. Ein mechanisch oder elektronisch geschädigter Datenträger wird dadurch nicht gesünder.
• Eine Platte per „Force Online“ in den Verbund drücken: Das kann inkonsistente Parität und neue Schreibvorgänge erzeugen. Für eine spätere virtuelle Rekonstruktion fehlen dann möglicherweise saubere Ausgangsdaten.
• Dateisystemreparaturen starten: chkdsk, fsck oder xfs_repair arbeiten auf Dateisystemebene. Sie verstehen weder die Fehlerhistorie des RAID noch die beschädigte Paritätslage. Sie können vermeintlich defekte Einträge bereinigen und dabei intakte Verzeichnis- oder Zuordnungsinformationen entfernen.
• Platten umstecken oder Bay-Reihenfolge vergessen: Bei vielen RAID-Layouts ist die Reihenfolge der physischen Mitglieder entscheidend. Wer Laufwerke ohne Dokumentation zieht und später beliebig wieder einsetzt, erschwert die Rekonstruktion unnötig.
• Eine neue Initialisierung akzeptieren: Meldet der Controller ein fremdes oder unkonfiguriertes Laufwerk, darf kein Initialisierungsvorgang gestartet werden, solange nicht zweifelsfrei klar ist, welche Metadaten auf welcher Platte liegen.
• SMART-Werte als Freigabe missverstehen: Ein unauffälliger SMART-Status beweist nicht, dass ein Laufwerk unter Rebuild-Dauerlast zuverlässig liest. Umgekehrt ist ein einzelner SMART-Hinweis keine vollständige Diagnose. Entscheidend ist das Fehlerbild im Verbund.

Der typische Fehler im Incident-Management lautet: „Wir testen nur noch kurz etwas.“ Aus Sicht der Datenrettung bedeutet „kurz“ oft: weitere Schreibzugriffe, veränderte Metadaten, zusätzliche Fehlversuche und eine schlechtere Beweislage.

Sofortmaßnahmen: Schaden begrenzen, bevor Daten verloren gehen

Wenn der RAID-Controller den Wiederaufbau abgebrochen hat oder das virtuelle Laufwerk offline meldet, zählt nicht Geschwindigkeit beim Klicken, sondern Disziplin. Der erste Auftrag lautet: Zustand einfrieren.

Der sinnvolle Ablauf in den ersten Minuten

1. Produktivbetrieb kontrolliert stoppen.

Fährt das System noch teilweise hoch oder laufen noch Dienste, müssen weitere Schreibzugriffe unterbunden werden. Ein sauberer Shutdown ist besser als ein langes Weiterlaufen in einem instabilen Degraded-Zustand.

2. Controller-Status vollständig dokumentieren.

Fotografieren oder exportieren Sie, sofern ohne Änderungen möglich, die Anzeige des RAID-Controllers: Modell, Firmware, virtuelle Laufwerke, Plattenstatus, Bay-Nummern, Ereignisprotokoll und Rebuild-Fortschritt. Auch Meldungen zu „Foreign Configuration“, Zeitüberschreitungen oder Medienfehlern gehören dazu.

3. Jeden Datenträger eindeutig beschriften.

Notieren Sie mindestens: Gehäuseposition, Seriennummer, Modell, Kapazität und den vom Controller angezeigten Zustand. Die Bay-Nummer ist nicht Dekoration. Sie kann für die spätere Rekonstruktion entscheidend sein.

4. Keine Datenträger vertauschen.

Wenn Platten ausgebaut werden müssen, bleiben sie in exakt dokumentierter Reihenfolge. Ersatzplatten und Originalmitglieder dürfen nicht vermischt werden.

5. Keine Reparaturwerkzeuge ausführen.

Keine Dateisystemprüfung, keine automatische Bereinigung, keine Neuinitialisierung, keine erzwungene Wiederaufnahme. Ein RAID-Controller-Rebuild-Fehler lässt sich nicht durch eine Dateisystemreparatur „beheben“.

6. Technische Entscheidung treffen: internes Labor oder spezialisierte Datenrettung.

Gibt es ein belastbares internes Verfahren mit Write-Blockern, sektorweisen Images, Kenntnis des exakten RAID-Layouts und ausreichend Kapazität für Arbeitskopien? Dann kann eine kontrollierte Analyse möglich sein. Fehlt diese Umgebung, ist der richtige Zeitpunkt für professionelle Hilfe jetzt – nicht nach drei weiteren Controller-Experimenten.

Diese Reihenfolge wirkt konservativ. Sie ist es auch. Konservativ ist im Datenverlustfall kein Charakterzug, sondern TCO-Optimierung. Der Preis eines vorübergehenden Stillstands ist messbar. Der Preis einer durch Selbstversuche vereitelten Wiederherstellung ist es ebenfalls – nur mit deutlich unangenehmerer Null am Ende.

Wie professionelle RAID-Datenrettung tatsächlich arbeitet

Professionelle Datenrettung ist kein magischer Zugriff auf ein „kaputtes RAID“. Seriöse Anbieter rekonstruieren den Verbund außerhalb des ursprünglichen Controllers. Das Ziel ist nicht, das alte Array unbedingt wieder hochzufahren. Ziel ist, die vorhandenen Informationen möglichst schonend auszulesen und virtuell in der richtigen Geometrie zusammenzusetzen.

Der Ablauf besteht typischerweise aus mehreren Arbeitsschritten:

• Zunächst werden die Datenträger physisch und logisch bewertet. Mechanische Auffälligkeiten, Leseschwächen und instabile Bereiche bestimmen, wie aggressiv oder vorsichtig ein Laufwerk ausgelesen werden darf.
• Anschließend entstehen sektorweise Kopien der Originalmedien. Auf den Originalplatten sollte möglichst nicht gearbeitet werden. Jede unnötige Belastung reduziert die Reserve.
• Die Spezialisten analysieren RAID-Metadaten, Stripe-Größe, Blockreihenfolge, Paritätsrotation, Controller-spezifische Informationen und die exakte Mitgliedsreihenfolge.
• Das RAID wird virtuell nachgebildet. Erst darauf folgen Prüfungen der Dateisystemstruktur und – falls erforderlich – die logische Rekonstruktion von Dateien, Verzeichnissen oder Anwendungsdaten.
• Die geretteten Daten werden auf ein separates Zielsystem ausgegeben und anhand sinnvoller Stichproben validiert: Datenbanken, virtuelle Maschinen, Archive und aktuelle Arbeitsdaten sind wichtiger als eine bloße Dateianzahl.

Bei RAID-5-Fällen, in denen nach dem Abbruch nicht weiter geschrieben und nicht mit Reparaturwerkzeugen gearbeitet wurde, berichten professionelle Datenretter von Erfolgsquoten von über 95 Prozent. Das ist keine Zusage für jeden Einzelfall. Mechanische Schäden, überschriebenen Bereiche, fehlende Platten und vorherige Eingriffe verändern die Lage erheblich. Es zeigt aber, warum ein sofortiger Stopp oft wirtschaftlicher ist als der vermeintlich kostenlose Selbstversuch.

Einstiegspreise für RAID-Datenrettung werden je nach Schadensbild und Anbieter häufig im Bereich von etwa 250 bis 449 Euro genannt. Für echte Enterprise-Fälle mit mehreren geschädigten Laufwerken, hoher Kapazität, Prioritätsbearbeitung und komplexer virtueller Rekonstruktion ist das keine realistische Obergrenze. Die relevante Vergleichszahl lautet ohnehin nicht „Kosten der Datenrettung“, sondern „Kosten der nicht verfügbaren oder verlorenen Daten“.

Was Sie dem Datenretter liefern sollten

Ein guter Übergabepunkt spart Analysezeit und reduziert Rückfragen. Bereiten Sie deshalb diese Informationen vor:

• Hersteller und Modell des Servers, NAS oder Storage-Systems
• RAID-Controller-Modell inklusive Firmwarestand
• Anzahl der ursprünglichen RAID-Mitglieder und Kapazität je Laufwerk
• bekannte Reihenfolge der Laufwerke nach Bays oder Slots
• genaue Fehlermeldungen und Controller-Protokolle
• Zeitpunkt des ersten Laufwerksausfalls und des Rebuild-Abbruchs
• Information, ob „Force Online“, Initialisierung, Dateisystemprüfung oder weitere Rebuild-Versuche erfolgt sind
• Art der gespeicherten Daten: Dateifreigaben, Datenbanken, Hypervisor-Datastores, Sicherungsrepositorys oder Archive

Das ist kein Formalismus. Ein virtueller Maschinen-Datastore stellt andere Anforderungen an die Validierung als eine klassische SMB-Freigabe. Bei Datenbanken zählt nicht nur, ob Dateien lesbar sind, sondern ob Transaktions- und Log-Dateien in einer verwertbaren Beziehung stehen.

RAID 5 präventiv richtig einordnen: Kapazität ist nicht der einzige Preis

Die Beschaffungsperspektive auf RAID 5 ist nachvollziehbar: Gute Kapazitätsausnutzung, überschaubare Anzahl von Laufwerken, verbreitete Controller-Unterstützung. Bei drei Platten steht beispielsweise die Kapazität von zwei Datenträgern zur Verfügung. Bei sechs Platten verliert man rechnerisch nur die Kapazität eines Mitglieds an Parität. Auf dem Datenblatt sieht das effizient aus.

Die operative Rechnung ist komplexer. Je größer das Array, je höher die Plattenkapazität und je kritischer die Daten, desto stärker schlägt das Wiederherstellungsrisiko auf die Gesamtwirtschaftlichkeit durch. RAID 6 oder vergleichbare Dual-Parity-Konzepte kosten zusätzliche nutzbare Kapazität, tolerieren aber den Ausfall von zwei Laufwerken. Für produktive Systeme mit großen Nearline-SAS- oder SATA-Festplatten ist das häufig kein Luxus, sondern eine sachliche Risikoprämie.

Auch die Medienklasse muss zur Rolle passen. Eine günstige NAS-Platte kann für ein kleines Archiv oder ein unkritisches Backup-Ziel eine vernünftige Wahl sein. Für ein hochbelastetes Storage-System mit engem Servicefenster sind Enterprise-Laufwerke mit passender Firmware, spezifizierter Dauerlast und abgestimmtem Controller-Support oft die bessere Lifecycle-Entscheidung. Nicht, weil das Etikett „Enterprise“ magisch wäre, sondern weil Austauschprozesse, Firmware-Management und Fehlerverhalten planbarer werden.

Die präventive Beschaffungsagenda sollte mindestens diese Punkte enthalten:

• RAID-Level nach Wiederherstellungsrisiko wählen: RAID 5 ist nicht pauschal falsch. Für große produktive Arrays mit langer Rebuild-Dauer ist RAID 6, ein gespiegeltes Layout oder ein anderes Redundanzkonzept jedoch oft die belastbarere Kalkulation.
• Rebuild-Zeiten im eigenen Betrieb messen: Herstellerangaben helfen wenig, wenn der Storage unter echter Last läuft. Entscheidend sind Controller-Leistung, Queue-Tiefen, Hintergrundpriorität, Netzwerklast und die reale Datenverteilung.
• Hot-Spare-Konzept bewusst gestalten: Ein globales Hot Spare verkürzt die Zeit bis zum Rebuild, kann aber einen automatischen Wiederaufbau in einer ungünstigen Phase auslösen. Für kritische Systeme braucht es klare Regeln, wann Automatisierung sinnvoll ist und wann ein kontrollierter Eingriff besser wäre.
• Controller, Backplane und Firmware als Einheit verwalten: Nicht jeder Ausfall ist ein Medienfehler. Instabile Backplanes, nicht zertifizierte Laufwerke, Mischbestückung oder alte Firmware erzeugen Fehlerbilder, die der Controller vorschnell als Plattendefekt auslegt.
• Scrubbing und Patrol Read einplanen: Regelmäßige Prüfungen können schwache Bereiche früher sichtbar machen. Sie ersetzen kein Backup, verschieben aber Fehler aus dem akuten Rebuild-Fenster in einen planbaren Wartungszeitraum.
• Backups getrennt vom RAID denken: RAID hält Dienste nach dem Ausfall eines Laufwerks möglicherweise verfügbar. Ein Backup stellt gelöschte, verschlüsselte, logisch beschädigte oder vollständig verlorene Daten wieder her. Das sind zwei unterschiedliche Risikoklassen.
• Wiederherstellung testen: Ein Backup, das nie in ein separates System zurückgespielt wurde, ist eine Hoffnung mit Speichervertrag. Die Organisation braucht reale Wiederanlaufzeiten, nicht nur grüne Statusanzeigen.

Die richtige Entscheidung nach dem Abbruch

Ein abgebrochener RAID-5-Rebuild ist der Moment, in dem die ursprüngliche Kapazitätsersparnis zur Nebensache wird. Entscheidend ist jetzt, ob die vorhandenen Daten noch unverändert genug sind, um sie zuverlässig zu rekonstruieren. Der Controller liefert Hinweise, aber keine Garantie. Sein „Offline“-Status ist kein Urteil über endgültigen Datenverlust – und sein „Online“-Status keine Bestätigung, dass alles wieder stimmt.

Für den Einkauf und den Betrieb lautet die nüchterne Handlungsempfehlung: System stoppen, Zustand dokumentieren, Laufwerksreihenfolge sichern, keinerlei Schreib- oder Reparaturversuche zulassen und die Wiederherstellung auf Basis sauberer Images planen. Ist kein erfahrenes internes Datenrettungssetup vorhanden, gehört der Fall unmittelbar zu einem spezialisierten Dienstleister.

Danach folgt die unbequemere, aber wertvolle Arbeit: Das Storage-Design neu rechnen. Nicht nach Euro pro Terabyte, sondern nach Ausfallfenster, Wiederherstellungsdauer, Datenwert und Lifecycle-Risiko. RAID 5 kann wirtschaftlich sein. Ein RAID-5-Rebuild, der im falschen Moment scheitert, ist es fast nie.