Datenrettung virtuelle Systeme: VMware, Hyper-V, Proxmox und KVM

Erste Schritte bei Datenverlust in einer virtuellen Umgebung

Diese Maßnahmen verbessern die Ausgangslage für eine spätere Datenrettung und kosten wenig Zeit. Sie ergänzen unsere allgemeinen Erste-Hilfe-Maßnahmen bei Datenverlust:

1. Betroffene VMs herunterfahren und den Host aus der Produktion nehmen. Jeder weitere Schreibzugriff auf den Datenspeicher kann Bereiche überschreiben, die für die Rekonstruktion gebraucht werden.
2. Konfigurationsdateien und Protokolle auf ein separates Medium sichern, etwa die VMX-Datei, die libvirt-XML oder die Prüfpunktdateien. Sie enthalten Angaben zu Reihenfolge und Zuordnung der Abbilder.
3. Den Zustand dokumentieren: RAID-Level und Reihenfolge der Laufwerke, letzte Änderung an der Infrastruktur, erste Fehlermeldung und deren Zeitpunkt. Diese Angaben verkürzen die Diagnose spürbar.
4. Vorhandene Backups prüfen, aber nicht auf das Original zurückspielen. Eine Rücksicherung überschreibt genau den Datenspeicher, aus dem noch gerettet werden soll. Sinnvoll ist ein Rückspielen ausschließlich auf ein anderes Ziel.
5. Bei einem degradierten Array keinen zweiten Rebuild starten. Ein abgebrochener Rebuild lässt sich in der Regel nicht durch einen weiteren beheben.
6. Keine Recovery-Software auf dem Originalspeicher ausführen. Programme dieser Art arbeiten auf Ebene einzelner Laufwerke und bilden weder den Verbund noch die Ebenen darüber ab.

Ablauf der VM-Datenrettung

Der Ablauf folgt immer derselben Reihenfolge, von der Hardware bis zur einzelnen Datei im Gastsystem:

1. Diagnose jedes physischen Datenträgers. Wir prüfen Lesbarkeit und Zustand jeder Platte und jeder SSD einzeln. Mechanisch oder elektronisch beschädigte Laufwerke setzen unsere Spezialisten im Reinraumlabor instand und tauschen Leseköpfe oder Elektronik gegen Ersatzteile desselben Modells. Was dabei je Laufwerkstyp zu beachten ist, steht auf den Seiten zur Festplatten-Datenrettung und zur SSD-Datenrettung.
2. Sektorgenaue, schreibgeschützte Abbilder aller Laufwerke oder der bereitgestellten LUN. Jeder weitere Arbeitsschritt läuft ausschließlich auf diesen Kopien, das Original bleibt unverändert.
3. Den Verbund rechnerisch schließen. Level, Reihenfolge, Blockgröße, Offsets und Parität bestimmen wir aus den Metadaten, auch ohne den ursprünglichen Controller und ohne das Original-Gerät.
4. Die Datastore-Ebene auswerten: VMFS, LVM und Thin-Pools, ZFS, NTFS oder ReFS. Fehlende oder überschriebene Metadaten werden anhand ihrer Strukturen rekonstruiert.
5. Containerdateien zusammensetzen. VMDK, VHDX, QCOW2 und VDI werden mitsamt ihren Delta-Ketten in der richtigen Reihenfolge verbunden, fehlende Deskriptoren erzeugen wir neu.
6. Gastdateisystem öffnen und Daten extrahieren. Ob Windows- oder Linux-Gastsystem: Auf Wunsch liefern wir einzelne Dateien und Ordner, konsistente SQL-Datenbanken oder eine wieder startfähige virtuelle Maschine.

Vor der Übergabe erhalten Sie eine Liste der wiederhergestellten Dateien und Ordner und prüfen daran, ob die erforderlichen Daten vollständig sind. Übergeben wird auf einem neuen Datenträger, den wir bereitstellen. Den gesamten Prozess von der Anfrage bis zur Rückgabe beschreibt unsere Seite zum Ablauf der Datenrettung. Gehen ausgemusterte Datenträger danach aus dem Betrieb, übernimmt das unsere Datenlöschung nach DIN 66399, auf Wunsch mit Löschzertifikat.

Kosten und Preise der VM-Datenrettung

Die Preise entsprechen unserer regulären Staffelung für Speichersysteme: Standard-Datenrettung ab 449 €, Express-Bearbeitung rund um die Uhr zum individuellen Festpreis. Verbindlich wird der Preis nach der Diagnose, vor der Beauftragung und ohne Überraschungen danach.

Den Aufwand bestimmen im Wesentlichen fünf Punkte:

• Anzahl der Laufwerke, da jedes einzeln diagnostiziert und geklont wird
• Art des Schadens, denn rein logische Fälle sind weniger aufwendig als eine mechanische oder elektronische Beschädigung
• Umfang der nötigen Reinraumarbeit, etwa beim Austausch von Leseköpfen
• Komplexität der Umgebung, von einer einzelnen VM auf einer Spiegelung bis zum verschachtelten Verbund mit langen Delta-Ketten
• Dringlichkeit, denn im Notfall läuft die Express-Bearbeitung rund um die Uhr und wird priorisiert eingeplant

