Die „Schlankheitskur“ kann böse Folgen haben – dann hilft nur

Echte Datenrettung im virtuellen Raum

Seite: 2/2

Firma zum Thema

Die virtuelle Speicherlandschaft

Wo können hier überall Datenverluste passieren? Die Antwort ist einfach: überall. Rein quantitativ stellen 96 Festplatten eine enorme Fehlerquelle zum Beispiel durch physikalischen Ausfall eines Datenträgers oder durch korrupte Sektoren einer Festplatte dar. Aber die Parity-Daten in einem RAID sollten hier eine gewisse Sicherheit geben.

Hier müsste angesichts der Parity-Codes schon viel Unglück zusammenkommen. Selbst der Ausfall der Festplatte mit dem Controller würde noch nicht genügen, da RAID6 den Verlust von zwei logischen Einheiten aushält. Aber auch rein arithmetisch steigt das quantitative Ausfallrisiko, wenn mehr potenzielle Ausfallkandidaten im Spiel sind.

Organisationsprobleme

Gefährlicher als die Kettenreaktionen von unten durch den Ausfall von Festplatten sind Organisationsfehler oder Organisationsänderungen auf höherer Ebene. Wichtig ist, dass selbst hochverschachtelte virtuelle Speicherverwaltungen letztlich auf den korrekten Einträgen von Speicheradressen in zentralen Verzeichnissen beruhen. Die Speicheradressen definieren bitgenau die einzelnen Sektoren auf physikalischen Datenträgern. Die Verzeichnisse verweisen auf die Adresse.

Wenn die Verzeichnisstruktur fehlerhaft ist, fragt der Controller der RAID-Einheit zum Beispiel Speicheradressen ab, auf denen sich die Daten gar nicht befinden. Oder er fragt nicht alle Speicherorte ab. Oder in der falschen Reihenfolge. Egal, was geschieht, die Daten erscheinen als korrupt und können deswegen nicht abgerufen werden.

Das größte Risiko ergibt sich konsequent weitergedacht also auf der Ebene der Virtual Machine oder der zentralen Appliance, die die Gesamtheit der 96 Terabyte Speicherplatz automatisch verwaltet und dabei die Landkarte der Speicherlandschaft zeichnet. Solange die Verwaltung automatisch abläuft, passiert noch nichts.

Probleme tauchen aber unter Umständen dann auf, wenn die Speicherressourcen neu aufzuteilen sind. In einem Beispiel weist die Machine den umfangreichen Finanzdaten 32 TB Datenplatz zu. Nach einer erfolgten Deduplizierung denkt man nun, mit einem Volumen von 24 TB auszukommen. Ist aber nun in Wirklichkeit das Datenaufkommen doch 28 Terabyte, fragt die Appliance nun 4 Terabyte zu wenig ab. Daten werden korrupt, weil die Datensätze nicht vollständig vorliegen.

In der Virtual Machine befindet sich also mit dem Verzeichnis der Speicherorte das Drehbuch für die Speicherabfrage. Der ultimative Daten-Gau ist ein Verlust dieser Verzeichnisdaten auf der Virtual Machine. Dann gilt es, dieses Drehbuch wieder herzustellen, wenn man die Speicherlandkarte von 96 Terabyte Daten nachzeichnen will.

Deduplizieren – eine Schlankheitskur mit Folgen

Doch neben den Problemen der Datenorganisation führt die Optimierung des Speicherplatzes, die oft mit der Virtualisierung einhergeht, zu neuen Verlustrisiken. Virtualisierung wird häufig auch für eine Entschlackung des Datenvolumens verwendet. Komprimierung und Deduplizierung können aber ebenfalls zu Datenverlust führen.

Werden nämlich Daten wieder dekomprimiert, kann es zu Fehlern beim Auslesen kommen. Datenretter wissen aber, wo die Änderungen der Daten verzeichnet sind und können so im Notfall die Informationen wieder rekonstruieren.

Beim Deduplizieren werden doppelt abgespeicherte Dateien ausgefiltert. In mehreren Verzeichnissen wird mit Pointern auf den neuen Datenort verwiesen. Diese Verbindung kann auf zwei Arten zerstört werden. Entweder der Verweis ist gelöscht und die Daten werden nicht gefunden. Oder die Daten selber sind nicht mehr vorhanden. In beiden Fällen kann Datenrettung helfen.

Nächste Seite: Wenn der Administrator Strukturen dokumentiert, klappt‘s mit der Rettung

(ID:2047364)