Datenrettung bei Speichersystemen:
RAID-Systeme: Fehler in Physik und Logik killen Daten

von Bernd Reder (bernd.reder@networkcomputing.de), Edmund Hilt

Share
28.07.2008

Moderne Speichersysteme sind relativ sicher. Kommt es trotzdem zu Ausfällen, ist oft professionelle Hilfe erforderlich. Der Beitrag führt die gefährlichsten Fehler bei RAID-Laufwerken auf und zeigt, welche Auswirkungen sie haben können.

RAID-Systeme werden für immer mehr Anwender interessant. Selbst bei kleineren Unternehmen wachsen die Datenmengen rapide.

Doch offenbar verspricht der Verbund ein Zuviel an Sicherheit. Datenrettungsspezialisten sehen Fälle, in denen man sich blind auf virtuelle RAID-Verbunde verlassen hat und ein Backup zwei Jahre lang lediglich geplant war. Als es dann doch zum Ausfall kam, wurde durch unsachgemäße Reparaturversuche der Storage-Gau perfekt.


RAID-Vielfalt


Die Vielzahl der möglichen RAID-Konfigurationen ist größer als man denkt. RAID ist nicht nur auf Platten oder Bänder beschränkt, sondern kann auch mit Flash-Speichern aufgebaut werden. Wie, wird die Zukunft zeigen.

Wikipedia listet aktuell zehn verschiedene RAID-Arten und 22 Kombinationen auf. Hohe Performance durch Striping (RAID 0), höchste Sicherheit und Redundanz durch Mirroring (RAID 1) sowie die Möglichkeit, durch die Berechnung von Kontrollparities die Datensicherheit zu erhöhen (RAID 5 und RAID 6), sind unterschiedliche Vorteile.

RAID 6

Gesunkene Festplattenpreise degradieren den Hardwarekostenfaktor zur Fußnote und haben RAID 6 zum Standard gemacht. RAID 6 erhöht die Datensicherheit gegenüber RAID 5 durch eine zweite Berechnung von Parity-Codes, die bei Ausfall einer Platte mit Hilfe der anderen Platten die Daten über Parity-Bits berechnen können.

Bei RAID-6 können zwei von vier Platten ausfallen, bei RAID 5 nur eine von dreien. Bei virtuellen RAIDs wird das Mosaik noch viel bunter, da hier verschiedenste Spielarten parallel betrieben werden können.

Allen Parities zum Trotz kann oft auch im RAID auf Daten nicht mehr zugegriffen werden. Die Gründe sind so verschieden, dass niemand sie ausschließen kann. Hardware- und Softwarefehler, aber auch Fehlbedienungen sind die häufigsten Ursachen. Generell kommt es entweder zum physikalischen Defekt von Datenträgern oder zu logischen Fehlern in der Verzeichnisstruktur.

Wenn die Physik nicht mitspielt

Physikalische Fehler sind vielfältig: Entweder sind einzelne Bereiche oder Schreib-/Leseköpfe defekt oder der Controller versagt zum Beispiel durch Überhitzung.

Der Tausch von Ersatzteilen reicht oft nicht aus. Ersatz-Controller sprechen oft aus nicht nachvollziehbaren Gründen die Festplatten nicht an. Mechanische Ausfälle sind deswegen so gefährlich, weil sie selten allein auftreten.

Der erste verschleißbedingte Ausfall wird in RAID 6 von vielen Administratoren häufig fahrlässig hingenommen. Erst wenn eine weitere Platte ausscheidet, sind die Daten nicht mehr verfügbar. Dieser Fall ist aber gar nicht so selten, denn oft stammen die Platten aus einer Produktionscharge und ihre »Mean Time Between Failures« läuft gemeinsam ab.

Fehler in der Logik

Auch logische Fehler in der Verzeichnisstruktur sind zahlreich und oft noch schwieriger zu beheben. Vor allem die großen SANs und RAIDs beruhen wie jede Festplatte auf einem zentralen Verzeichnis der Dateien, welches genau die Speicherorte zuteilt. Neben dem Verlust des Verzeichnisses als Extremfall sind hier alle Spielarten denkbar, die dazu führen, dass Einträge nicht mehr korrekt sind.

So können Verzeichnisse von einer falschen Dateigröße ausgehen. Ist sie zu klein angegeben, liest der Controller die Folgebereiche nicht mehr richtig weiter ein und die Datei wird in seinen Augen korrupt.

