Datenrettung für RAID, NAS und Storage-Systeme

Ein RAID erhöht die Verfügbarkeit, schützt aber nicht vor Fehlbedienung oder mehreren Defekten; Laufwerksreihenfolge, Geometrie und Ereignisfolge müssen vor jedem Rebuild gesichert werden.

Angebot anfordern

Ausgeschaltetes NAS mit eindeutig beschrifteten Laufwerkseinschüben nach einem zweiten Disk-Ausfall

Erste Maßnahme

Nach dem zweiten Laufwerksausfall NAS stoppen und Einschübe erhalten

Meldet ein NAS nach einem degradierten Zustand ein zweites ausgefallenes Laufwerk, endet jeder weitere Startversuch. Einschub, Seriennummer und zeitliche Reihenfolge der Ausfälle sind jetzt ebenso wichtig wie der Inhalt der einzelnen Disks. Laufwerke werden nicht vertauscht, neu eingesetzt oder probeweise als Ersatz bestätigt. Das System bleibt ausgeschaltet, bis die Ausgangslage dokumentiert ist.

Fotografiert werden Front, Bay-Nummern, LEDs, Controlleranzeige, Kabel und vorhandene Beschriftungen. Exportierte Konfigurationen und Logs sind nützlich, sofern das instabile System dafür nicht neu gestartet werden muss. Ausgebaute Mitglieder, Hot Spares und früher entfernte „defekte“ Disks bleiben erhalten. Ein älteres Mitglied kann für Metadaten oder einen früheren konsistenten Zeitstand entscheidend sein.

Die Chronologie umfasst Stromausfall, Firmwareupdate, Laufwerkstausch, Rebuildbeginn, Abbruch, Controllerwechsel und jede Initialisierung. Ein als foreign, unconfigured oder failed markiertes Laufwerk wird nicht automatisch wieder eingebunden. Diese Zustände beschreiben die Sicht des Controllers, nicht zwingend den physischen Datenbestand. Cachemodule und Verschlüsselungsschlüssel gehören ebenfalls zur Quellkonfiguration.

Bei einem noch erreichbaren Share werden Schreibzugriffe, Snapshots, Backupjobs und Replikation kontrolliert gestoppt. Laufende Dienste können Journale und Datenbanken weiter verändern, während ein Mitglied bereits fehlerhaft liest. Priorisierte Informationen werden nur gesichert, wenn das Risiko eines weiteren Storagezugriffs vertretbar ist. Ein kurzer Dateizugriff beweist keine Verbundkonsistenz.

NAS nach zweitem Ausfall nicht erneut starten
Bay, Seriennummer und Status jedes Mitglieds dokumentieren
Entfernte Disks, Cachemodule und Controllerkonfiguration erhalten

Bay-Reihenfolge sichern

Fotos und Beschriftungen verbinden jedes Medium mit Einschub, Rolle und Zeitpunkt. Ausprobieren erzeugt keine verlässliche Topologie.

Vorherige Ausfälle erhalten

Ein früher entferntes Mitglied kann ältere, aber konsistente Blöcke oder ursprüngliche RAID-Metadaten tragen.

Ein Controllerstatus ist eine Momentaufnahme; er ersetzt weder die physische Prüfung noch die zeitliche Einordnung jedes RAID-Mitglieds.

Gestoppter RAID-Rebuild mit geschützten Originalmitgliedern und noch nicht überschriebenen Paritätsblöcken

Rebuild-Risiko

Einen Rebuild nicht fortsetzen, wenn die Restkonsistenz ungeklärt ist

Ein Rebuild setzt voraus, dass RAID-Level, Reihenfolge, Geometrie und alle verbleibenden Mitglieder korrekt und ausreichend lesbar sind. Er liest den gesamten Verbund intensiv und schreibt rekonstruierte Blöcke zurück; eine falsche Annahme wird dadurch zum neuen Zustand. Latente Sektorfehler oder ein zweites schwaches Laufwerk können während dieses Vorgangs sichtbar werden und den Schaden erweitern.

