Datenrettung bei RAID-Systemen
Retter in der Not
Wer Datensicherheit sagt, meint RAID. Häufig läuft immer noch RAID 5 oder der De-facto-Standard RAID 6. Auch die moderne Welt der Virtualisierung basiert auf Festplattenverbünden. NAS-Appliances sind in ihrem Inneren ebenso RAIDs. Obwohl Parity Codes bei einem RAID-6-Verbund den Ausfall zweier Festplatten verkraften können, ist auch hier Datenverlust möglich - eine Datenrettung allerdings auch.
Alle RAID-Typen (Redundant Array of Independent Disks) bergen zwei Ausfallrisiken:
Hardwareausfall und logische Fehler. Die Grenzen sind fließend: Hardwaredefekte führen häufig zur
Beschädigung der logischen Strukturen. Logische Schäden sind häufig Folgen eines Bedienungsfehlers.
Die Änderung der Datenorganisation etwa oder fehlerhafte und fehlende zentrale Verzeichnisse führen
zu Fehlern. Wer etwa die Zuteilung des Speicherplatzes in einem als virtuellen RAID organisierten
Verbund von Festplatten verändert, schneidet unter Umständen alte Daten aus seiner LUN. Der
Controller versucht dann, Datensektoren abzurufen, die nun von anderen Informationen belegt
sind.
Generell hängt die Sicherheit davon ab, ob Verbünde mehr auf Schnelligkeit oder Sicherheit
ausgerichtet sein sollen. Hohe Performance durch Striping (RAID 0) ohne jede Sicherung, höchste
Sicherheit und Redundanz durch Mirroring (RAID 1) sowie die Möglichkeit der Berechnung von
Kontroll-Parities, die so Festplattenausfälle auffangen (RAID 5 und RAID 6), bieten
unterschiedliche Levels von Datensicherheit. Bei virtuellen RAIDs wird das Mosaik noch viel bunter,
da hier verschiedenste Spielarten parallel laufen können.
Doch gleich, wie viele Ausfälle von Festplatten ein RAID verkraften kann, eine endgültige
Sicherheit gibt es nicht. Von Herstellern und Wissenschaftlern zu findende Berechnungen kalkulieren
eine theoretische Durchschnittszeit bis zum Datenverlust (Mean Time to Data Loss, MTDL) aus dem
Zusammenspiel der Faktoren MTTF (Mean Time to Failure, Durchschnittszeit bis zum Fehler), MTTR
(Mean Time to Recovery, durchschnittliche Wiederherstellungszeit) und der Anzahl der Festplatten.
Bei einem Array mit 60 Laufwerken tritt danach unter normalen Betriebsbedingungen und gleichen
Fehlerwahrscheinlichkeiten bei RAID 5 nach sechs Monaten ein Datenverlust ein, bei RAID 6 erst nach
25 Jahren.
Auch nach diesen Kalkulationen bestünde bei einem RAID 6 immer noch ein Restrisiko von fünf
Prozent für einen Datenverlust innerhalb von fünf Jahren. RAID 6 stellt sicher einen Zuwachs an
Datensicherheit dar, aber solche auf Laborbedingungen fußende Kalkulationen geben die Realität
nicht wieder: Einige Hauptfehlerquellen – etwa Bedienungsfehler – werden komplett ausgeklammert.
Dabei sind Bedienungsfehler in virtuellen Umgebungen laut den Erfahrungen von Kroll Ontrack die
Ursache für 65 Prozent der Datenverluste.
Datenrettung im RAID
Herkömmliche RAIDs bieten keine absolute Sicherheit. Zwar können RAID-6-Systeme sogar den
Ausfall von zwei Platten verkraften. Doch wenn aus diesem Gefühl der Sicherheit heraus der erste
Plattenausfall ignoriert wird, schlägt beim nächsten Ausfall dann doch die Stunde des
Datenververlusts.
Die Gründe für Hardwareausfälle sind vielfältig: Entweder sind einzelne Bereiche oder
Schreib-/Leseköpfe defekt oder der Controller versagt zum Beispiel durch Überhitzung. Häufig sind
auch Fehler der Backplane oder ein Connectivity-Problem des Einschubs Ursache dafür, dass ein RAID
ausfällt. Nicht zu unterschätzen ist auch das Risiko, dass der RAID-Controller seine Konfiguration
verliert.
Eine weitere Gefahrenquelle ist die Kombination aus Bediener- und Hardwarefehler, wie
beispielsweise der unsachgemäße Ersatzteilaustausch. Auch ein gewissenhafter IT-Spezialist kann oft
nicht nachvollziehen, wieso ein Ersatz-Controller oder eine vermeintlich baugleiche Platine zu
Folgeschäden und Datenverlust führen. In einem Fall hatte ein Controller eine Platte auf defekt
geschaltet. Ein Techniker tauschte die Backplane und wollte einen Rebuild durchführen. Da aber die
Platte nicht identisch war, startete der Rebuild nicht. Vorübergehend lief nun RAID 5 mit zwei
Platten im Degraded Mode anstatt mit drei. Im nächsten Versuch startete auch eine korrekte,
baugleiche Platte nicht die Wiedererrichtung des Verbundes. Nach einem Reboot wurde über das BIOS
des Controllers die neue korrekte Platte per „Add and Migrate“ in das RAID 5 eingefügt. Später
stellte sich heraus, dass für den Controller die alte, defekte Platte noch im Verbund war.
Vermutlich war nun in der Zwischenzeit ein RAID 5 über vier Platten mit defekter Platte in Betrieb
und wurde so falsch neu berechnet. Ein schneller Neustart des Servers führte nun dazu, dass keine
Daten mehr auszulesen waren. Dem Unternehmen bleibt dann nur eine Rekonstruktion aus dem alten
Backup oder der Gang zum Datenretter.
Bedienfehler sind oft die Ausfallursache. Häufig werden Bordmittel zum falschen Zeitpunkt
eingesetzt. So wird nach einem Plattenausfall das RAID neu initialisiert, wo eigentlich ein Rebuild
auf der Agenda stünde – und selbst dieser ist nicht risikofrei. Unerkannte strukturelle und
physikalische Probleme lassen sich so nicht wegkorrigieren. Gefährlich ist die fehlerhafte
Neuinitialisierung deshalb, weil die neue Parity unter Mitberücksichtigung alter Parities und
sozusagen als neue Parity der Ersatzfestplatte geschrieben wird, anstatt aus den verbliebenen guten
Festplatten die fehlende Festplatte auf der Ersatzfestplatte wieder aufzubauen.
Das kann auch professionellen Anbietern dezidierter Server passieren. In einem Fall bestand der
RAID-5-Verbund aus drei 700-GByte-HDDs unter Windows mit NTFS-Dateisystem. Nach dem Austausch einer
Festplatte führte der Rebuild aus unerklärlichen Gründen zum Verlust aller Daten. Dann erfolgten
Neupartitionierung und Neuinstallation. Aus ursprünglich drei Volumes wurden nun zwei NTFS-Volumes.
Nun blendeten die Datenretter mit einem speziellen Tool die Änderungen durch Rebuild und
Neuinstallation aus. Dies muss sehr schnell gehen. Je mehr man hier weitergearbeitet hätte, umso
mehr Daten wären überschrieben worden. Überschriebenes kann auch nicht mehr ausgeblendet werden, da
die elektromagnetischen Zustände und damit die Daten definitiv verändert sind.
Im Verlauf der Bemühungen musste eine Festplatte, die schon zu stark beschädigt war, aus dem
Datenrettungsprozess genommen werden. In der Folge musste auch ein Volume unberücksichtigt bleiben.
Der durch die neuen Daten in der Neuinstallation überschriebene Bereich hatte schon zuviel Schaden
produziert. Glücklicherweise waren hier nur Systemdateien betroffen. Nach Fehlerkontrolle und
Filterung waren 550 GByte mit wichtigen Kundendaten zu retten.
Virtualisierung und RAID
RAIDs werden auch für virtuelle Umgebungen immer wichtiger. Großflächige virtuelle
Infrastrukturen fußen immer auf Verbünden von Festplatten. Ein HP-EVA-SAN-System zum Beispiel
basiert auf RAID-6-Systemen. Datacore Sanmelody oder auch Sun ZFS sind im Unterbau oft ebenfalls
mit RAID-Algorithmen abgesichert. Unabhängig von der Hardware verteilen diese Lösungen die
Informationen. Einzelfestplatten werden zu LUNs zusammengeschaltet und die Daten nach
RAID-Prinzipien darauf verteilt: Ein solcher hardwareunabhängiger RAID-Verbund unterliegt aber auch
den allgemeinen RAID-Ausfallrisiken. Diese Gefahr wird oft unterschätzt, und Backups fehlen dann.
Im SAN einer Behörde mit 88 Festplatten à 320 GByte zum Beispiel fielen nach einem Wasserschaden 24
Platten aus. Ein unsachgemäßer Ausbau machte den Einsatz von Datenrettern erforderlich.
Fast banal, folgenschwer und in der Praxis häufig ist das Abschalten einer LUN in einer Art
Spanset über mehrere LUNs. Das kommt im Ergebnis einem Plattenausfall gleich. Die komplexen
Datenorganisationen führen dadurch auch zu logischen Fehlern und einer fehlerhaften
Verzeichnisstruktur in der Virtual Machine (VM). Die VM verweist auf fehlende Speicheradressen, die
der Controller der RAID-Einheit gar nicht mehr adressiert. Dateien werden so regelrecht
abgeschnitten. Neben dem Verlust des Verzeichnisses als Extremfall sind alle Spielarten denkbar,
die dazu führen, dass Einträge nicht mehr korrekt sind. So können Verzeichnisse von einer falschen
Dateigröße ausgehen. Dann werden die Folgebereiche nicht mehr richtig eingelesen, und die Datei
erscheint der VM als korrumpiert.
Der Controller ist das Herzstück der Datenverwaltung. In einem Fall war ein RAID-5-Array mit
fünf Festplatten an einen VMware ESX Server mit einer Datenmenge von 1,2 TByte angeschlossen. Auf
dem Array waren vier Windows-2003-Server-VMs gespeichert, MS SQL 2005 speicherte medizinischen
Unterlagen von Patienten. Als der Controller ausfiel, wurde dieser von einem internen Techniker
ersetzt. Auch nach dem Reboot blieben alle Platten offline. Die IT stand nun vor einem Dilemma. Ein
erzwungenes Online-Stellen der Platten und Rebuild garantierten keinen Erfolg.
Der IT-Administrator erstellte gewissenhaft zuerst 1:1-Kopien auf gleich große Festplatten. Dann
schaltete er die 1:1-Kopien online. Zutage kam eine beschädigte RAID-Konfiguration. Die Lösung war
letztlich, den Controller durch eigens von Datenrettungsexperten entwickelte Software zu ersetzen.
So können dann die Data Stripes gemappt werden, um die Original-RAID-Konfiguration zu bestimmen und
per Software den RAID-Controller zu simulieren. Dieses virtuelle RAID-Manager-Layer fungierte für
den Verlauf des Recovery-Prozesses wie die Original-LUN.
Vorbeugen besser als Heilen
Gleich wie solide ein RAID und wie der Unterbau einer virtuellen Umgebung ist – Datenverlust
lässt sich nicht ausschließen. Klassische Risiken wie Hardwareausfall, Fehlbedienungen oder höhere
Gewalt bleiben. Wichtig ist, im Ernstfall richtig zu handeln. Einige wenige Regeln helfen schon in
den meisten Fällen weiter: Ausfälle von Festplatten sollte man ernst nehmen und schnell beheben. Im
Zweifelsfall sollte man Selbstreparaturen unterlassen und Experten befragen.
Administratoren können aber auch vorsorgen: Eine stets aktuelle gewissenhafte Dokumentation ist
oft schon die halbe Datenrettungsmiete. Wenn im Ernstfall aufgrund dieser Basis der enge Austausch
mit Experten möglich ist, stehen die Erfolgsaussichten gut. Aber auch in virtuellen Umgebungen
bleiben Backups die Mutter der Datensicherheit.
Lesen Sie mehr zum Thema