Das ist häufig bei dynamischer Speicherverwaltung in virtuellen RAIDs der Fall, wenn ein RAID-Segment im Fehlerfall automatisch verkleinert wird und dadurch von ihm noch belegte Bereiche aus seinem Verfügungsbereich eigentlich konsequent heraus fallen. Dateien werden regelrecht abgeschnitten, obwohl sie physikalisch durch die elektromagnetische Polung der einzelnen Sektoren noch einwandfrei vorhanden sind. Ebenso können sich Korruptionen daraus ergeben, dass die einzelnen Fragmente einer Datei in der falschen Reihenfolge abgefragt werden.

Die Ursachen falscher oder fehlender Einträge sind unterschiedlich. Physikalische Ausfälle in RAID-Verbunden ziehen häufig eine logische Beschädigung nach sich. Banale Bedienungsfehler können eine weitere Ursache sein: Wer beim Austausch einzelner Festplatten diese eventuell auch vertauscht, kann böse Überraschungen erleben.

RAID 6 ist hier besonders sensibel, weil die neu einzusetzenden Festplatten bei der Einrichtung exakt wie die alten bezeichnet und implementiert werden müssen.

Datenrettung mit Bordmitteln hilft nur begrenzt

Manchmal lassen sich mit RAID-Bordmitteln logische Fehler beheben, aber hier ist äußerste Vorsicht geboten. Jedes System bringt Rebuild-Optionen mit. Der Rebuild berechnet fehlende Fragmente einer ausgefallenen Festplatte aus bestehenden Dateien und Parities der noch verbliebenen Datenträger und schreibt diese automatisch auf die neu eingesetzte Festplatte.

Bei manchen Systemen bringt sich diese Rebuild-Funktion auch automatisch von selbst ins Spiel, wenn beispielsweise die Hotspare-Option eingeschaltet ist. Der Administrator wird dadurch erst einmal in Sicherheit gewogen. Anschließende Austauschaktionen oder zusätzliche Backups finden kaum zeitnah statt. Wenn dann rasch weitere Festplatten ausfallen, dann ist ein Rebuild nicht mehr möglich.

Auch andere Bordmittel sind mit Vorsicht zu genießen, so etwa der Einsatz von »CHKDSK« in NTFS-Umgebungen. Wenn tiefer gehende Probleme vorliegen, kann »CHKDSK« wichtige Datenstrukturen löschen.

Bei einem RAID mit neun Platten traf es beispielsweise die Master-File-Table mit ihren File-Record-Tabellen, die die einzelnen Speicherorte zentral bezeichnet. Das Zusammentragen der vorhandenen File-Records beim Einzelscan aller Sektoren hatte weitere Tücken.

Es wurden auch ältere File-Records wiederhergestellt, die das Bordtool Shadow-Copy angelegt hatte. Sie führten nun ins Leere und hätten beim Nachgehen durch die Experten automatisch einen neuen und zeitraubenden »CHKDSK« veranlasst.

Das Team musste daher ein kundenspezifisches Toolset entwickeln, das nur die aktuellen Verweise auf die Speicherorte der Kundendaten berücksichtigte. Bei einem Volumen von 1 TByte mussten die Tools bereits nach dem Scan der Hälfte des Volumens über 19 Millionen File-Records bewerten. Ohne die Filterung hätte man alle Dateien und Verzeichnisse einzeln herauskopieren müssen. So aber ließ sich eine Verzeichnisstruktur vollständig rekonstruieren und die Daten konnten wieder gefunden werden.

Bordmittel zum richtigen Zeitpunkt einsetzen

Nicht weniger problematisch ist es, wenn Bordmittel zum falschen Zeitpunkt eingesetzt werden. Häufiger als vermutet wird bei Zugriffsproblemen das RAID einfach neu initialisiert, anstatt einen Rebuild durchzuführen. Dann wird nichts wieder aufgebaut, sondern lediglich neue Parities für ein bestehendes, nun aber korruptes System ausgerechnet. Dann kann kein korrektes Ergebnis mehr heraus kommen.


Virtuelle Logiken

Die Virtualisierung, die sich im Server-Bereich immer weiter durchsetzt, macht diese Grundsatzprobleme immer komplexer. Wenn im schlimmsten Fall der zentrale Controller der Virtual-Machine aussetzt, beginnt unter Umständen eine umfassende Jagd auf Tables, Blocks und Parities, denn ein Scan der einzelnen Sektoren hätte wohl enorme Dimensionen.

Fatal wird es, wenn wieder die »Physik« in Form höherer Gewalt durchschlägt und die Logik aushebelt. Im virtuellen RAID 5 einer hochrangigen Behörde mit 80 Festplatten mit jeweils 320 GByte fielen nach einem Wasserschaden im Serverraum 24 Platten aus.

