RAID-Rebuild abgebrochen: Was jetzt technisch entscheidend ist

Wenn ein scheinbar normaler Wiederaufbau den Verbund weiter verändert

Ein RAID-Rebuild beginnt oft mit einer klaren Ausgangslage: Eine Festplatte ist ausgefallen, der Verbund läuft degradiert, ein Ersatzlaufwerk wird eingesetzt. Das System startet die Wiederherstellung und soll die verlorene Redundanz wiederherstellen.

Solange alle verbleibenden Laufwerke stabil sind, die Konfiguration stimmt und das Dateisystem konsistent ist, kann dieser Vorgang problemlos funktionieren.

In der Praxis sehen wir jedoch immer wieder Fälle, in denen der Rebuild nicht abgeschlossen wird. Die Fortschrittsanzeige bleibt stehen, eine weitere Festplatte meldet Fehler, der Controller verliert ein Laufwerk oder der Speicherpool lässt sich nach dem nächsten Neustart nicht mehr einbinden.

Ab diesem Moment ist die Situation technisch nicht mehr mit dem ursprünglichen Ausfall vergleichbar.

Der Rebuild hat bereits Daten geschrieben. Metadaten können aktualisiert worden sein. Das Ersatzlaufwerk enthält möglicherweise nur einen Teil des rekonstruierten Datenbestands. Gleichzeitig können ursprüngliche RAID-Mitglieder unterschiedliche Aktualitätsstände aufweisen.

Die zentrale Aufgabe besteht dann nicht darin, den Rebuild einfach erneut zu starten.

Zuerst muss geklärt werden, welcher Laufwerkssatz noch den letzten konsistenten Datenstand enthält.

Warum ein RAID-Rebuild nur unter klaren Voraussetzungen funktioniert

Ein Rebuild setzt voraus, dass alle noch benötigten Daten- und Paritätsblöcke gelesen werden können.

Bei einem RAID 5 fehlt bereits ein vollständiges Laufwerk. Die Daten dieses Laufwerks werden aus den übrigen Mitgliedern und der vorhandenen Parität berechnet.

Vereinfacht gilt innerhalb eines Stripes:

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

In realen Systemen müssen dafür jedoch mehrere Parameter exakt stimmen:

• Laufwerksreihenfolge,

• Stripe- oder Chunk-Größe,

• Position des fehlenden Mitglieds,

• Paritätsrotation,

• Datenoffset,

• RAID-Level,

• Anzahl der Laufwerke,

• aktueller Stand der RAID-Metadaten.

Der Controller oder das NAS verwendet dafür seine gespeicherte Konfiguration. Ist diese Konfiguration beschädigt, unvollständig oder durch vorherige Eingriffe verändert, kann der Rebuild mit falschen Voraussetzungen arbeiten.

Auch ein technisch korrekt konfigurierter Rebuild kann scheitern, wenn eine weitere HDD bestimmte Bereiche nicht mehr lesen kann.

Was ein einzelner Lesefehler im degradierten RAID bewirken kann

Solange alle Laufwerke vorhanden sind, kann ein RAID je nach Level einzelne Lesefehler oft aus der vorhandenen Redundanz korrigieren.

Im degradierten Zustand ist diese Reserve bereits teilweise oder vollständig aufgebraucht.

Fehlt bei RAID 5 eine Festplatte und kann innerhalb desselben Stripes ein weiterer Block nicht gelesen werden, stehen nicht mehr genügend Informationen zur vollständigen Rekonstruktion zur Verfügung.

Der unmittelbare Schaden kann auf wenige Sektoren begrenzt sein. Die logischen Auswirkungen hängen jedoch davon ab, welche Daten dort gespeichert waren.

Besonders kritisch sind Lesefehler in Bereichen mit:

• Dateisystem-Superblöcken,

• B-Trees,

• Verzeichnisstrukturen,

• Journaldaten,

• LVM-Metadaten,

• RAID-Verwaltungsdaten,

• Datenbankseiten,

• virtuellen Festplatten,

• Exchange-, SQL- oder ERP-Daten,

• Metadaten großer Backup-Container.

Ein kleiner physischer Fehler kann dadurch einen wesentlich größeren Bereich logisch unzugänglich machen.

Weshalb große HDDs den Rebuild anspruchsvoller machen

Je größer die Festplatten, desto mehr Daten müssen während eines vollständigen Wiederaufbaus gelesen und geschrieben werden.

