Reale Rettung im virtuellen Raum - Datenrettung und Virtualisierung

Virtualisierung bietet große Chancen. Flexibilität und Hardwareunabhängigkeit sind nicht zu bestreiten. Eine datenverlustfreie Speicherutopie entsteht dabei aber nicht. Ohne Zweifel bietet die Technologie große Chancen. Doch auch hier werden Daten von Menschen auf Festplatten oder Bändern gespeichert. Die hohe Flexibilität und die Schnelligkeit, die per Mausklick Entscheidungen von großer Tragweite in den Speicherverwaltungen hervorruft, schaffen neue Risiken. 2009 stieg die Zahl der Datenrettungs-Anfragen in virtualisierten Umgebungen bei Kroll Ontrack gegenüber dem Vorjahr um 58 Prozent. Über zwei Drittel davon waren Folgen von Anwenderfehlern. Häufigste Ursache sind dabei Fehlbedienungen. Bei traditionellen Systemen liegt der Anteil menschlichen Fehlverhaltens nur bei 26 Prozent gegenüber 74 Prozent technischem Versagen.

Das zeigt, wie komplex es ist, virtuelle Umgebungen zu implementieren, zu managen oder zu migrieren. Bei virtualisierten Umgebungen liegen immer mehr kritische Informationen zentralisiert auf einem System. So ist der mögliche Schaden durch Datenverluste viel größer. Aber eine Datenrettung ist auch hier meistens noch möglich. Denn wie in der herkömmlich digitalen Welt gilt auch in der virtuellen Umgebung: Erst nach Veränderung der Informationen in den Festplattensektoren sind Daten wirklich unwiederbringlich verloren.

Szenarien eines Datenverlusts in virtuellen Umgebungen

Die Ursachen der Datenverluste sind ebenso unterschiedlich wie bei herkömmlichen Systemen. Prinzipiell gilt, dass auch in der virtuellen Welt Informationen letzten Endes immer auf einer Festplatte oder einem Tape gespeichert werden. Hardwareunabhängigkeit bedeutet nicht, dass das Risiko des Datenverlustes durch Hardwareverlust ausgeschlossen ist. Auch neue Technologien nützen nichts, wenn - wie in der Praxis vorgekommen - ein Wassereinbruch den überwiegenden Teil der Festplatten eines virtuellen Verbundes flutet und kein Backup vorliegt.

Viel entscheidender sind aber die Fehler durch Fehlbedienung bzw. mangelhaftes Training. Hierbei handelt es sich nicht um fahrlässige und/oder überforderte Administratoren, sondern um Gefahren, die eine komplexe Technologie in sich trägt, wenn schnell und unter Zeitdruck Entscheidungen getroffen werden müssen. Bei Systemen des Virtualisierungsspezialisten VMware – als Beispiel- verteilen sich die Ursachen wie folgt:

  • Hardware-/RAID-Probleme: 36 Prozent
  • VMFS-Korruption: 20 Prozent
  • gelöschte virtuelle Festplatten und/oder Snapshots: 18 Prozent
  • VMFS-Re-Installation: 17 Prozent
  • interne Korruption der virtuellen Festplatte: 9 Prozent.

Szenario 1 – Fehler im RAID

Ausfälle im RAID-System können verschiedene Ursachen haben. In einem Fall wurde aus Versehen eine intakte Festplatte aus dem virtuellen RAID-Bereich entfernt, der alle wichtigen SQL-Server in einem Krankenhaus hostete. Durch eine Reihe von Reparatur-Versuchen wie RAID Rebuilds oder auch einer RAID Initialisierung bei gleichzeitigem Check Disk der Partition wurden nun die Data Stripes des RAID-Arrays weiter beschädigt. Der Fall stellte sich sehr kompliziert dar, da nicht nur Datenstrukturen zum Beispiel im VMFS (Virtual Machine File System)-Datensystem, sondern auch in SQL und sogar in NTFS betroffen waren. Wesentlich war in diesem Fall die Wiederherstellung der Konfiguration der originären RAID-Konstellation. Bei Kroll Ontrack konnte dies durch eine Software-Simulation ohne den ursprünglichen Hardware Raid Controller erreicht werden, bei der die DataStripes in der richtigen Reihenfolge über alle Festplatten neu angeordnet wurden. Die Experten von Kroll Ontrack verfügen auch über spezifische Tools zur Reparatur beschädigter VMFS-Dateisysteme und zur Kopie der VMDK (Virtual Machine Disk)-Files. NTFS Datenrettungs-Tools reparierten das NT-Datensystem und kopierten die SQL-Informationen, die dann in eine neue Datenbank überspielt wurden. Angesichts dieser aufwändigen Datenrettungsvorgänge ist es hierbei zwingend nötig, zuerst eine Sicherung des Status Quo mitsamt aller Beschädigungen der Datenstruktur vorzunehmen. Dann können anhand der Kopie über einen speziellen Recovery Layer alle Rettungsarbeiten vorgenommen, dokumentiert und - sofern nötig - auch wieder zurückgenommen werden.

Szenario 2: Gelöschte virtuelle Maschinen

