RAID-Rebuild fehlgeschlagen: Warum die Rekonstruktion danach deutlich komplexer wird

Wenn Parität, Laufwerkszustände und RAID-Metadaten nicht mehr zusammenpassen

Ein RAID-Rebuild gilt im normalen Betrieb als Routinevorgang: Defektes Laufwerk entfernen, Ersatzdatenträger einsetzen, Rekonstruktion starten und nach Abschluss wieder mit vollständiger Redundanz arbeiten.

Technisch funktioniert das jedoch nur unter klaren Voraussetzungen.

Die verbliebenen Laufwerke müssen vollständig lesbar sein. Die RAID-Konfiguration muss stimmen. Die Laufwerksreihenfolge darf nicht verändert worden sein. Das Dateisystem muss sich in einem konsistenten Zustand befinden. Vor allem aber muss eindeutig sein, welches Laufwerk tatsächlich ausgefallen ist und welche Mitglieder noch den aktuellen Datenstand enthalten.

Fehlt eine dieser Voraussetzungen, kann ein Rebuild abbrechen oder einen inkonsistenten Verbund erzeugen.

Besonders kritisch wird die Situation, wenn bereits während der Rekonstruktion auf die Ersatzplatte geschrieben wurde. Danach existiert nicht mehr nur ein ursprünglicher RAID-Zustand. Es liegen mehrere zeitlich und technisch unterschiedliche Zustände vor, die für eine erfolgreiche Datenrettung korrekt eingeordnet werden müssen.

Was ein RAID-Rebuild technisch tatsächlich macht

Ein Rebuild kopiert nicht einfach den Inhalt einer ausgefallenen Festplatte.

Bei einem paritätsbasierten RAID werden fehlende Datenblöcke aus den verbleibenden Daten- und Paritätsblöcken berechnet. Welche Blöcke dafür benötigt werden, hängt vom RAID-Level und von der konkreten Stripe-Konfiguration ab.

Bei einem klassischen RAID 5 gilt vereinfacht:

Datenblock A XOR Datenblock B XOR Paritätsblock = fehlender Datenblock

Die tatsächliche Verteilung ist jedoch komplexer. Die Parität rotiert je nach Layout über die beteiligten Laufwerke. Zusätzlich müssen unter anderem folgende Parameter korrekt sein:

• Laufwerksreihenfolge,

• Stripe- oder Chunk-Größe,

• Paritätsrotation,

• Startoffset,

• Anzahl der Mitglieder,

• verwendetes RAID-Level,

• Position des fehlenden Laufwerks.

Ein NAS oder RAID-Controller kennt diese Parameter aus seinen Metadaten oder seiner internen Konfiguration. Bei einer manuellen Datenrettung müssen sie dagegen aus den vorhandenen Datenträgern rekonstruiert oder überprüft werden.

Schon eine falsch angenommene Laufwerksreihenfolge kann dazu führen, dass Datenblöcke scheinbar lesbar sind, das Dateisystem aber inkonsistente Strukturen liefert.

Warum ein einzelner Lesefehler während des Rebuilds relevant sein kann

Bei einem degradierten RAID fehlt bereits ein vollständiges Laufwerk. Die noch vorhandenen Festplatten müssen deshalb jeden benötigten Block korrekt liefern.

Kann während des Rebuilds ein weiterer Block nicht gelesen werden, stehen für diesen Stripe möglicherweise zu wenige Informationen zur Verfügung.

Das bedeutet nicht automatisch, dass der gesamte Datenbestand verloren ist. Der Fehler kann sich auf einen einzelnen Bereich beschränken. Kritisch wird es jedoch, wenn der betroffene Stripe wichtige Metadaten enthält, etwa:

• Dateisystem-Superblöcke,

• Verzeichnisstrukturen,

• Journaldaten,

• Allocation Tables,

• B-Trees,

• Volume-Metadaten,

• Datenbankdateien,

• virtuelle Festplatten,

• RAID-interne Verwaltungsbereiche.

Ein einzelner fehlerhafter Datenbereich kann dadurch wesentlich größere logische Folgen haben als seine physische Größe vermuten lässt.

Warum große Festplatten das Rebuild-Risiko erhöhen

Mit steigender Laufwerkskapazität wächst nicht nur die Datenmenge, sondern auch die Zeit, in der die verbliebenen Festplatten unter hoher Leselast arbeiten müssen.