Ein RAID aus mehreren 12-, 16-, 20- oder 24-TB-Laufwerken kann über lange Zeit im degradierten Zustand bleiben. Der tatsächliche Rebuild kann je nach Systemlast, Controller, Schnittstelle und Zustand der HDDs viele Stunden oder mehrere Tage dauern.

Währenddessen:

• laufen alle verbleibenden Laufwerke unter hoher Leselast,

• werden auch lange nicht verwendete Bereiche angesprochen,

• treten instabile Sektoren deutlicher hervor,

• steigt die Zahl interner Lesewiederholungen,

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

• wird die Ersatzplatte fortlaufend beschrieben,

• bleibt die normale Redundanz eingeschränkt.

Der Rebuild wird damit zu einem vollständigen Belastungstest für den Restverbund.

Warum SMART allein keine ausreichende Entscheidungsgrundlage ist

Vor einem Rebuild wird häufig geprüft, ob die verbleibenden Festplatten einen unauffälligen SMART-Status anzeigen.

Das ist sinnvoll, reicht für eine belastbare Beurteilung aber nicht aus.

SMART kann Hinweise auf bekannte Probleme liefern, etwa:

• wiederzugewiesene Sektoren,

• schwebende Sektoren,

• Schnittstellenfehler,

• hohe Temperaturen,

• Start- und Betriebsstunden,

• protokollierte Leseprobleme.

SMART kann jedoch nicht garantieren, dass:

• jeder Bereich vollständig lesbar ist,

• ein Laufwerk unter Dauerlast stabil bleibt,

• alle Leseköpfe gleich zuverlässig arbeiten,

• keine zeitabhängigen Aussetzer auftreten,

• die Firmware stabil reagiert,

• ein mechanischer Defekt rechtzeitig erkannt wird.

Ein Laufwerk kann „SMART OK“ melden und beim sequenziellen Lesen trotzdem massiv einbrechen.

Für die Beurteilung vor einer Rekonstruktion ist deshalb die tatsächliche Lesestabilität entscheidend.

„Failed“ bedeutet nicht automatisch physisch defekt

Ein RAID-Controller kann ein Laufwerk aus dem Verbund entfernen, obwohl die HDD selbst noch grundsätzlich lesbar ist.

Mögliche Ursachen sind:

• Timeouts,

• kurzzeitige Verbindungsabbrüche,

• Backplane-Probleme,

• instabile Stromversorgung,

• zu viele Lesefehler in kurzer Zeit,

• Controller-Resets,

• inkonsistente RAID-Metadaten,

• Firmwareprobleme,

• SATA- oder SAS-Kommunikationsfehler.

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

Für eine professionelle RAID-Analyse ist deshalb nicht nur der vom System gemeldete Status relevant.

Wichtig ist:

• Welche HDD ist tatsächlich physisch beschädigt?

• Welches Laufwerk ist vollständig lesbar?

• Welches Mitglied enthält den aktuellsten Datenstand?

• Wurde ein Laufwerk nur vorübergehend ausgeschlossen?

• Welche Platte war während späterer Schreibvorgänge noch aktiv?

• Welche RAID-Metadaten sind konsistent?

Veraltete RAID-Mitglieder und unterschiedliche Datenstände

Ein RAID-Mitglied kann technisch vollständig lesbar sein und trotzdem nicht mehr zum aktuellen Verbund passen.

Das ist beispielsweise der Fall, wenn eine HDD zeitweise offline war und das RAID ohne sie weiterlief. Während dieser Zeit wurden Daten geändert, Dateien gelöscht, neue Daten geschrieben oder Metadaten aktualisiert.

Das zurückkehrende Laufwerk enthält dann einen älteren Zustand.

Ein solches Mitglied wird häufig als „stale“ bezeichnet.

Darauf können sich befinden:

• ältere Nutzdaten,

• veraltete Paritätsblöcke,

• frühere Dateisystemzustände,

• ältere Journale,

• überholte RAID-Sequenznummern,

• nicht mehr aktuelle Verzeichnisstrukturen.

Wird ein stale Member ungeprüft in die Rekonstruktion einbezogen, kann der Verbund auf Blockebene scheinbar vollständig sein, aber logisch widersprüchliche Daten liefern.

Deshalb ist nicht nur die Lesbarkeit, sondern auch die zeitliche Einordnung jedes Laufwerks entscheidend.