Nach einem abgebrochenen Rebuild können Mitglieder unterschiedliche Zeitstände enthalten. Die Ersatzdisk trägt bereits neue Parität, während ein Originalmitglied ältere Nutzdaten bewahrt. Keines wird als alleinige Wahrheit behandelt. Schreibzähler, RAID-Metadaten, Dateisystemstrukturen und bekannte Dateien helfen, die zeitliche Zusammensetzung auf Arbeitskopien zu bewerten.

Eine neue Disk wird nicht initialisiert, formatiert oder als Spare bestätigt. Controllerfunktionen wie „Force Online“, „Initialize“, „Repair Pool“ oder „Resync“ bleiben aus. Sie können Metadaten und Nutzblöcke verändern. Auch ein scheinbar ungefährlicher Dateisystemcheck arbeitet oberhalb des Arrays und setzt voraus, dass die darunterliegende Blockfolge bereits korrekt ist.

Mehrere Geometrien und Zeitstände lassen sich vergleichen, ohne Originalmedien zu beschreiben. Ein Rebuild kann später auf neuer Infrastruktur Teil des Wiederanlaufs sein, aber erst nach gesicherter Datenrettung und fachlicher Abnahme, nicht als Diagnosewerkzeug. Stattdessen wird jedes Mitglied separat erfasst und der RAID-Verbund virtuell rekonstruiert.

Rebuild, Resync und Pool-Reparatur sofort anhalten
Ersatzdisk und Originalmitglieder getrennt sichern
Hypothesen ausschließlich auf schreibgeschützten Abbildern testen

Abgebrochener Rebuild

Mitglieder können danach verschiedene Blockgenerationen enthalten. Ersatz und Originale bleiben getrennte Quellen.

Force Online vermeiden

Das Erzwingen eines Mitglieds kann falsche Metadaten akzeptieren und weitere Schreibvorgänge auf dem Verbund auslösen.

Ein Rebuild ist ein Schreibvorgang zur Wiederherstellung von Redundanz, keine beweissichere Methode zur Bestimmung der richtigen RAID-Geometrie.

Beschriftete RAID-Festplatten und SSDs werden einzeln mit Fehlerkarten und angepasster Lesestrategie abgebildet

Imaging

Jedes RAID-Mitglied nach seinem physischen Zustand separat abbilden

Jede Festplatte oder SSD erhält ein eigenes Abbild, eine Fehlerkarte und eine eindeutige Zuordnung zu Bay und Seriennummer. Auch ein scheinbar gesundes Mitglied bleibt schreibgeschützt, weil seine Metadaten und ältere Blöcke für die Rekonstruktion benötigt werden können. Leseprotokolle unterscheiden bestätigte, instabile und nicht erreichbare Bereiche. Fehler werden nicht unbemerkt mit Nullen ersetzt.

Bei mechanischen Festplatten bestimmen Geräusche, Sturz, Anlaufverhalten und Fehlerzonen die Lesereihenfolge. Klickende oder schleifende Medien werden nicht wiederholt im NAS gestartet. Eine Öffnung in geeigneter kontrollierter Umgebung ist nur bei diagnostiziertem mechanischem Schaden relevant. Die Datenrettung im Reinraum erklärt diesen gezielten Schritt; gute RAID-Mitglieder werden nicht unnötig geöffnet.

SSDs und Flashcache benötigen eine andere Strategie. Controller, Firmware, NAND-Verschleiß, TRIM und interne Speicherbereinigung wirken ohne mechanische Symptome. Ein Cachemedium wird nach seiner Rolle im Verbund bewertet und nicht als eigenständiges Datenvolume interpretiert. Stromzyklen werden begrenzt, wenn der Controller instabil antwortet.