Ein RAID aus mehreren großen HDDs kann während eines Rebuilds viele Terabyte vollständig lesen. Das kann je nach System, Auslastung und Fehlerzustand viele Stunden oder mehrere Tage dauern.

Während dieser Zeit:

• werden große Oberflächenbereiche gelesen,

• werden bislang unbemerkte instabile Sektoren sichtbar,

• steigt die Zahl der internen Lesewiederholungen,

• können schwache Köpfe oder Oberflächenbereiche ausfallen,

• bleibt das RAID ohne vollständige Redundanz,

• werden fortlaufend neue Daten auf das Ersatzlaufwerk geschrieben.

Die lange Dauer erhöht die Wahrscheinlichkeit, dass ein weiteres Problem während des Rebuilds sichtbar wird.

SMART-Werte reichen für eine sichere Beurteilung nicht aus

Vor einem Rebuild wird häufig nur geprüft, ob die verbliebenen Laufwerke laut SMART noch als „gut“ gelten.

Das ist für eine erste Einschätzung hilfreich, aber nicht ausreichend.

SMART-Werte zeigen vor allem bekannte und vom Laufwerk protokollierte Auffälligkeiten. Sie können jedoch nicht zuverlässig garantieren, dass:

• jeder Datenbereich vollständig lesbar ist,

• ein Laufwerk unter Dauerlast stabil bleibt,

• alle Köpfe gleich zuverlässig arbeiten,

• keine zeitabhängigen Fehler auftreten,

• Firmware oder Elektronik unauffällig sind,

• ein beginnender mechanischer Defekt rechtzeitig erkannt wird.

Ein Laufwerk kann einen vollständigen SMART-Status „OK“ melden und dennoch bei der sequentiellen Sicherung bestimmter Bereiche stark einbrechen oder ausfallen.

Für eine belastbare Beurteilung ist deshalb die tatsächliche Lesestabilität wichtiger als ein einzelner Statuswert.

Der Unterschied zwischen „offline“, „failed“ und physisch defekt

Ein RAID-Mitglied, das vom System als „failed“ oder „offline“ markiert wurde, ist nicht automatisch mechanisch defekt.

Ein Laufwerk kann aus dem Verbund entfernt werden, weil:

• es kurzzeitig nicht erreichbar war,

• ein Timeout auftrat,

• zu viele Lesefehler gemeldet wurden,

• ein Kabel- oder Backplane-Problem bestand,

• die Stromversorgung instabil war,

• der Controller das Laufwerk aus Sicherheitsgründen ausgeschlossen hat,

• RAID-Metadaten nicht mehr zum erwarteten Zustand passten.

Umgekehrt kann ein Laufwerk weiterhin als Mitglied angezeigt werden, obwohl es bereits instabile Bereiche besitzt.

Für eine Datenrettung muss deshalb jedes Laufwerk unabhängig vom vom RAID gemeldeten Status untersucht werden.

Entscheidend ist nicht nur, welches Laufwerk offiziell als ausgefallen markiert wurde, sondern:

• welches Laufwerk noch vollständig lesbar ist,

• welches Mitglied den aktuellsten Datenstand enthält,

• ob ein Laufwerk nur kurzzeitig ausgefallen war,

• ob ein Mitglied nach einem Neustart wieder aufgenommen wurde,

• ob unterschiedliche Generationen der RAID-Metadaten vorhanden sind.

Stale Members: Wenn ein Laufwerk technisch lesbar, aber logisch veraltet ist

Ein besonders kritischer Punkt sind sogenannte veraltete oder „stale“ RAID-Mitglieder.

Ein Laufwerk kann physisch vollständig lesbar sein, aber einen älteren Datenstand enthalten. Das passiert beispielsweise, wenn es zeitweise aus dem RAID entfernt wurde und der Verbund danach ohne dieses Laufwerk weiterlief.

Wird dieses Laufwerk später wieder eingesetzt, enthält es möglicherweise:

• ältere Dateisystemdaten,

• veraltete Parität,

• frühere RAID-Metadaten,

• einen älteren Journalzustand,

• nicht mehr aktuelle Verzeichnisstrukturen.

Bei einer Rekonstruktion darf ein solches Mitglied nicht automatisch als vollwertig aktuell behandelt werden.