Warum die höchste Sequenznummer nicht automatisch den besten Stand zeigt

Viele RAID-Systeme speichern Ereigniszähler, Generationen oder Sequenznummern in den RAID-Metadaten.

Diese Werte helfen dabei, aktive und veraltete Mitglieder zu unterscheiden. Sie müssen jedoch im Zusammenhang mit dem gesamten Ablauf betrachtet werden.

Ein Beispiel:

Eine neue Ersatzplatte wird eingesetzt. Der Rebuild beginnt. Die RAID-Metadaten der Ersatzplatte werden aktualisiert. Der Vorgang bricht jedoch nach 35 Prozent ab.

Die Ersatzplatte kann nun eine neuere Sequenznummer besitzen als ein ursprüngliches Mitglied. Trotzdem enthält sie nur einen Teil des rekonstruierten Datenbestands.

Die höchste Generation bedeutet daher nicht automatisch:

• vollständigster Datenstand,

• korrektes Dateisystem,

• vollständig rekonstruierte Parität,

• bestes Laufwerk für die Wiederherstellung.

Metadaten müssen immer mit Nutzdaten, Rebuild-Fortschritt und Dateisystemstrukturen abgeglichen werden.

Die besondere Rolle einer teilweise beschriebenen Ersatzplatte

Eine Ersatzplatte nach einem abgebrochenen Rebuild ist weder einfach leer noch vollständig aktuell.

Sie kann enthalten:

• korrekt rekonstruierte Bereiche,

• noch nicht beschriebene Zonen,

• ältere Restdaten,

• aktualisierte RAID-Metadaten,

• teilweise aktuelle Dateisystemstrukturen,

• unvollständige Parität.

Ob und wie dieses Laufwerk verwendet werden kann, hängt vom Rebuild-Verlauf ab.

Wichtige Fragen sind:

• In welcher Richtung lief der Rebuild?

• Wurde linear oder zonenweise gearbeitet?

• Wie weit war der Vorgang tatsächlich fortgeschritten?

• Welche Bereiche wurden bereits geschrieben?

• Wurden nur verwendete Bereiche oder das gesamte Laufwerk rekonstruiert?

• Welche Metadaten wurden zu Beginn aktualisiert?

• Ist die Prozentanzeige technisch verlässlich?

Eine teilweise beschriebene Ersatzplatte kann für einzelne Bereiche wertvoll sein. Sie darf aber nicht ungeprüft als vollständig aktuelles Mitglied behandelt werden.

Warum die Prozentanzeige allein wenig aussagt

Eine Anzeige von 40 Prozent vermittelt den Eindruck, dass die ersten 40 Prozent des Laufwerks bereits korrekt rekonstruiert wurden.

Das muss nicht stimmen.

Je nach System kann ein Rebuild:

• vom Anfang zum Ende,

• vom Ende zum Anfang,

• in Zonen,

• parallel in mehreren Bereichen,

• anhand belegter Daten,

• prioritätsgesteuert,

• blockgruppenweise

durchgeführt werden.

Zusätzlich kann die Oberfläche Fortschritt nach Datenmenge, Stripe-Anzahl oder internen Arbeitsabschnitten anzeigen.

Für die technische Bewertung müssen deshalb Datenmuster, Parität, Metadaten und Dateisystemstrukturen herangezogen werden.

RAID-Konsistenz und Dateisystemkonsistenz sind nicht dasselbe

Ein RAID kann auf Blockebene korrekt rekonstruiert sein und trotzdem ein beschädigtes Dateisystem enthalten.

Das passiert beispielsweise nach:

• ungeplanten Abschaltungen,

• Controllerfehlern,

• abgebrochenen Rebuilds,

• Schreibvorgängen während des degradierten Betriebs,

• inkonsistenten Journaldaten,

• Fehlern in LVM oder Volume-Management,

• beschädigten Dateisystemmetadaten.

Die Analyse muss deshalb mehrere Ebenen getrennt betrachten.

Physische Ebene

• Zustand der Festplatten,

• Lesbarkeit der Sektoren,

• Köpfe, Oberflächen, Elektronik und Firmware.

RAID-Ebene

• Laufwerksreihenfolge,

• Stripe-Größe,

• Paritätslayout,

• Offset,

• fehlende und veraltete Mitglieder.

Volume-Ebene

• Partitionierung,

• LVM,

• Storage Pools,

• virtuelle Disks,