Nicht selten kommt es vor, dass eine virtuelle Disk aus Versehen gelöscht wird. In einem Fall traf es dabei die Disk mit zwei virtuellen SQL-Datenbanken. Ein Backup war nicht vorhanden. Gelöschte Daten in VMFS sind eine besondere Herausforderung. Hier werden nämlich alle Verweise auf die Daten entfernt. Zum Glück werden die Home-Verzeichnisse der VMDK Meta Daten als zentrale Register nicht endgültig gelöscht - wie auch die eigentlichen Datei-Inhalte der besonders wichtigen Datei mit dem virtualisierten Dateisystem und den eigentlich gesuchten realen Daten. Datenrettungsingenieure können hier dann nach den noch auffindbaren VMDK Dateien suchen. Einen kleinen Hinweis haben die Ingenieure bei ihrer Arbeit – vorausgesetzt man beginnt sofort mit der Datenrettung: Datenretter müssen lediglich die freien und damit vermeintlich leeren Sektoren durchsuchen. Mit Hilfe von VMFS Recovery Tools können die Ingenieure den Suchbereich auf den unallocated space des Volumes eingrenzen, um die gelöschte virtuelle Maschine zu finden. Aufwändig wird dies, weil VMDK-Files meist fragmentiert sind und alle Einzelteile mühsam wieder zum Ganzen zusammengesetzt werden müssen. Die Suche ist auch mit automatisierten Tools langwierig, da VMFS-Daten oft eine Dimension von über einer Milliarde Sektoren à 512 Byte erreichen. Danach können aber die alten VMDKs in einem neuen VMDK-File wieder zusammengesetzt werden.

Szenario 3: Formatierung und Re-Installation eines Volumes

Die versehentliche Neuformatierung eines Volumens virtueller Maschinen kann schwerwiegende Folgen haben. Insbesondere dann, wenn der Fehler nicht sofort bemerkt und eine Weile in einem so falsch neuformatierten System gearbeitet wird. In einem Fall wurde ein aktives VMFS LUN versehentlich einem Windows 2003 Physical Server zugänglich gemacht und unter diesem als Datenplatte verwendet. In NTFS wurden dadurch Datensätze neu geschrieben und damit die alten VMFS-Daten überschrieben. Nun ist schnelle Hilfe notwendig. Auch hier werden dann zuerst die neu beschriebenen NTFS-Daten ausgeblendet und im zweiten Schritt nur die noch nicht überschriebenen und nicht mehr sichtbaren VDMK-Strukturen gesucht. So lassen sich mit der rekonstruierten VMDK die Files wieder finden und auslesen – sofern sie nicht schon überschrieben sind.

Szenario 4: Quick initialised VMFS LUNs

Ebenso gefährlich kann es sein, ein VMFS LUN an einem Windows Backup Server zu betreiben und dabei die LUN nicht zu verstecken. Im Festplattenmanager kann man durch „quick initialising“ auf dem Backup Server mit einem Mausklick alle darunter liegenden Strukturen von VMFS für die ESX Server unsichtbar machen. In einem Fall hatte ein Kunde ein SAN SYSTEM mit 10 ESX Production Servern und 20 VMFS LUNs mit je einer Größe von 500 GB sowie einen Windows 2003 Server. Dieser diente in diesem System als Backup Server, die 20 LUNs wurden dort im Direct Access Mode gemappt.

Das ganze System beherbergte über 200 virtuelle Maschinen in einer unbekannten Zahl von VMDKs. Im konkreten Fall wurde am Windows Backup Server eine neue Datenfestplatte eingebaut. Beim anschließenden Formatieren musste zunächst ein “Quick Initialize“ durchgeführt werden. Dabei waren nicht nur die eine neue Festplatte, sondern auch noch die 20 ESX Volumes ausgewählt und mit dem Bestätigen auch sofort strukturell beschädigt! Die virtuellen Maschinen und der ESX Server waren noch ansprechbar. Das Risiko, nach einem nun nötigen Reboot aber auch diese Daten endgültig zu verlieren, war groß, die VMFS Volumes jedes ESX Servers wären nie wieder erkannt worden. Die ursprünglich vom Kunden avisierte Lösung, einen neuen ESX Server aufzusetzen und die Daten aller virtueller Maschinen und VMDKs auf neue LUNs zu überspielen, war zu aufwändig. Wesentlich eleganter war es hingegen, im laufenden Betrieb alle VMFS LUNs mit modernen Datenrettungstechnologien reparieren zu lassen. Das bedeutet in diesem Fall die manuelle Rekonstruktion der gelöschten und zudem beschädigten VMFS Frontend Strukturen von 20 LUNs. Alle Daten konnten innerhalb von 24 Stunden gerettet werden. Gearbeitet wurde dabei über eine geschützte Internet-Verbindung mit der Remote Recovery von Kroll Ontrack, ohne das Festplatten und Systeme ausgebaut werden mussten.

Fazit

Die Beispiele zeigen, dass Datenverlust in virtuellen Umgebungen schnell eintritt. Virtualisierung ist eine komplexe Technologie und Fehlbedienungen können durch die zentrale Verwaltung großer, auf engem Raum komprimierter Speicherlandschaften zu enormen Verlusten führen. Auch wenn Virtualisierung mittlerweile weit verbreitet ist, lassen sich Fehler nicht ganz vermeiden. Bei einer so jungen Technologie, die von manchen als Quantensprung in der IT bezeichnet wird, ist das auch nicht verwunderlich. Administratoren können neben Schulungen und Sorgfalt zusätzlich im Vorfeld einiges tun, um auch einen möglichen Datenverlustfall einzugrenzen. Wer seine Strukturen gut dokumentiert und mit Bedacht virtuelle Speicherlandschaften anlegt, minimiert sein Risiko und kann im Ernstfall durch Rückgriff auf die Dokumentation die Wiederherstellung wesentlich vereinfachen oder auch erst ermöglichen. Zudem sollte man immer auch mit Weitblick in die Virtualisierung gehen. Die Infrastrukturen müssen Flexibilität, hohe Verfügbarkeit, Performance und Datensicherheit miteinander verbinden. Die Virtualisierungstechnologien bleiben eine verlockende und hervorragende Alternative. Mit guter Planung auch ohne Weiteres sicher.

Holger Engelland, Manager Data Recovery Engineering, Kroll Ontrack GmbH