Ein veraltetes Laufwerk kann einen Verbund scheinbar vervollständigen, gleichzeitig aber inkonsistente Daten liefern. Besonders bei Dateisystem-Metadaten können daraus schwer erkennbare Fehler entstehen.

Deshalb wird bei einer professionellen Analyse nicht nur geprüft, ob Daten vorhanden sind, sondern auch, wie aktuell diese Daten sind.

Warum Zeitstempel und Sequenznummern wichtig sind

Viele RAID-Implementierungen speichern Sequenznummern, Ereigniszähler oder Zeitinformationen in ihren Metadaten.

Diese Werte können Hinweise darauf geben:

• welches Laufwerk zuletzt aktiv war,

• wann ein Mitglied aus dem Verbund entfernt wurde,

• ob ein Rebuild begonnen wurde,

• welche Platte bereits neu synchronisiert wurde,

• welche Mitglieder zum letzten konsistenten Zustand gehörten.

Diese Informationen sind wertvoll, dürfen aber nicht isoliert betrachtet werden.

Ein Controller kann Metadaten aktualisieren, obwohl ein Rebuild später scheitert. Eine Ersatzplatte kann dadurch eine neuere Sequenznummer besitzen als ein älteres Originalmitglied, obwohl sie nur teilweise rekonstruiert wurde.

Die höchste Sequenznummer bedeutet deshalb nicht automatisch, dass dieses Laufwerk den vollständigsten oder besten Datenstand enthält.

Das Problem einer teilweise beschriebenen Ersatzplatte

Wenn ein Rebuild abbricht, enthält das Ersatzlaufwerk eine Mischung aus:

• bereits rekonstruierten Datenbereichen,

• noch nicht beschriebenen oder alten Bereichen,

• aktualisierten RAID-Metadaten,

• möglicherweise unvollständigen Dateisysteminformationen.

Je nach Rebuild-Richtung und Controllerlogik kann sich der gültige Bereich über einen bestimmten Teil des Laufwerks erstrecken. Außerhalb dieses Bereichs können Daten fehlen oder aus einem früheren Zustand stammen.

Diese Ersatzplatte darf weder automatisch verworfen noch ungeprüft als vollwertiges Mitglied verwendet werden.

Sie kann für einzelne Bereiche wertvolle rekonstruierte Daten enthalten. Gleichzeitig kann sie bei falscher Einbindung zu einer inkonsistenten Gesamtstruktur führen.

Für eine erfolgreiche Rekonstruktion muss deshalb der Rebuild-Fortschritt möglichst genau nachvollzogen werden.

Rebuild-Richtung und Fortschritt

Nicht jeder RAID-Rebuild arbeitet in derselben Reihenfolge.

Je nach Controller, NAS-System oder Software-RAID kann die Rekonstruktion:

• vom Anfang zum Ende,

• vom Ende zum Anfang,

• bereichsweise,

• prioritätsgesteuert,

• in mehreren parallelen Zonen,

• anhand genutzter Bereiche

erfolgen.

Eine Prozentanzeige allein reicht daher nicht immer aus, um exakt zu bestimmen, welche Daten bereits geschrieben wurden.

Bei der Analyse werden zusätzlich Datenmuster, Paritätskonsistenz, Dateisystemstrukturen und Metadaten herangezogen, um den nutzbaren Bereich der Ersatzplatte zu bewerten.

Paritätskonsistenz ist nicht gleich Dateisystemkonsistenz

Ein RAID kann auf Blockebene konsistente Parität liefern und trotzdem ein beschädigtes Dateisystem enthalten.

Umgekehrt kann ein Dateisystem in großen Teilen lesbar erscheinen, obwohl einzelne Stripes keine korrekte Parität mehr besitzen.

Diese Ebenen müssen getrennt betrachtet werden:

RAID-Ebene

Hier geht es um:

• Laufwerksreihenfolge,

• Stripe-Aufbau,

• Parität,

• fehlende Mitglieder,

• Datenoffsets,

• RAID-Metadaten.

Volume- und Dateisystemebene

Hier geht es um:

• Partitionierung,

• LVM,

• Volume Groups,

• Btrfs,

• ext4,

• XFS,

• NTFS,

• ReFS,

• ZFS,

• virtuelle Datenträger,

• Datenbanken.