• Thin Provisioning.

Dateisystemebene

• ext4,

• XFS,

• Btrfs,

• NTFS,

• ReFS,

• ZFS,

• VMFS oder weitere Strukturen.

Anwendungsebene

• Datenbanken,

• virtuelle Maschinen,

• Mailserver,

• Backup-Container,

• ERP- und Dokumentenmanagementsysteme.

Ein korrekt zusammengesetztes RAID ist daher oft nur der erste Schritt.

Weshalb fsck, CHKDSK und automatische Reparaturen riskant sind

Nach einem Rebuild-Abbruch bieten Systeme häufig eine Dateisystemprüfung an.

Reparaturtools versuchen, Inkonsistenzen zu beseitigen. Dabei können sie:

• Journale zurückspielen,

• Verzeichniseinträge löschen,

• beschädigte Inodes verwerfen,

• freie Blöcke neu berechnen,

• B-Trees verändern,

• verlorene Dateien in Fundordner verschieben,

• Metadaten neu schreiben.

Auf einem gesicherten Arbeitsabbild kann das sinnvoll sein.

Auf dem einzigen Originalverbund ist es riskant.

Eine Reparatur kann Strukturen entfernen, die für eine alternative Rekonstruktion noch benötigt werden. Sie kann außerdem einen logisch konsistenten, aber unvollständigen Zustand erzeugen, in dem wichtige Daten nicht mehr referenziert werden.

Deshalb sollte vor jeder Dateisystemreparatur eine vollständige Sicherung des bestmöglichen RAID-Zustands vorhanden sein.

Warum die Sicherung vor der Rekonstruktion steht

Bei einer professionellen Datenrettung werden die beteiligten Datenträger möglichst nicht direkt für Rekonstruktionsversuche verwendet.

Zunächst wird von jeder Festplatte ein sektorweises Abbild erstellt.

Bei instabilen Laufwerken wird die Lesestrategie an den Zustand angepasst:

• stabile Bereiche zuerst lesen,

• problematische Zonen überspringen,

• Lesegeschwindigkeit reduzieren,

• Wiederholungsversuche begrenzen,

• Köpfe oder Oberflächen getrennt behandeln,

• kritische Metadatenbereiche priorisieren,

• Temperatur und Reaktionsverhalten überwachen.

Das Ziel ist nicht, eine beschädigte HDD mit maximaler Belastung vollständig auszulesen.

Ziel ist, möglichst viele verwertbare Daten zu sichern, bevor sich der Zustand weiter verschlechtert.

Rekonstruktion auf Arbeitskopien statt auf Originalmedien

Mit Abbildern oder Arbeitskopien können unterschiedliche RAID-Konfigurationen getestet werden, ohne die Originaldatenträger weiter zu verändern.

Das ermöglicht:

• verschiedene Laufwerksreihenfolgen,

• unterschiedliche Stripe-Größen,

• alternative Paritätslayouts,

• Ausschluss veralteter Mitglieder,

• Kombination mehrerer Datenstände,

• sektorweise Rekonstruktion fehlender Bereiche,

• getrennte Dateisystemanalysen,

• Wiederholung von Versuchen ohne erneute Belastung der HDDs.

Gerade bei widersprüchlichen Metadaten ist diese Flexibilität entscheidend.

Wie die richtige RAID-Konfiguration ermittelt wird

Sind die RAID-Metadaten vollständig und glaubwürdig, liefern sie wichtige Parameter.

Fehlen sie oder widersprechen sie sich, müssen die Eigenschaften aus den Daten abgeleitet werden.

Dafür können verwendet werden:

• Partitionstabellen,

• Superblöcke,

• Dateisystemsignaturen,

• wiederkehrende Metadaten,

• Datenbankseiten,

• virtuelle Festplattenstrukturen,

• bekannte Dateiinhalte,

• Paritätsbeziehungen,

• LVM-Header,

• Volume- und Poolinformationen.

Mehrere mögliche Konfigurationen werden gegeneinander geprüft.

Eine plausible Rekonstruktion muss nicht nur einzelne lesbare Dateien erzeugen. Sie sollte auch konsistente Dateisystemstrukturen, Verzeichnisse, Metadaten und Paritätsbeziehungen liefern.

Paritätsprüfung als Plausibilitätskontrolle

Bei RAID 5 kann die Parität verwendet werden, um eine angenommene Laufwerksreihenfolge und Stripe-Größe zu überprüfen.