Bei schwachen Disks können zuerst RAID-Metadaten, Dateisystemstrukturen und priorisierte Datenbereiche gesichert werden. Mehrere Lesepässe werden verglichen; bereits bestätigte Bereiche bleiben unverändert. Diese Strategie nutzt ein begrenztes Lesefenster, ohne eine Vollständigkeit zu versprechen, die der physische Zustand nicht trägt. Danach folgen weniger kritische Zonen, solange die Mechanik stabil bleibt.

Jedes Mitglied mit eigener Fehlerkarte erfassen
Mechanische und Flashmedien unterschiedlich behandeln
Priorisierte Zonen vor belastenden Wiederholungen sichern

Mechanische Festplatten

Kopfzustand und Fehlerzonen bestimmen Zahl und Reihenfolge der Zugriffe; Reinraumarbeit bleibt mechanisch begründeten Fällen vorbehalten.

SSD und Flashcache

TRIM, Controller und Cachefunktion verändern die Bewertung. Ein geräuschloses Medium kann dennoch hochgradig instabil sein.

Die Qualität der virtuellen RAID-Rekonstruktion kann nie besser sein als die dokumentierten Abbilder ihrer einzelnen Mitglieder.

RAID-Mitglieder werden nach Reihenfolge, Stripe-Größe, Startoffset und Paritätsrotation logisch angeordnet

Geometrie

Reihenfolge, Stripe-Größe, Offset und Paritätsrotation gemeinsam bestimmen

RAID 0, 1, 5, 6 und 10 verteilen Daten, Spiegel und Parität unterschiedlich. Hinzu kommen SHR, mdadm, Storage Spaces und proprietäre Controllerlayouts. Eine richtige Laufwerksreihenfolge allein genügt nicht: Stripe-Größe, Startoffset, Paritätsrotation und bei RAID 10 die Spiegelpaarung müssen gemeinsam stimmen. Sonst können Ordner sichtbar sein, während Dateiinhalte über Stripe-Grenzen beschädigt werden.

RAID-Metadaten liefern Hinweise auf Level, UUID, Ereigniszähler und Rollen. Sie können nach einem Rebuild oder Controllerwechsel widersprüchlich sein. Wiederkehrende Dateisystemstrukturen, Partitionstabellen, bekannte Header und Paritätsbeziehungen ergänzen die Bewertung. Mehrere Hypothesen werden virtuell berechnet; keine Konfiguration wird auf die Originaldisks geschrieben.

Kleine Dokumente im ersten Stripe reichen nicht

Die beste Geometrie muss reale Dateien über unterschiedliche Größen und Bereiche konsistent wiedergeben. Archive, Bilder, virtuelle Disks und Datenbanken über mehrere Mitglieder hinweg werden stichprobenartig geprüft. Nicht lesbare Blöcke bleiben markiert, damit ein plausibles Layout nicht mit vollständiger Datenintegrität verwechselt wird.

Eine zufällige lokale Paritätsübereinstimmung ist kein Beweis

Bei RAID 5 und 6 wird die Lage beziehungsweise Rotation der Parität über mehrere Stripes geprüft. Bei RAID 10 müssen Mirrors und Stripe-Reihenfolge korrekt zusammenfinden. Proprietäre NAS-Layouts können zusätzliche Systempartitionen oder versetzte Nutzdatenbereiche enthalten, die nicht mit dem ersten sichtbaren Offset beginnen.

Virtuell rekonstruierter RAID-Blockverbund mit darüberliegenden LVM-, Btrfs- und ZFS-Volumes vor dem Mounten

Schichtenmodell

RAID virtuell rekonstruieren, bevor Volumes oder Pools geöffnet werden

Aus den Mitgliedsabbildern entsteht ein schreibgeschützter virtueller Blockverbund. Erst danach werden Partitionen und darüberliegende Ebenen untersucht. Ein NAS kann mdadm mit LVM, Btrfs oder ext kombinieren; andere Systeme verwenden ZFS, Storage Pools, Thin Provisioning, Deduplizierung oder Verschlüsselung. Jede Schicht besitzt eigene Metadaten und darf nicht die Fehler der darunterliegenden Ebene verdecken.