Ein korrekt rekonstruierter RAID-Verbund garantiert nicht automatisch ein fehlerfreies Dateisystem. Insbesondere nach abgebrochenen Rebuilds, Controllerfehlern oder ungeplanten Abschaltungen kann eine zusätzliche logische Rekonstruktion notwendig sein.

Warum Dateisystemreparaturen auf dem Originalverbund gefährlich sind

Nach einem fehlgeschlagenen Rebuild bieten NAS-Systeme oder Betriebssysteme häufig Dateisystemprüfungen an.

Tools wie fsck, CHKDSK oder herstellerspezifische Reparaturfunktionen versuchen, inkonsistente Strukturen zu korrigieren. Dabei können sie:

• Journale zurückspielen,

• Verzeichniseinträge entfernen,

• unzugeordnete Blöcke freigeben,

• beschädigte Metadaten ersetzen,

• Dateien in Fundordner verschieben,

• Datenstrukturen neu schreiben.

Auf einem stabilen und gesicherten System kann das sinnvoll sein.

Auf einem beschädigten RAID ohne vollständige Kopie ist es riskant. Die Reparatur kann Strukturen verändern, die für eine alternative Rekonstruktion noch benötigt würden.

Deshalb sollte vor jeder Dateisystemreparatur ein vollständiges Abbild des bestmöglichen RAID-Zustands erstellt werden.

Controller-Rebuild versus Software-Rekonstruktion

Ein Hardware-RAID-Controller führt einen Rebuild nach seinen internen Regeln durch. Er verwendet die gespeicherten Konfigurationsinformationen und entscheidet, welche Platte Quelle und welche Ziel des Rebuilds ist.

Bei beschädigten oder widersprüchlichen Zuständen kann diese Automatisierung problematisch werden.

Eine softwarebasierte forensische Rekonstruktion arbeitet anders:

• Originaldatenträger werden möglichst nicht beschrieben.

• Laufwerke werden einzeln gesichert.

• Mehrere mögliche RAID-Konfigurationen können getestet werden.

• Veraltete Mitglieder können gezielt ausgeschlossen werden.

• Teilbereiche verschiedener Datenträger können kombiniert werden.

• Parität kann zur Plausibilitätsprüfung genutzt werden.

• Dateisystemstrukturen werden separat bewertet.

Diese Flexibilität ist entscheidend, wenn der ursprüngliche RAID-Zustand nicht mehr eindeutig ist.

Warum die Sicherung der Laufwerke vor der Rekonstruktion kommt

Bei einer professionellen RAID-Datenrettung wird nicht direkt mit den Originalfestplatten rekonstruiert.

Zunächst wird versucht, von jedem beteiligten Laufwerk ein möglichst vollständiges sektorweises Abbild zu erstellen.

Dabei werden instabile Datenträger angepasst behandelt:

• Lesegeschwindigkeit reduzieren,

• problematische Bereiche zunächst überspringen,

• stabile Zonen priorisieren,

• mehrfaches Lesen fehlerhafter Bereiche begrenzen,

• Köpfe oder Zonen getrennt behandeln,

• Laufwerkszustand fortlaufend überwachen.

Ziel ist nicht, eine beschädigte HDD um jeden Preis vollständig auszulesen. Ziel ist, die maximal verwertbare Datenmenge zu sichern, ohne den Zustand unnötig zu verschlechtern.

Erst danach beginnt die eigentliche RAID-Rekonstruktion.

Warum die Originalreihenfolge dokumentiert werden muss

Bei einem RAID mit mehreren baugleichen HDDs ist die Slot-Reihenfolge ein wichtiger Ausgangspunkt.

Je nach System können zwar Metadaten auf den Laufwerken gespeichert sein. Nach Rebuilds, Controllerwechseln oder mehrfachen Umbauten sind diese Informationen aber nicht immer eindeutig.

Deshalb sollten vor dem Ausbau dokumentiert werden:

• Position jedes Laufwerks,

• Seriennummer,

• Modellnummer,

• vom System gemeldete Rolle,

• Status des Laufwerks,

• Zeitpunkt des Ausfalls,

• durchgeführte Austauschvorgänge.

Die Festplatten sollten nach dem Ausbau physisch mit ihrer ursprünglichen Position gekennzeichnet werden.

Eine vertauschte Reihenfolge kann bei der automatischen Rekonstruktion scheinbar plausible, aber logisch falsche Daten liefern.

Wie Stripe-Größe und Paritätsrotation ermittelt werden