Stimmt das Layout, müssen die Datenblöcke und der Paritätsblock innerhalb eines Stripes mathematisch zusammenpassen.

Bei RAID 6 ist die Situation komplexer, da zwei unterschiedliche Paritätsinformationen vorhanden sind. Je nach Controller oder Software-RAID kommen unterschiedliche Layouts und Algorithmen zum Einsatz.

Die Paritätsprüfung ist deshalb ein wichtiges Werkzeug, aber kein automatischer Beweis für ein vollständig korrektes Dateisystem.

Fehlende Sektoren und Rekonstruktion aus Parität

Sind einzelne Bereiche eines Laufwerks nicht lesbar, können sie je nach RAID-Level rechnerisch rekonstruiert werden.

Bei RAID 5 funktioniert das, solange innerhalb eines Stripes nur ein erforderlicher Block fehlt.

Bei RAID 6 können unter passenden Voraussetzungen zwei fehlende Blöcke rekonstruiert werden.

In der Praxis sind Ausfälle jedoch oft nicht gleichmäßig verteilt.

Ein defekter Lesekopf kann einen großen Bereich einer Oberfläche betreffen. Eine zweite HDD kann gleichzeitig einzelne instabile Sektoren enthalten. Dadurch entstehen in bestimmten logischen Bereichen mehrere Lücken im selben Stripe.

Die Wiederherstellbarkeit muss daher stripeweise betrachtet werden.

Besonderheiten bei RAID 6

RAID 6 bietet eine höhere Ausfallsicherheit, ist aber in der manuellen Rekonstruktion anspruchsvoller.

Neben der Laufwerksreihenfolge und Stripe-Größe müssen bestimmt werden:

• Verteilung der ersten Parität,

• Verteilung der zweiten Parität,

• verwendetes RAID-6-Layout,

• Rotation der Paritätsblöcke,

• Implementierung des Controllers oder Software-RAID.

Eine falsch angenommene zweite Parität kann Daten erzeugen, die auf den ersten Blick strukturiert wirken, auf Anwendungsebene jedoch beschädigt sind.

RAID 10: Spiegelung schützt nicht vor jedem Zustand

Bei RAID 10 hängt die Ausfallsicherheit davon ab, welche Laufwerke betroffen sind.

Fallen zwei HDDs aus unterschiedlichen Spiegelpaaren aus, kann der Verbund vollständig bleiben. Fallen beide Mitglieder desselben Paars aus, fehlt der entsprechende Datenbereich.

Zusätzlich können Spiegelpartner unterschiedliche Aktualitätsstände enthalten.

Zu prüfen ist daher:

• Welche Laufwerke bilden ein Spiegelpaar?

• Welches Mitglied wurde zuletzt beschrieben?

• Gab es einen Resync?

• War ein Laufwerk zeitweise offline?

• Sind beide Kopien vollständig?

• Stimmen Metadaten und Journale überein?

Ein physisch gut lesbarer Spiegel kann logisch veraltet sein.

Synology SHR und mehrschichtige Speicherpools

Synology SHR basiert häufig auf mehreren technischen Ebenen.

Ein typischer Aufbau kann enthalten:

1. physische Festplatten,

2. mehrere mdadm-RAID-Bereiche,

3. LVM Physical Volumes,

4. Volume Groups,

5. Logical Volumes,

6. ext4 oder Btrfs.

Bei unterschiedlich großen Laufwerken kann SHR mehrere RAID-Segmente mit unterschiedlicher Zusammensetzung erzeugen.

Die Rekonstruktion besteht dann nicht aus einem einzigen RAID-Satz. Mehrere Bereiche müssen einzeln korrekt zusammengesetzt und anschließend auf der LVM- und Dateisystemebene verbunden werden.

Btrfs nach einem fehlgeschlagenen Rebuild

Btrfs arbeitet mit Copy-on-Write, Prüfsummen und baumartigen Metadatenstrukturen.

Das kann bei einer Datenrettung Vorteile bieten, weil ältere Metadatengenerationen teilweise noch vorhanden sind.

Gleichzeitig können mehrere Ebenen inkonsistent sein:

• RAID-Verbund,

• LVM,

• Btrfs-Chunks,

• Trees,

• Root-Strukturen,

• Snapshots.

Ein auf Blockebene plausibles RAID muss daher zusätzlich auf gültige Btrfs-Strukturen geprüft werden.