Zunächst werden Arraygeometrie und fehlende Bereiche stabil dargestellt. Darauf folgen Partitionen, Poolmitglieder, logische Volumes, Snapshots und Dateisysteme. Reparaturprogramme laufen nur auf einer weiteren Arbeitskopie. Ein mountbares Volume beweist nicht, dass die Geometrie stimmt; erst Dateien über verschiedene Stripes und Metadatenbäume zeigen eine belastbare Kombination.

Btrfs und ZFS besitzen Prüfsummen, Mirrors, Parität und Snapshots auf eigener Ebene. Diese Funktionen können Fehler erkennen und teilweise alternative Kopien liefern, ersetzen aber nicht die korrekte Rekonstruktion des darunterliegenden RAID. Deduplizierte oder komprimierte Pools benötigen ihre Referenz- und Metadatenblöcke; eine einzelne verlorene Struktur kann viele logisch getrennte Dateien betreffen.

Schlüsselmaterial wird getrennt von allgemeinen Logs aufbewahrt

Verschlüsselte Volumes benötigen gültige Schlüssel und eine autorisierte Bearbeitung. Bei fehlenden Poolmitgliedern oder Metadaten werden mehrere Zustände getrennt geprüft. Das Ergebnis kann ein vollständiges Volume, ein konsistenter älterer Snapshot oder ein gezielter Dateiexport sein; die Herkunft bleibt dokumentiert.

Für den Wiederanlauf entsteht neue, geprüfte Infrastruktur

Der rekonstruierte Bestand wird nicht auf das beschädigte NAS zurückgeschrieben. Erst nach der Datenabnahme werden ein neues Array und Backups aufgebaut. Der alte Verbund bleibt Quelle der Rettung und erhält keine Reparaturfreigabe durch einen erfolgreichen virtuellen Mount.

NAS-Freigaben, virtuelle Maschinen, Sicherungen und Datenbanken werden nach Wiederanlaufbedarf priorisiert

Geschäftspriorität

Freigaben, virtuelle Maschinen, Backups und Datenbanken unterschiedlich priorisieren

Ein NAS kann aktuelle Benutzerfreigaben, VM-Datastores, Kameraarchive, Backups und Datenbanken gleichzeitig enthalten. Die erste Lesepassage richtet sich nach dem tatsächlichen Wiederanlaufbedarf, nicht nach Dateigröße oder Verzeichnisreihenfolge. Der Auftraggeber benennt Dienst, Zeitraum, Pfad, verantwortliche Person und gewünschtes Ausgabeformat. Alte Archive folgen, wenn kritische Daten gesichert sind.

Freigaben werden mit bekannten Projekten und Rechten geprüft. Virtuelle Maschinen benötigen Deskriptoren, Deltas und alle zugehörigen Disks; die Datenrettung virtueller Festplatten behandelt Snapshotketten. Datenbanken verlangen zusammenpassende Daten- und Transaktionslogs. Ein kopierbarer Container ist noch kein anwendungsfähiger Bestand.

Backups werden inventarisiert, aber nicht über die Quelle zurückgespielt. Ein gültiger Sicherungsstand kann den fehlenden Zeitraum verkleinern; ein unvollständiges Repository kann selbst vom beschädigten Pool abhängen. Backupkatalog, Chunks und Schlüssel werden gemeinsam geprüft. Bereits vorhandene Kopien behalten Herkunft und Zeitstand, statt das gerettete Ergebnis künstlich zu vergrößern.

Bei sensiblen Unternehmens-, Gesundheits- oder Forschungsdaten werden berechtigte Ansprechpartner und Prüfbereiche begrenzt. Eine technische Ordneransicht kann Berechtigungen, Versionen oder Anwendungsbeziehungen nicht allein validieren. Priorisierte Stichproben erfolgen mit Personen, die den fachlichen Inhalt kennen.

