Warum ein Rebuild RAID zerstören kann: Was tun bei einem degraded Array

Die Antwort gleich vorweg: Wenn ein RAID oder NAS degraded, critical, failed disk oder einen unvollständigen Rebuild meldet und die Daten wichtig sind, starten Sie keinen weiteren blinden Rebuild. Stoppen Sie Schreibvorgänge, dokumentieren Sie die Reihenfolge der Festplatten, machen Sie Screenshots der Meldungen und schalten Sie das Array sicher aus. Eine professionelle Wiederherstellung beginnt nicht mit dem Neuaufbau des Arrays auf den Originalfestplatten, sondern mit einem sektorbasierten Klonen jeder Festplatte und einer Offline-Rekonstruktion von den Kopien.

Ein Klick. 160 TB Kapazität. Vier Jahre Firmenprojekte. Und eine Administrator-Entscheidung, die auf den ersten Blick wie Routine aussah: eine defekte Festplatte austauschen und den Rebuild starten.

Genau so gelangte ein 20-Platten-RAID 6 von einem Brünner Projektierungsunternehmen zu uns. Das NAS enthielt CAD-Dokumentationen, historische Projekte und einen Teil der Betriebsbackups. RAID 6 ist prinzipiell ein Array mit doppelter Parität, sollte also den Ausfall von zwei Festplatten verkraften. Nur bedeutet „sollte„ nicht „es ist sicher, ein altes Array ohne Prüfung neu aufzubauen".

Was bedeutet degraded RAID

Der Status degraded bedeutet nicht, dass die Daten verloren sind. Er bedeutet, dass das RAID einen Teil seiner Redundanz verloren hat und in einem Notbetrieb läuft.

• RAID 1: eine gespiegelte Festplatte fehlt, die Daten befinden sich auf der anderen.
• RAID 5: eine Festplatte fehlt, ein weiterer Fehler kann bereits den Verlust des Arrays bedeuten.
• RAID 6: ein oder zwei Festplatten fehlen, aber bei zwei Ausfällen besteht kein Spielraum mehr für einen weiteren Fehler.
• RAID 10: es hängt davon ab, in welchem Mirror-Paar die Festplatte ausgefallen ist.

Der größte Irrtum ist es, den degraded Status als Aufforderung zu einem sofortigen Rebuild um jeden Preis zu betrachten. Bei einem kleinen, neuen Array mit einem aktuellen Backup mag das sinnvoll sein. Bei einem vier Jahre lang laufenden NAS mit Dutzenden von Terabyte und ohne verifiziertes Offsite-Backup ist es ein Glücksspiel.

Die Zeitleiste des Ausfalls

In unserem Fall handelte es sich um ein Enterprise-NAS mit 20 Festplatten im RAID 6. Das Array lief mehrere Jahre ununterbrochen. Die Benutzer hatten darauf aktive Projekte sowie ein Archiv.

Montagmorgen: Festplatte Nummer 7 fiel aus. Das Array wechselte in den Status degraded, aber die Daten waren verfügbar. Der Administrator bestellte eine Ersatzfestplatte und plante den Austausch für den Abend.

Dienstagmorgen: noch bevor die Ersatzfestplatte geliefert wurde, meldete Festplatte Nummer 12 einen kritischen Fehler. RAID 6 war theoretisch immer noch lesbar, hatte aber keine Toleranz mehr für einen weiteren Fehler.

Dienstagnachmittag: die Ersatzfestplatte traf ein und der Rebuild wurde gestartet. Der Controller begann, die gesamte Oberfläche der verbleibenden Festplatten zu lesen, die Parität neu zu berechnen und eine neue Kopie der fehlenden Daten zu schreiben.

Nach dreißig Stunden: der Rebuild stoppte an fehlerhaften Sektoren von Festplatte Nummer 5. Diese hatte zuvor gesund ausgesehen. Das intensive Lesen während des Rebuilds förderte jedoch latente Fehler zutage, die im Normalbetrieb nicht sichtbar waren.

Mittwochmorgen: das Array war offline und konnte mit normalen Mitteln nicht mehr eingebunden werden.

Dies ist genau der Moment, in dem ein weiterer Rebuild-Versuch, „force online", eine Änderung der Plattenreihenfolge oder die Initialisierung eines neuen Arrays selbst das zerstören kann, was noch wiederherstellbar ist.

Warum ein Rebuild alte Arrays killt

Ein Rebuild ist keine Datenreparatur. Ein Rebuild ist ein massiver Belastungstest für alle verbleibenden Festplatten.