ZFS, RAIDZ und Resilver

ZFS erkennt beschädigte Datenblöcke durch End-to-End-Prüfsummen. Bei ausreichender Redundanz können fehlerhafte Blöcke aus korrekten Kopien rekonstruiert werden.

Ein Resilver oder Scrub liest jedoch große Datenbereiche und belastet die beteiligten Laufwerke.

Wenn bereits mehrere HDDs instabil sind, kann ein solcher Vorgang weitere Ausfälle sichtbar machen.

Auch bei ZFS gilt deshalb: Vor einem intensiven Resilver oder Scrub sollte berücksichtigt werden, ob die verbleibenden Laufwerke noch stabil genug sind.

Virtuelle Maschinen und Datenbanken im RAID

RAID-Ausfälle betreffen in Unternehmen häufig nicht nur normale Dateien.

Auf dem Verbund liegen möglicherweise:

• VMware- oder Hyper-V-Datenträger,

• SQL-Datenbanken,

• Exchange-Datenbanken,

• ERP-Systeme,

• Backup-Repositories,

• Container-Volumes,

• große Archivdateien.

Solche Daten reagieren besonders empfindlich auf einzelne fehlende oder fehlerhafte Bereiche.

Eine virtuelle Festplatte kann grundsätzlich eingebunden werden, während ein kritischer Bereich innerhalb des Gastdateisystems fehlt. Eine Datenbank kann vollständig vorhanden wirken, aber einzelne Seitenfehler oder inkonsistente Logs enthalten.

Deshalb muss die Ergebnisprüfung über die reine Dateiextraktion hinausgehen.

Ein typischer Verlauf aus der Praxis

Ein RAID 5 aus vier HDDs verliert ein Laufwerk.

Der Server bleibt online. Eine Ersatzplatte wird eingesetzt. Der Rebuild beginnt.

Nach mehreren Stunden meldet eine weitere HDD Lesefehler. Der Controller setzt das Laufwerk zurück, die Rekonstruktion wird langsamer und bricht schließlich ab.

Danach folgen mehrere Neustarts. Die ursprüngliche ausgefallene HDD wird erneut eingesetzt. Der Controller erkennt eine fremde Konfiguration. Eine Importfunktion wird ausgeführt. Anschließend ist das Volume nicht mehr verfügbar.

Nun liegen mehrere konkurrierende Zustände vor:

• ursprüngliches ausgefallenes Mitglied,

• instabile zweite HDD,

• teilweise beschriebene Ersatzplatte,

• aktualisierte Controller-Metadaten,

• möglicherweise veraltete Mitglieder,

• beschädigtes Dateisystem.

Eine erneute automatische Rekonstruktion würde diese Unsicherheit nicht beseitigen.

Zuerst muss der Ablauf zeitlich und technisch rekonstruiert werden.

Strukturierter Analyseablauf im RAID-Labor

1. Dokumentation des Systems

Erfasst werden:

• Hersteller und Modell,

• RAID-Controller oder NAS,

• RAID-Level,

• Festplattenanzahl,

• Slot-Reihenfolge,

• Seriennummern,

• Fehlermeldungen,

• Rebuild-Fortschritt,

• bisherige Eingriffe.

2. Einzelanalyse der Datenträger

Geprüft werden:

• stabile Erkennung,

• Lesegeschwindigkeit,

• Fehlerbereiche,

• mechanische Auffälligkeiten,

• Firmware,

• Elektronik,

• RAID-Metadaten,

• zeitlicher Datenstand.

3. Sektorweise Sicherung

Von jedem Laufwerk wird ein möglichst vollständiges Abbild erstellt. Instabile HDDs werden mit angepasster Lesestrategie behandelt.

4. Klassifizierung der Mitglieder

Festgestellt wird:

• aktuell,

• veraltet,

• teilweise rekonstruiert,

• physisch beschädigt,

• logisch ausgeschlossen,

• Ersatzlaufwerk,

• ursprünglich fehlendes Mitglied.

5. Rekonstruktion der RAID-Parameter

Bestimmt werden:

• Reihenfolge,

• Stripe-Größe,

• Offset,

• Paritätsrotation,

• RAID-6-Layout,

• gültige Mitglieder,

• nutzbare Teilbereiche.

6. Volume- und Dateisystemanalyse

Geprüft werden:

• Partitionierung,

• LVM,

• Storage Pools,