Eine pauschale Erfolgsquote lässt sich für virtuelle Umgebungen nicht seriös angeben. Aus über 20 Jahren Erfahrung mit ausgefallenen Serversystemen lässt sich aber sagen, was das Ergebnis verschiebt: ein vollständiger Satz Laufwerke, ein seit dem Ausfall unveränderter Zustand und der Verzicht auf eigene Rettungsversuche wirken sich durchweg günstig aus. Eine Übersicht aller Leistungen finden Sie in unserer Preisübersicht.

Virtualisierungslösungen, die wir bearbeiten

Als Datenrettungsdienst mit eigenem Reinraumlabor arbeiten wir herstellerunabhängig; entscheidend für die Rekonstruktion ist nicht das Produkt, sondern die Struktur darunter. Diese Plattformen und Virtualisierungstechnologien erreichen uns am häufigsten:

Weitere Virtualisierungssoftware wie oVirt, Red Hat Virtualization oder Nutanix AHV bearbeiten wir ebenso. Liegen die virtuellen Maschinen auf einem Netzwerkspeicher, kommt die Auswertung des Geräts selbst hinzu: dazu führen die Seiten zur NAS- und SAN-Datenrettung sowie zu den Systemen von Synology, QNAP und Buffalo weiter.

Struktur der Daten in virtuellen Umgebungen

Ein Hypervisor bündelt viele Systeme auf einem gemeinsamen Speicher und verteilt dessen Ressourcen an die einzelnen Gäste. Genau das macht den Unterschied im Schadensfall: Ein Ausfall trifft selten eine einzelne Maschine, sondern alle VMs, die auf demselben Datastore liegen. Zwischen dem physischen Laufwerk und der Datei, die ein Anwender vermisst, liegen dabei deutlich mehr Verwaltungsebenen als bei einem klassischen Server.

Für die Praxis folgt daraus zweierlei:

• Die Reihenfolge liegt fest. Jede Ebene wird von unten nach oben zusammengesetzt. Eine intakte Containerdatei nützt wenig, solange der Verbund darunter nicht rechnerisch geschlossen ist.
• Recovery-Tools sehen immer nur eine Ebene. Sie erkennen ein einzelnes Laufwerk oder ein einzelnes Dateisystem, aber weder den RAID-Verbund noch den VMFS-Datastore noch eine unterbrochene Delta-Kette.

Innerhalb der virtuellen Festplatte liegt anschließend das Dateisystem des Gastbetriebssystems, je nach VM etwa NTFS und ReFS, ext4, XFS oder UFS. Wie ein Verbund die Daten über mehrere Laufwerke verteilt, beschreibt unsere Seite zur RAID-Datenrettung im Detail.

Typische Schadensbilder in virtualisierten Umgebungen

Die Symptome ähneln sich über alle Hypervisor hinweg. Ein Symptom allein lässt allerdings noch keinen sicheren Schluss auf die Ursache zu; erst die Diagnose zeigt, auf welcher Ebene der Fehler tatsächlich sitzt.

Als Ursachen sehen wir im Labor regelmäßig dieselben Muster: defekte Festplatten und SSDs im Verbund, Überspannung und Stromausfall, Fehler bei Migration und Implementierung, versehentlich gelöschte oder formatierte Volumes, ausgefallene Controller sowie Schadsoftware. Wie sich logische Defekte und mechanische Defekte unterscheiden, ordnen wir gesondert ein. Welche Warnzeichen einem Ausfall des Verbunds vorausgehen, sammelt die Übersicht zu den Symptomen eines defekten RAID.

Snapshots und Delta-Ketten

Ein Snapshot friert den Zustand einer virtuellen Maschine ein. Ab diesem Moment wird das Basis-Abbild nicht mehr beschrieben, alle Änderungen landen in einer eigenen Delta-Datei. Jeder weitere Snapshot erzeugt ein weiteres Glied. Beim Lesen arbeitet sich der Hypervisor durch diese Kette zurück, bis er den gesuchten Block findet.

Genau hier entsteht das häufigste Schadensbild in virtuellen Umgebungen. Drei Auslöser sehen wir immer wieder:

• ein vermeintlich altes Delta wird gelöscht
• ein Glied der Kette wird auf ein anderes Volume verschoben
• eine Konsolidierung bricht ab, weil der Speicher knapp wird

Der aktuelle Stand verteilt sich dann über mehrere Dateien und wirkt verloren. Rekonstruierbar ist er in vielen Fällen trotzdem, denn Reihenfolge und Zuordnung der Blöcke lassen sich aus den Metadaten der Delta-Dateien bestimmen. Voraussetzung dafür ist, dass anschließend nicht weiter auf den Datenspeicher geschrieben wurde.