Im normalen Betrieb liest ein NAS nur aktive Dateien und Metadaten. Während eines Rebuilds muss der Controller einen großen Teil der Oberfläche aller Festplatten durchlaufen, oft Stunden bis Tage am Stück. Bei älteren Festplatten treten dann genau folgende Probleme auf:

• latente defekte Sektoren,
• Lese-Timeouts,
• schwache Schreib-/Leseköpfe,
• auffällige SMART-Werte,
• Probleme mit der Stromversorgung oder Kühlung des Schachts,
• Paritätsinkonsistenzen nach vorherigen Ausfällen.

Je größer die Festplatten, desto länger der Rebuild und desto größer das Risikofenster. Bei RAID 5 ist das Problem noch gravierender, da ein weiterer Fehler während des Rebuilds das Ende bedeuten kann. RAID 6 hat eine größere, aber keine unendliche Reserve. Wenn bereits zwei Festplatten ausgefallen sind und eine dritte beginnt, Fehler zurückzugeben, reicht der Schutz durch die doppelte Parität nicht mehr aus.

Was vor dem Rebuild hätte kommen sollen

Ein sicheres Vorgehen bei einem wichtigen degraded RAID sieht anders aus:

1. Schreibvorgänge stoppen. Idealerweise die Freigaben trennen, Dienste deaktivieren, Virtualisierung und Datenbanken stoppen.
2. Status dokumentieren. Screenshots der NAS-Administration, Logs, Festplattenreihenfolge, Seriennummern, Slots, RAID-Typ, Stripe-Größe, Dateisystemtyp.
3. SMART aller Festplatten prüfen. Nicht nur derjenigen, die das NAS als defekt markiert hat.
4. Backup verifizieren. Nicht „es sollte irgendwo sein", sondern das letzte Backup tatsächlich öffnen und die Daten überprüfen.
5. Bei kritischen Daten vor dem Rebuild klonen. Jede Originalfestplatte sektorweise auf ein anderes Medium auslesen. Den Rebuild erst von den Kopien oder nach einer klaren Risikobewertung durchführen.

Wenn Sie unsicher sind, ist der sicherste Schritt, nichts weiter zu überschreiben. Dies gilt für Synology, QNAP, TrueNAS, Linux mdadm, ZFS sowie für Hardware-Controller von Dell/HP/LSI.

Wie wir im Labor vorgegangen sind

Nach der Übernahme haben wir zunächst die Festplatten gemäß ihrer ursprünglichen Positionen beschriftet. Bei einer RAID-Wiederherstellung ist die Reihenfolge entscheidend. Die Festplatten werden nicht vertauscht, es wird keine automatische Initialisierung ausgeführt und das Angebot „repair" in der Administration wird nicht angenommen.

Die erste Phase war das sektorweise Klonen aller Festplatten. Defekte Festplatten werden mit einer anderen Strategie gelesen als gesunde: zuerst die stabilen Bereiche, dann die schlechteren Stellen, bei Bedarf Lesen in umgekehrter Richtung und wiederholte Versuche über schwachen Sektoren. Das Ziel ist nicht ein schöner SMART-Report. Das Ziel ist, so viele lesbare Sektoren wie möglich zu erhalten, bevor sich die Festplatte verschlechtert.

Die zweite Phase war die Offline-Analyse. Bei großen Arrays reicht es nicht zu wissen, dass „es ein RAID 6 war". Wir benötigen die exakte Geometrie:

• Reihenfolge der Festplatten,
• Stripe Size,
• Parity Rotation,
• Start Offset,
• eventuelle Metadaten des NAS-Herstellers,
• Zustand des Dateisystems über dem Array.

Erst danach wird das virtuelle Array aus den Klonen zusammengestellt. Die Originale wollen wir in dieser Phase nicht mehr belasten. Wenn die Rekonstruktion beim ersten Mal nicht gelingt, werden die Parameter über den Kopien geändert, nicht über den Kundenfestplatten.

In diesem Fall konnten 100 % der Kundendaten wiederhergestellt werden. Der Kunde überprüfte stichprobenartig CAD-Projekte aus mehreren Jahren, Referenzdateien und Archivordner. Aktuelle Projekte der Priorität A haben wir früher als den Rest des Arrays extrahiert, damit die Firma weiterarbeiten konnte, während die vollständige Rekonstruktion lief.

Eine ausführlichere technische Case Study finden Sie auf der Seite Datenrettung von einem 20-Platten-RAID 6 in einem NAS.

Was zu tun ist, wenn das RAID gerade einen Fehler meldet

Wenn Sie diesen Artikel in dem Moment lesen, in dem das NAS piept oder die Administration rot leuchtet:

1. Starten Sie den Rebuild nicht wiederholt. Ein fehlgeschlagener Rebuild ist eine ausreichende Warnung.
2. Erstellen Sie kein neues Array auf denselben Festplatten. Die Initialisierung kann Metadaten überschreiben.
3. Ändern Sie nicht die Reihenfolge der Festplatten. Fotografieren Sie die Schächte, notieren Sie sich Slots und Seriennummern.
4. Lassen Sie das Array ohne Schreibvorgänge. Jede neue Datei erschwert den Zustand des Dateisystems.
5. Kombinieren Sie keine Anleitungen aus Foren. mdadm, ZFS, Synology SHR, QNAP LVM und Hardware-RAID haben unterschiedliche Metadatenstrukturen.
6. Wenn ein Backup existiert, verifizieren Sie es. Dateien zu öffnen ist besser, als nur zu sehen, dass der Backup-Job „erfolgreich abgeschlossen" wurde.

Wenn es sich um Daten handelt, deren Verlust Sie sich nicht leisten können, halten Sie inne, bevor Sie eine Aktion ausführen, die auf die Festplatten schreibt. Eine Datenwiederherstellung ist am erfolgreichsten, wenn der ursprüngliche Zustand noch nicht überschrieben wurde.

RAID ist kein Backup

RAID sorgt für Verfügbarkeit. Ein Backup ermöglicht die Rückkehr zu Daten nach einer Katastrophe.

RAID kann Sie unterstützen, wenn eine Festplatte ausfällt und Sie weiterarbeiten müssen. Es schützt Sie nicht vor dem Löschen eines Ordners, Ransomware, einem Administratorfehler, einem defekten Controller, Feuer, Wasserschäden oder einem fehlgeschlagenen Rebuild. Daher ist bei Unternehmensdaten eine Kombination sinnvoll aus:

• RAID/NAS für die Betriebsverfügbarkeit,
• regelmäßigem Scrub oder Patrol Read,
• SMART- und Temperaturüberwachung,
• Offline- oder Offsite-Backup,
• einem Restore-Test zumindest der kritischen Ordner.

Wenn Sie ein NAS als einzigen Ort haben, an dem Daten existieren, ist das kein Backup. Es ist eine einzige Kopie in einer teureren Box.

Kurze FAQ

Mein Synology/QNAP ist im degraded-Status. Soll ich eine neue Festplatte einsetzen?

Überprüfen Sie zuerst den Zustand aller Festplatten und das Backup. Wenn die Daten wichtig und das Array älter ist, ist es sicherer, das Vorgehen vor einem Rebuild zu konsultieren. Durch das Einsetzen der Festplatte wird oft automatisch ein Prozess gestartet, der nicht mehr einfach rückgängig gemacht werden kann.

Der Rebuild läuft bereits. Soll ich ihn stoppen?

Das hängt vom Zustand ab. Wenn er fehlerfrei läuft und Sie ein verifiziertes Backup haben, kann er zu Ende laufen. Wenn Lesefehler, Timeouts, eine weitere failed disk oder ungewöhnliche Geräusche auftreten, kann die weitere Belastung schaden. In einer solchen Situation ist es besser, Schreibvorgänge zu stoppen, den Zustand zu dokumentieren und das Klonen zu veranlassen.

Hilft ddrescue zu Hause?

Bei einer einzelnen Festplatte kann ddrescue ein nützliches Werkzeug sein, wenn Sie wissen, was Sie tun, und auf ein anderes Medium auslesen. Bei einem RAID reicht es jedoch nicht, „irgendetwas" zu klonen. Sie benötigen die korrekte Reihenfolge der Festplatten, den Offset, die Parität und das Dateisystem. Ein fehlerhaftes Vorgehen kann Metadaten überschreiben oder die Festplatten verschlechtern.

Was kostet die Datenrettung von einem RAID?

Dies hängt von der Anzahl der Festplatten, der Kapazität, dem RAID-Typ, dem Zustand der Medien und dem Aufwand für die manuelle Rekonstruktion ab. Die Diagnose des RAID/NAS ist bei uns kostenlos und vor der eigentlichen Wiederherstellung erhalten Sie einen Kostenvoranschlag. Beginnen sollten Sie am besten über die Anfrage zur Datenrettung von RAID oder den Kontakt.

Wenn Sie ein degraded RAID, einen fehlgeschlagenen Rebuild oder ein offline NAS haben, versuchen Sie keine weiteren blinden Reparaturen. Rufen Sie +420 775 556 063 an, schreiben Sie an zachranadat@ithope.cz oder senden Sie eine Beschreibung über das Kontaktformular. Unser Labor befindet sich in Brünn-Židenice, RAID/NAS-Fälle bearbeiten wir aus ganz Tschechien.