• Dateisystem,

• virtuelle Disks,

• Datenbanken und Anwendungen.

7. Validierung

Die Ergebnisse werden anhand von:

• Paritätskonsistenz,

• Dateisystemstrukturen,

• Dateiöffnungen,

• Datenbankprüfungen,

• VM-Integrität,

• Stichproben

bewertet.

Wann ein laufender Rebuild kritisch wird

Ein Rebuild sollte technisch neu bewertet werden, wenn:

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

• die Geschwindigkeit massiv einbricht,

• neue Lesefehler auftreten,

• ein weiteres Laufwerk aus dem Verbund fällt,

• der Controller wiederholt Resets meldet,

• mechanische Geräusche entstehen,

• das System nicht mehr reagiert,

• das Volume während der Rekonstruktion verschwindet.

Ein unkontrolliertes Ausschalten kann ebenfalls Risiken haben. Bei wichtigen Daten ist jedoch ein kontrollierter Stopp häufig besser als ein Vorgang, der instabile Laufwerke weiter belastet und Originaldaten verändert.

Wann eine professionelle Analyse notwendig ist

Eine technische RAID-Datenrettung sollte insbesondere geprüft werden, wenn:

• mehr als ein Laufwerk betroffen ist,

• ein Rebuild abgebrochen wurde,

• die Ersatzplatte teilweise beschrieben ist,

• Mitglieder unterschiedliche Datenstände enthalten,

• die Laufwerksreihenfolge unklar ist,

• RAID-Metadaten widersprüchlich sind,

• eine fremde Konfiguration importiert wurde,

• das Dateisystem nicht mehr eingebunden wird,

• Datenbanken oder virtuelle Maschinen betroffen sind,

• kein aktuelles Backup vorhanden ist.

Welche Informationen für eine erste Einschätzung wichtig sind

Hilfreich sind:

• NAS-, Server- und Controller-Modell,

• RAID-Level,

• Anzahl und Kapazität der Laufwerke,

• Seriennummern,

• ursprüngliche Slot-Reihenfolge,

• genaue Fehlermeldungen,

• Stand eines begonnenen Rebuilds,

• Reihenfolge aller bisherigen Maßnahmen,

• Zustand der einzelnen Festplatten,

• verwendetes Dateisystem,

• enthaltene Anwendungen und Datenarten.

Die zeitliche Reihenfolge ist oft genauso wichtig wie die technische Konfiguration.

Was nach einem gescheiterten Rebuild erhalten bleiben sollte

Folgende Komponenten sollten möglichst unverändert aufbewahrt werden:

• alle ursprünglichen RAID-Mitglieder,

• ausgefallene oder ausgeschlossene HDDs,

• die teilweise beschriebene Ersatzplatte,

• Controller oder NAS, falls relevant,

• Screenshots der Fehlermeldungen,

• Dokumentation der Slot-Reihenfolge,

• Protokolle und Ereignismeldungen,

• Informationen zu Austausch- und Rebuild-Vorgängen.

Keine Festplatte sollte vorschnell als unwichtig betrachtet werden.

Das offiziell ausgefallene Laufwerk kann noch wertvolle Datenbereiche enthalten. Die Ersatzplatte kann bereits rekonstruierte Bereiche liefern. Ein stale Member kann für bestimmte ältere Strukturen relevant sein.

Einschätzung aus unserem RAID-Labor

Ein fehlgeschlagener Rebuild ist nicht einfach ein Reparaturvorgang, der noch einmal gestartet werden muss.

Er kann einen Verbund hinterlassen, in dem mehrere Daten- und Metadatengenerationen gleichzeitig existieren.

Die Aufgabe besteht dann darin, diese Zustände korrekt zu klassifizieren und den bestmöglichen konsistenten Datenstand zu rekonstruieren.

Dafür müssen physischer Zustand, Parität, RAID-Metadaten, Laufwerksreihenfolge, Rebuild-Fortschritt, Volume-Struktur und Dateisystem gemeinsam betrachtet werden.

Je weniger nach dem Abbruch auf den Originaldatenträgern verändert wurde, desto besser lässt sich der ursprüngliche Zustand nachvollziehen.

Die entscheidende Frage lautet daher nicht:

Kann der Controller den Rebuild noch einmal starten?

Sondern:

Welche Laufwerke und Datenbereiche bilden noch den letzten technisch und logisch konsistenten Zustand des RAID?