Wichtig ist die Einordnung: Ein Snapshot ist kein Backup. Er liegt auf demselben Speicher wie die Maschine, die er sichern soll, und fällt mit ihr gemeinsam aus. Denselben Denkfehler beschreibt unser Beitrag RAID ist kein Backup für die Ausfallsicherheit von Speicherverbünden.

Ransomware in virtualisierten Umgebungen

Cyberangriffe zielen inzwischen bevorzugt auf die Hypervisor-Ebene statt auf einzelne Arbeitsplätze. Der Grund ist einfach: Wer die Containerdateien auf dem Datastore verschlüsselt, trifft sämtliche Gastsysteme eines Unternehmens auf einen Schlag, einschließlich der Server, die für Anwendungen und Datenbanken zuständig sind.

Für die Wiederherstellung ist das nicht zwangsläufig die schlechteste Ausgangslage. Weil virtuelle Festplatten sehr groß sind, beschränkt die Schadsoftware die Verschlüsselung häufig auf Teilbereiche der Dateien, etwa Kopfbereiche oder Abschnitte in festen Abständen. Die dazwischenliegenden Bereiche bleiben unverändert, sodass sich Dateien und Datenbankinhalte in vielen Fällen aus den unberührten Teilen zurückgewinnen lassen. Ob und in welchem Umfang das gelingt, zeigt die Analyse; eine pauschale Zusage wäre unseriös.

Sinnvoll ist in dieser Lage:

• den Host sofort vom Netzwerk trennen
• nichts löschen und den Zustand unverändert lassen
• kein Lösegeld zahlen
• die betroffenen Speichermedien vollständig für die Analyse bereithalten

Sind personenbezogene Daten betroffen, kann eine Meldepflicht nach DSGVO bestehen. Für die dafür nötige Beweissicherung und die Auswertung des Angriffswegs steht unsere IT-Forensik bereit.

Häufige Fragen zur Datenrettung aus virtuellen Systemen

Können Sie einzelne Dateien wiederherstellen oder nur die komplette virtuelle Maschine?

Beides ist möglich. Nach der Rekonstruktion der Containerdatei öffnen wir das Dateisystem des Gastsystems und können daraus gezielt einzelne Ordner, Dateien oder Datenbankbestände extrahieren. Alternativ liefern wir die vollständige virtuelle Festplatte zurück, sodass sich die Maschine in Ihrer Umgebung wieder starten lässt. Welche Variante sinnvoll ist, hängt davon ab, ob Sie die Infrastruktur ohnehin neu aufbauen oder den Betrieb möglichst schnell fortsetzen wollen.

Benötigen Sie den Original-Host oder den RAID-Controller?

Nein. Wir setzen den Verbund softwareseitig aus schreibgeschützten Abbildern der Einzellaufwerke zusammen, deshalb sind weder das Originalgehäuse noch der ursprüngliche Controller erforderlich. In den meisten Fällen genügen die Datenträger selbst. Wichtig ist, dass der Satz vollständig ist, einschließlich vermeintlich defekter Platten, und dass die Einbaupositionen beschriftet sind.

Lässt sich eine VM nach einer abgebrochenen Konsolidierung noch retten?

Häufig ja. Entscheidend ist, ob alle Glieder der Kette noch vorhanden sind und ob seither weiter auf den Datenspeicher geschrieben wurde. Aus den Metadaten der Delta-Dateien bestimmen wir Reihenfolge und Zuordnung der Blöcke und setzen die Kette in der richtigen Abfolge zusammen. Weitere Konsolidierungsversuche am Original verschlechtern die Ausgangslage dagegen meist.

Was passiert mit Datenbanken innerhalb der virtuellen Maschine?

Datenbankdateien liegen im Dateisystem des Gastsystems und werden mit ihm zusammen wiederhergestellt. Bei laufendem Betrieb zum Zeitpunkt des Ausfalls kann der Bestand inkonsistent sein, weil Transaktionen nur teilweise geschrieben wurden. In diesem Fall werten wir zusätzlich die Protokolldateien aus und stellen einen konsistenten Stand bereit. Gleiches gilt für beschädigte Sicherungsdateien gängiger Backup-Software wie Veeam, die auf demselben Speichersystem lagen. Liegt die Sicherung auf Band, führt die Seite zur Datenrettung von Magnetbändern weiter.

Wie schnell können Sie bei einem Produktivausfall arbeiten?

Rein logische Fälle sind oft innerhalb weniger Tage abgeschlossen. Sind mehrere Laufwerke physisch beschädigt, dauert es länger, weil jedes einzeln instand gesetzt und geklont werden muss, bevor die Rekonstruktion beginnt. Für zeitkritische Serversysteme steht eine Express-Bearbeitung rund um die Uhr bereit, die Ausfallzeiten so kurz wie technisch möglich hält. Die Einschätzung dazu erhalten Sie direkt nach der Diagnose.