Wiederanlaufkritische Shares zuerst benennen
VM- und Datenbankabhängigkeiten vollständig erfassen
Backups als getrennte Zeitstände und Quellen behandeln

Dateifreigaben und Rechte

Bekannte Projekte, Zeitstände und Zugriffsstrukturen werden stichprobenartig mit fachlichen Ansprechpartnern kontrolliert.

VM und Datenbank

Container, Logs, Konfigurationen und externe Volumes müssen denselben konsistenten Zeitpunkt abbilden.

Ein terabytegroßer Export kann geschäftlich wertlos sein, wenn die aktuelle Datenbank oder das einzige noch nicht gesicherte Projekt fehlt.

Rekonstruiertes RAID-Volume wird mit Dateien über Stripe-Grenzen, Prüfsummen und Anwendungstests validiert

Qualitätsnachweis

Konsistenz weit über ein erfolgreich gemountetes Volume hinaus validieren

Ein falsches RAID-Layout kann einen glaubhaften Verzeichnisbaum erzeugen. Die Validierung öffnet deshalb Dateien, die verschiedene Mitglieder und Stripe-Grenzen nutzen, und verbindet technische mit fachlichen Stichproben. Dokumente, Archive, Medien, virtuelle Disks und Datenbanken erhalten passende Tests. Dateiname und Größe allein reichen nicht.

Das Rekonstruktionsprotokoll nennt Mitgliedsabbilder, Reihenfolge, Stripe, Offset, Paritätsrotation und nicht gelesene Bereiche. Prüfsummen identifizieren die verwendeten Quellen. Fehlende Blöcke werden, soweit möglich, betroffenen Dateien zugeordnet. Ein RAID-Level kann einzelne Ausfälle kompensieren, aber mehrere fehlende Blöcke im selben Stripe bleiben eine technische Grenze.

Btrfs-, ZFS- oder Anwendungsprüfsummen helfen, Korruption zu erkennen, sind aber kein pauschaler Vollständigkeitsbeweis. Auch Daten ohne gespeicherte Prüfsumme müssen getestet werden. Datenbanken werden mit bekannten Datensätzen und Logs geöffnet, VMs isoliert gestartet und Backuparchive probeweise gelesen. Beschädigte Ergebnisse bleiben getrennt.

Die Übergabe erfolgt auf einem gesunden Zielmedium mit Manifest, Grenzen und Prioritätenstatus. Nach der Abnahme kann die IT neue Infrastruktur aufbauen und geprüfte Daten importieren. Die ursprünglichen Mitglieder bleiben bis zum vereinbarten Abschluss unverändert verfügbar. Ein rekonstruierter Pool wird nicht auf den geschädigten Verbund zurückgespielt.

Geometrie und Quellabbilder im Bericht festhalten
Dateien über mehrere Stripe-Grenzen inhaltlich prüfen
Teilresultate und nicht lesbare Bereiche klar kennzeichnen

Blockbezogene Kontrolle

Fehlerkarten und Stripe-Zuordnung zeigen, welche Dateien von fehlenden Mitgliedsblöcken betroffen sein können.

Fachliche Kontrolle

Bekannte Datensätze, Projekte und Zeitstände bestätigen, ob die technisch lesbaren Dateien den benötigten Inhalt tragen.

Mountbarkeit zeigt eine mögliche Struktur; erst Dateien und Anwendungen über den gesamten Verbund belegen deren Nutzbarkeit.

Bay-Plan, beschriftete RAID-Mitglieder, Controllerprotokolle und NAS-Konfiguration liegen für die Diagnose bereit

Auftrag

Bay-Plan, Controllerprotokolle und NAS-Konfiguration vollständig vorbereiten