Sind RAID-Metadaten beschädigt oder fehlen sie vollständig, müssen die Parameter aus den Nutzdaten abgeleitet werden.

Dafür können unter anderem genutzt werden:

• bekannte Dateisystemsignaturen,

• periodische Metadatenstrukturen,

• Partitionstabellen,

• Superblöcke,

• wiederkehrende Datenmuster,

• Paritätsbeziehungen,

• Datenbankseiten,

• virtuelle Festplattenstrukturen.

Durch Vergleich möglicher Laufwerksreihenfolgen und Stripe-Größen lässt sich prüfen, bei welcher Konfiguration zusammenhängende Dateisystemstrukturen entstehen.

Die Parität dient zusätzlich als Plausibilitätskontrolle. Stimmt die angenommene Konfiguration, müssen Daten- und Paritätsblöcke innerhalb eines Stripes zueinander passen.

Umgang mit fehlenden Sektoren

Bei beschädigten Laufwerken lassen sich nicht immer alle Sektoren lesen.

In einem RAID können fehlende Bereiche teilweise aus Parität rekonstruiert werden. Das funktioniert jedoch nur, solange innerhalb eines Stripes nicht mehr Informationen fehlen, als das RAID-Level kompensieren kann.

Bei RAID 5 kann ein fehlender Block rekonstruiert werden. Fehlen im selben Stripe zwei notwendige Blöcke, reicht die einfache Parität nicht mehr aus.

Bei RAID 6 können unter geeigneten Bedingungen zwei fehlende Blöcke rekonstruiert werden.

In der Praxis entstehen Fehler jedoch nicht immer sauber blockweise. Ein beschädigter Lesekopf kann große, zusammenhängende Bereiche einer Oberfläche betreffen. Dadurch können auf mehreren Laufwerken gleichzeitig Lücken in denselben logischen Bereichen entstehen.

Die Rekonstruktion muss deshalb sektor- und stripebezogen bewertet werden.

Warum RAID 6 nicht automatisch einfach ist

RAID 6 besitzt zwei unabhängige Paritätsinformationen und kann normalerweise zwei vollständig ausgefallene Laufwerke verkraften.

Die mathematische Rekonstruktion ist jedoch komplexer als bei RAID 5. Zusätzlich existieren verschiedene Implementierungen für die zweite Parität.

Für eine manuelle Rekonstruktion müssen daher nicht nur Reihenfolge und Stripe-Größe, sondern auch das konkrete RAID-6-Layout korrekt bestimmt werden.

Fehlerhafte Annahmen können dazu führen, dass eine Rekonstruktion scheinbar Daten liefert, die auf Dateisystemebene jedoch nicht konsistent sind.

Besonderheiten bei RAID 10

RAID 10 wird häufig als unkompliziert betrachtet, weil Daten gespiegelt sind.

In der Praxis hängt die Wiederherstellbarkeit davon ab, welche Mitglieder ausgefallen sind.

Fallen zwei Laufwerke aus unterschiedlichen Spiegelpaaren aus, kann der Verbund möglicherweise vollständig bleiben. Fallen beide Mitglieder desselben Spiegelpaars aus, fehlt der entsprechende Datenbereich vollständig.

Zusätzlich können Spiegelmitglieder unterschiedliche Aktualitätsstände besitzen, etwa wenn ein Laufwerk zeitweise offline war.

Auch bei RAID 10 muss deshalb geprüft werden:

• Welche HDDs bilden ein Spiegelpaar?

• Welches Mitglied ist aktuell?

• Gab es einen Resync?

• Sind beide Spiegel vollständig?

• Enthalten sie identische Metadatenstände?

SHR, mdadm und LVM

Viele Synology-Systeme verwenden SHR. Technisch basiert die Umsetzung häufig auf Linux-Komponenten wie mdadm und LVM.

Ein Speicherpool kann deshalb aus mehreren Ebenen bestehen:

1. physische Festplatten,

2. RAID-Sets,

3. LVM Physical Volumes,

4. Volume Groups,

5. Logical Volumes,

6. Dateisysteme wie ext4 oder Btrfs.

Bei unterschiedlichen Laufwerksgrößen kann SHR mehrere RAID-Bereiche mit unterschiedlicher Zusammensetzung anlegen.