Ein unsachgemäßer Ausbau der Daten machte es Kunden wie Herstellern der Backup-Lösung endgültig unmöglich, die Informationen zu retten. Allein schon der prinzipielle Aufbau des Systems illustriert die Probleme, die Dateiorte wieder korrekt zu lokalisieren.

Physikalische und Virtualisierungsebene

Rein physikalisch bestand das System aus 80 Festplatten. Die Gesamtheit der Platten war in zehn RAID-5-Verbunden organisiert. In der zweiten Ebene, der Virtualisierungsebene, wurden die Daten noch einmal umorganisiert.

Ein Drittel des Speicherbereichs wurde als erste logische Einheit (LUN) in RAID 1 gespiegelt, eine zweite LUN aus Gründen des schnellen Zugriffs mit RAID 0 »gestriped« und eine dritte LUN mit RAID 5 eingerichtet. Der Controller für das ganze virtuelle System teilte in einer zentralen Liste alle Bereiche den einzelnen LUNs zu und verteilte die logischen Einheiten physisch über alle 80 Platten.

Jede LUN für sich hat nun ihren Bereich zu verwalten und ebenso geschieht dies bei den zehn einzelnen RAID-5-Verbunden. Zusätzlich unübersichtlich wird dies in der Virtualisierung, weil hier nicht eine homogene MFT die Datenorganisation übernimmt, sondern zum Beispiel ein ESX-Server von Vmware virtuell verschiedene Dateisysteme synchron laufen lässt.

Um ein Verständnis für die Dimensionen zu erhalten: Allein das zentrale Verzeichnis des Controllers wurde aus Sicherheitsgründen auf Teilbereichen von vier einzelnen Festplatten gespeichert. Veränderungen im Aufbau und Zuordnung des Systems wurden hier immer neu angelegt und vermerkt.

Letzte Rettung: Suche nach Dateisignaturen

Wenn man diese Zuordnung nicht kennt, erscheint das Puzzle schier unlösbar. Bei anderen virtuellen SAN-Systemen wäre das ganze noch aufwändiger gewesen, da die Daten hier direkt nacheinander aneinander gereiht werden, egal an welche Stelle im Dateisystem diese gehören.

Jede Änderung wird hier erst im Bedarfsfall durch einen eigenen Eintrag dokumentiert, welcher auf den realen Speicherort verweist. Bei Verlust der aktuellen, zuletzt angelegten Tabelle bleibt dann nur noch der Scan nach einzelnen Signaturmustern: Jede Datei hat einen typischen Aufbau. Bilder eines Computertomographie-Systems oder spezifische Kundeneinträge lassen sich anhand dieses Musters durchaus noch erkennen.

Wie sich ein logischer Fehler hier auswirken kann, kann man sich ausmalen. Die Suche nach einschlägigen Verzeichnissen, bestehenden Redundanzen und das Nachrechnen von Paritäten und der automatisierte Signaturscan einzelner Sektoren ermöglichen es aber, Daten wieder herzustellen.

Im Fall der Behörde war der Aufwand der Datenrettung beachtlich, was aber angesichts des enormen Wertes der Daten sicher zu rechtfertigen war. Nur durch die erfolgreiche Wiederherstellung der Informationen war die Behörde überhaupt in der Lage, ihre Arbeit weiterzuführen.

Datenrettung in den meisten Fällen möglich

Hardwareausfälle und Bedienungsfehler bleiben – wie die Beispiele belegen – Hauptursache für vermeintlichen Datenverlust. Doch Rettung ist meistens möglich. Aufwändig wird es dann, wenn nicht adäquate Mittel die logische Zerstörung der Datenstrukturen fortführen. Lediglich die vollständige Überschreibung von Daten und Partitionierung oder ein Low-Level-Format kann aber Daten wirklich vernichten.

Wenn es im RAID-Verbund zu Ausfällen kommt, ist es für eine Rettung daher nicht zu spät, wenn man schnell professionelle Hilfe anfordert. Immer wichtiger aber wird im Vorfeld eine gewissenhafte und übersichtliche Datenorganisation. Ordentliche dokumentierte Strukturen und Protokolle beschleunigen gerade in virtuellen RAIDs die Datenrettung immens. Eine beruhigende Botschaft, die vor Kurzschlussaktionen schützen sollte.

Edmund Hilt ist Managing Director bei dem Datenrettungsspezialisten Kroll Ontrack [1].

[1] http://www.ontrack.de