Für die Erstbewertung werden Hersteller, Modell, Controller, RAID-Level soweit bekannt, Anzahl und Kapazität der Disks sowie der ursprüngliche Bay-Plan benötigt. Nennen Sie Fehlermeldungen, Ausfallreihenfolge, Rebuilds, Ersatzlaufwerke, Firmwareupdates und Restores. Fotos und exportierte Konfigurationen sind hilfreich, sofern kein instabiles NAS dafür neu gestartet wird.

Die Datenrettung für Server ordnet Dienste und Hardwareabhängigkeiten ein. Mechanische Festplatten bleiben stromlos und werden pro Einschub antistatisch sowie stoßgeschützt verpackt. Der Ablauf der Datenrettung beschreibt Diagnose, Freigabe und Übergabe. Keine Disk wird vorher initialisiert oder mit einem Dateisystemcheck verändert.

Ein Inventar verhindert, dass unter Zeitdruck neue Annahmen über Reihenfolge und Rolle entstehen

Beim Versand bleiben Einschübe und Disks eindeutig gekoppelt; schwere Teile und Netzteile liegen nicht lose daneben. Bereits entfernte Mitglieder und vorhandene technische Images werden mitgeliefert und beschrieben.

Verschlüsselungsschlüssel werden sicher getrennt übermittelt

Die Prioritätenliste benennt Shares, VM, Datenbanken, Backups, Zeiträume und akzeptablen Wiederherstellungspunkt. Das Angebot richtet sich nach Zahl und Zustand der Mitglieder, Geometrie, Poolschichten und Anwendungsprüfung. Die Anzahl der Terabytes allein beschreibt den Aufwand nicht.

Häufige Fragen

Warum kann ein weiterer RAID-Rebuild den vorhandenen Schaden vergrößern?

Der Rebuild liest alle verbliebenen Mitglieder intensiv und schreibt rekonstruierte Blöcke zurück. Schwache Sektoren, falsche Reihenfolge oder ein zweiter Ausfall können dadurch aus einer Hypothese einen neuen inkonsistenten Zustand machen. Jedes Mitglied wird zuerst separat abgebildet; die Rekonstruktion erfolgt virtuell auf Kopien.

Wie wichtig ist die ursprüngliche Laufwerksreihenfolge im NAS?

Sie ist oft entscheidend, reicht allein aber nicht. Bay-Folge, Stripe-Größe, Startoffset, Paritätsrotation und bei RAID 10 die Spiegelpaarung müssen zusammenpassen. Kennzeichnen Sie jedes Mitglied mit Einschub und Seriennummer und bewahren Sie auch früher entfernte Disks sowie Ersatzlaufwerke auf.

Kann RAID-Parität beliebig viele ausgefallene Laufwerke ersetzen?

Nein. Jedes RAID-Level toleriert nur bestimmte Ausfallmuster. Fehlen mehrere Blöcke im selben Stripe oder sind weitere Mitglieder in diesen Zonen unlesbar, bleibt der Inhalt dort möglicherweise verloren. Der Bericht nennt nicht gelesene Bereiche und prüft Dateien über Stripe-Grenzen statt nur den Ordnerbaum.

Warum reicht ein sichtbares NAS-Volume nicht als Qualitätsnachweis?

Eine falsche Geometrie kann plausible Verzeichnisse zeigen und Dateiinhalte unbemerkt zusammensetzen. Dokumente, Archive, virtuelle Maschinen und Datenbanken werden formatspezifisch geprüft. Darüberliegende Ebenen wie LVM, Btrfs, ZFS, Deduplizierung oder Verschlüsselung müssen ebenfalls konsistent rekonstruiert sein.

Datenträger

Weitere Fachbereiche

Diagnose

Unsicher bei Datenträger oder Schadenbild?

Datastrophe bewertet das Risiko vor jedem Eingriff und nennt den vorsichtigsten nächsten Schritt.

Diagnose anfragen