Die Datenrettung besteht dann nicht aus einer einzigen RAID-Rekonstruktion. Es müssen mehrere RAID-Segmente korrekt zusammengesetzt und anschließend auf LVM- und Dateisystemebene verbunden werden.

Btrfs und Snapshots

Btrfs wird häufig auf modernen NAS-Systemen eingesetzt. Es bietet Prüfsummen, Copy-on-Write und Snapshot-Funktionen.

Diese Eigenschaften verbessern die Integrität und Flexibilität, machen die Rekonstruktion nach einem beschädigten RAID aber nicht automatisch einfacher.

Durch Copy-on-Write können mehrere Generationen von Metadaten vorhanden sein. Das kann bei einer Analyse hilfreich sein, weil ältere Strukturen erhalten geblieben sein können.

Gleichzeitig können Inkonsistenzen zwischen RAID-, LVM- und Btrfs-Ebene entstehen. Ein logisch korrekter RAID-Verbund muss deshalb zusätzlich auf gültige Btrfs-Roots, Trees und Chunk-Strukturen geprüft werden.

ZFS, RAIDZ und Scrubs

ZFS verwendet End-to-End-Prüfsummen und erkennt beschädigte Datenblöcke sehr zuverlässig. Bei vorhandener Redundanz kann es fehlerhafte Daten aus einer korrekten Kopie reparieren.

Ein ZFS-Scrub ist jedoch kein Ersatz für eine Datenrettung bei bereits instabilen Laufwerken.

Ein Scrub liest große Teile des Pools und kann dadurch ähnliche Belastungen erzeugen wie ein Rebuild. Wenn bereits mehrere Datenträger geschwächt sind, kann der Vorgang weitere Ausfälle sichtbar machen.

Auch bei ZFS gilt daher: Vor einem intensiven Prüf- oder Resilver-Vorgang muss die Stabilität der verbleibenden Laufwerke berücksichtigt werden.

Typischer Ablauf nach einem gescheiterten Rebuild

Ein komplexer RAID-Fall sieht häufig so aus:

1. Eine Festplatte fällt aus.

2. Der Verbund läuft degradiert weiter.

3. Eine Ersatzplatte wird eingesetzt.

4. Der Rebuild startet.

5. Eine zweite HDD entwickelt Lesefehler.

6. Der Rebuild bricht ab.

7. Das System wird mehrfach neu gestartet.

8. Laufwerke werden ausgebaut oder vertauscht.

9. Der Controller erkennt eine fremde oder unvollständige Konfiguration.

10. Eine Initialisierung oder Neuerstellung wird angeboten.

Zu diesem Zeitpunkt existieren möglicherweise mehrere unvollständige Zustände.

Die Aufgabe des Datenrettungslabors besteht dann nicht darin, einfach den Rebuild erneut zu starten. Zunächst muss der letzte konsistente Zustand rekonstruiert werden.

Professioneller Analyseablauf

Eine strukturierte RAID-Analyse umfasst typischerweise folgende Schritte:

1. Dokumentation

Erfassung von:

• RAID-System,

• Controller oder NAS-Modell,

• Laufwerkspositionen,

• Seriennummern,

• bekannten Fehlermeldungen,

• bisherigen Rebuilds,

• erfolgten Austauschvorgängen.

2. Einzelprüfung der Datenträger

Bewertung von:

• Erkennbarkeit,

• SMART- und Fehlerprotokollen,

• Lesestabilität,

• mechanischem Zustand,

• Firmware,

• Elektronik,

• vorhandenen RAID-Metadaten.

3. Sektorweise Sicherung

Erstellung möglichst vollständiger Abbilder. Instabile Laufwerke werden priorisiert und schonend gelesen.

4. RAID-Rekonstruktion

Bestimmung von:

• RAID-Level,

• Reihenfolge,

• Stripe-Größe,

• Paritätslayout,

• Offset,

• gültigen und veralteten Mitgliedern.

5. Konsistenzprüfung

Überprüfung von:

• Parität,

• Partitionierung,

• LVM,

• Dateisystem,

• Datenbank- und VM-Strukturen.

6. Dateisystemauswertung

Rekonstruktion der Ordner- und Dateistrukturen sowie Bewertung beschädigter Bereiche.

7. Ergebnisprüfung

Stichproben, Dateiintegrität, Datenbankkonsistenz und priorisierte Prüfung besonders wichtiger Dateien.

Wann ein Rebuild gestoppt werden sollte

Ein laufender Rebuild sollte kritisch bewertet werden, wenn:

• die Geschwindigkeit massiv einbricht,

• neue Lesefehler auftreten,

• ein weiteres Laufwerk aus dem Verbund fällt,

• mechanische Geräusche entstehen,

• der Fortschritt über lange Zeit unverändert bleibt,

• der Controller wiederholt Resets meldet,

• der Speicherpool nicht mehr reagiert.

Ein Abbruch ist ebenfalls ein Eingriff und sollte nicht unüberlegt erfolgen. Wenn wichtige Daten betroffen sind, ist jedoch ein kontrollierter Stopp häufig besser als ein Rebuild, der mehrere instabile Laufwerke weiter belastet.

Wann eine professionelle RAID-Datenrettung notwendig wird

Eine professionelle Analyse ist besonders sinnvoll, wenn:

• mehr als ein Laufwerk ausgefallen ist,

• ein Rebuild abgebrochen wurde,

• die Ersatzplatte teilweise beschrieben ist,

• die Laufwerksreihenfolge unklar ist,

• Mitglieder unterschiedliche Aktualitätsstände besitzen,

• RAID-Metadaten beschädigt sind,

• der Controller eine fremde Konfiguration meldet,

• das Dateisystem nicht mehr eingebunden wird,

• virtuelle Maschinen oder Datenbanken betroffen sind,

• kein aktuelles Backup vorhanden ist.

Gerade bei geschäftskritischen Systemen sollte nicht versucht werden, die Konfiguration durch mehrere automatische Reparaturen zu erraten.

Welche Informationen für die Analyse wichtig sind

Für eine erste technische Einschätzung helfen:

• Hersteller und Modell von NAS oder Server,

• RAID-Controller oder HBA,

• RAID-Level,

• Anzahl und Kapazität der Datenträger,

• ursprüngliche Laufwerksreihenfolge,

• Seriennummern,

• genaue Fehlermeldungen,

• Fortschritt eines begonnenen Rebuilds,

• Reihenfolge aller bisherigen Maßnahmen,

• Zustand jeder HDD,

• verwendetes Dateisystem,

• Art der gespeicherten Daten.

Besonders wichtig ist die zeitliche Abfolge. Ein scheinbar kleines Detail, etwa welches Laufwerk zuerst entfernt wurde, kann für die Rekonstruktion entscheidend sein.

Was ein fehlgeschlagener Rebuild technisch hinterlässt

Ein gescheiterter Rebuild ist selten nur ein abgebrochener Kopiervorgang.

Er kann hinterlassen:

• unterschiedliche Generationen von RAID-Metadaten,

• teilweise aktualisierte Parität,

• eine unvollständige Ersatzplatte,

• stale Members,

• inkonsistente Journale,

• beschädigte Dateisystemstrukturen,

• widersprüchliche Sequenznummern,

• teilweise rekonstruierte Nutzdaten.

Genau deshalb darf die Ersatzplatte nicht automatisch als wertlos gelten. Ebenso darf das offiziell ausgefallene Originalmitglied nicht automatisch ausgeschlossen werden.

Die erfolgreichste Rekonstruktion kann eine gezielte Kombination aus mehreren Laufwerken und Datenständen erfordern.

Einschätzung aus dem RAID-Labor

Der Rebuild selbst ist nicht das Problem. Er ist ein notwendiger Mechanismus zur Wiederherstellung der Redundanz.

Problematisch wird er, wenn seine Voraussetzungen nicht erfüllt sind.

Ein Controller oder NAS kann nicht in jedem Fall erkennen, ob alle verbliebenen Laufwerke vollständig lesbar sind, ob ein Mitglied veraltet ist oder ob die gespeicherten RAID-Metadaten noch den tatsächlichen Zustand des Verbunds widerspiegeln.

Bei wichtigen Daten sollte deshalb nicht nur gefragt werden, ob das System einen Rebuild anbietet.

Die entscheidende Frage lautet:

Ist der vorhandene Laufwerkssatz technisch und logisch konsistent genug, damit dieser Rebuild gefahrlos auf den Originaldatenträgern durchgeführt werden kann?

Wenn diese Frage nicht eindeutig beantwortet werden kann, ist eine vorherige Sicherung der beteiligten Laufwerke der sicherere Weg.