Datenrettung für virtuelle Festplatten VMDK und VHDX

Virtuelle Datenträger bestehen oft aus Deskriptor, Datenextent, Snapshots und Parent-Beziehungen; eine falsche Konsolidierung kann den letzten intakten Zustand zerstören.

Angebot anfordern

Gestoppte virtuelle Maschine mit unveränderter Snapshot-Kette vor einer automatischen Konsolidierung

Erste Maßnahme

Eine nicht startende VM nicht automatisch konsolidieren oder reparieren

Eine virtuelle Maschine, die nicht mehr startet, kann eine beschädigte Snapshot-Kette, fehlende Extents, einen inkonsistenten Datastore oder ein defektes Gastdateisystem haben. Ein erneuter Start schreibt Protokolle, Journale und Anwendungsdaten in den aktiven Layer und kann den noch nachvollziehbaren Zustand verändern. Der Ausgangszustand des Datastores bleibt geschützt; die VM bleibt ausgeschaltet, bis Bestand und Abhängigkeiten kopiert sind.

Automatische Funktionen des Hypervisors werden gestoppt: Snapshot-Konsolidierung, Storage-Migration, Replikation, Backupjob und Hochverfügbarkeits-Neustart. Ein Merge übernimmt eine angenommene Parent-Child-Beziehung dauerhaft. Ist der Parent falsch, werden Blöcke verschiedener Zeitpunkte vermischt. Das Ergebnis kann formal startfähig wirken und dennoch Datenbankseiten oder Dateisystemstrukturen aus unvereinbaren Ständen enthalten.

Dokumentiert werden die erste Fehlermeldung, Zeitpunkt des letzten normalen Betriebs, letzter Snapshot, fehlgeschlagene Sicherung und alle manuellen Aktionen. Hypervisor-Ereignisse und Datastore-Warnungen werden exportiert, sofern dafür kein instabiles Storage neu gestartet werden muss. Auch umbenannte, verwaiste oder scheinbar alte Dateien bleiben erhalten; ihr Zeitstempel allein sagt nichts über ihre Rolle aus.

Die erste Sicherung umfasst nicht nur die größte VMDK oder VHDX. Konfiguration, Deskriptoren, Deltas, Extents, Protokolle, NVRAM beziehungsweise VM-Status und externe Volumes können gemeinsam erforderlich sein. Ein vollständiges Dateilisting mit Größe, Pfad und Prüfsumme bildet die Ausgangslage. Erst auf einer Kopie werden mögliche Ketten aufgebaut.

VM, Replikation und automatische Konsolidierung stoppen
Datastore-Inventar vor Umbenennung oder Verschieben sichern
Fehlerchronologie und letzten bekannten Betriebsstand dokumentieren

Fehlgeschlagene Konsolidierung

Parent- und Delta-Dateien bleiben unverändert. Die gemeldete Abhängigkeit wird gegen Deskriptoren, IDs und Hypervisor-Logs geprüft.

Automatischer HA-Neustart

Ein anderer Host kann denselben beschädigten Datastore erneut beschreiben. Hochverfügbarkeit wird bis zur gesicherten Arbeitskopie kontrolliert ausgesetzt.

Eine erfolgreich gestartete VM kann bereits neue Blöcke in den falschen Snapshot schreiben und ist deshalb kein neutraler Funktionstest.

Snapshot-Kette

Snapshots über Parent, Delta und Inhaltskennung lückenlos zuordnen

Ein Snapshot ist kein eigenständiger vollständiger Datenträger. Er speichert geänderte Blöcke und verweist auf einen Parent. VMware nutzt je nach Format Deskriptoren, CID und parentCID sowie Flat-, Sparse- oder SESparse-Extents; Hyper-V verbindet VHDX mit AVHDX-Checkpointdateien. QCOW2 kann ein Backing File referenzieren. Nutzbar wird der Zustand nur mit der richtigen, vollständigen Kette.

Jede Datei erhält Pfad, Größe, UUID beziehungsweise Inhaltskennung, Headerinformationen und Prüfsumme. Änderungsdaten sind Indizien, aber keine verlässliche Reihenfolge: Kopiervorgänge, Zeitabweichungen und Backupsoftware können sie verändern. Parent-Verweise aus Metadaten werden mit Hypervisor-Konfiguration, Logs und bekannten Snapshotnamen abgeglichen. Eine ähnlich große Basisdatei wird nicht als Ersatzparent eingesetzt.

Fehlen Deskriptoren, können sie aus Extent-Geometrie und erhaltenen Metadaten abgeleitet werden; die Rekonstruktion bleibt auf einer Kopie. Bei doppelten IDs oder umbenannten Dateien entstehen mehrere Hypothesen. Jede Hypothese wird getrennt aufgebaut und gegen Partitionstabellen, Dateisystemstrukturen und bekannte Dateien geprüft. Ein mountbarer Anfang reicht nicht, wenn spätere Blöcke aus dem falschen Zeitpunkt stammen.

Der jüngste Snapshot ist nicht automatisch der beste

Die gewünschte Zeitlinie wird vorab benannt: letzter konsistenter Start, Zeitpunkt vor einem Update oder Zustand unmittelbar vor einer Fehlbedienung. Enthält er bereits Korruption oder Ransomwarefolgen, kann ein älterer Stand fachlich wertvoller sein. Mehrere Ergebnisse bleiben getrennt, statt stillschweigend vermischt zu werden.

Abgebrochene Merges können Teile bereits in die Basis geschrieben haben

Snapshot-Löschung und Konsolidierung werden erst nach dieser Zuordnung simuliert. Parent und Child müssen Kapazität, Sektorgröße, Geometrie und erwartete Inhaltskennung teilen. Dann ist eine einfache lineare Kette möglicherweise nicht mehr gültig; Lesemuster und Journale entscheiden, welcher Blockstand für den Zielzeitpunkt plausibel ist.

Metadatenbereiche von VMDK, VHDX und QCOW2 werden formatspezifisch auf einer Diagnosekopie verglichen

Formatdiagnose

VMDK, VHDX und QCOW2 anhand ihrer eigenen Metadaten rekonstruieren

VMDK bezeichnet mehrere Layouts: monolithisch sparse, zweigeteilt in Deskriptor und Flat-Extent oder in Segmente aufgeteilt. VHDX verwaltet Headerkopien, Region Table, BAT, Log und Metadatenregion. QCOW2 nutzt Header, L1- und L2-Tabellen, Refcounts und optional ein Backing File. Ein generischer Dateiscan kann diese internen Zuordnungen nicht durch eine gemeinsame Reparaturregel ersetzen.

Zunächst werden beide Headerkopien und redundante Strukturen verglichen. Ein unvollständiger Schreibvorgang kann eine Kopie aktualisiert und die andere unverändert gelassen haben. Logeinträge werden nicht ungeprüft eingespielt; ihre Sequenz und Zielblöcke müssen zum rekonstruierten Zeitpunkt passen. Bei dynamischen Datenträgern bedeutet die Dateigröße außerdem nicht, dass jeder logische Block physisch belegt ist.

Thin- und Sparse-Formate unterscheiden nicht zugewiesene Bereiche von explizit geschriebenen Nullen. Beschädigte Allocation Maps können reale Daten wie freien Raum erscheinen lassen. Die Analyse verbindet Metadaten, Dateisystemerwartung und zugrunde liegenden Datastore. Unbelegte Cluster werden nicht mit verloren gegangenen Extents gleichgesetzt; fehlende Quellblöcke bleiben als Grenze markiert.

Nach der Formatrekonstruktion entsteht ein schreibgeschützter logischer Blockstream. Erst dieser wird auf Partitionen, LVM, NTFS, ReFS, ext oder XFS untersucht. Mehrere technische Versionen erhalten eigene Namen und Prüfsummen. So bleibt nachvollziehbar, welche Header-, BAT- oder Refcount-Hypothese zu welchem exportierten Gastbestand geführt hat.

VMDK-Deskriptor und Extents vollständig zuordnen
VHDX-Header, BAT und Log getrennt prüfen
QCOW2-Tabellen und Backing File verifizieren

VMDK und SESparse

Deskriptor, CID, Grain Tables und Extents müssen denselben Datenträger und Snapshotstand beschreiben.

VHDX und AVHDX

Checkpointbeziehungen, BAT, Log und redundante Header werden gemeinsam ausgewertet, bevor ein Merge auf Kopie getestet wird.

Dynamisch belegter Speicher darf nicht mit fehlenden Datastore-Blöcken verwechselt werden; beide erscheinen außerhalb des Formats sonst ähnlich leer.

Vollständiger Datastore und physische Storage-Ebene werden vor der Analyse getrennt schreibgeschützt kopiert

Quellsicherung

Datastore und physisches Storage vor der logischen Analyse kopieren

Virtuelle Festplatten liegen häufig auf VMFS, ReFS, Cluster Shared Volumes, NFS, ZFS oder einem proprietären SAN- beziehungsweise NAS-Pool. Ein Dateiexport durch den laufenden Host kann Fehler übergehen, Sparse-Eigenschaften verändern oder nur den aktuell sichtbaren Namespace erfassen. Deshalb wird geklärt, ob eine dateibasierte Sicherung genügt oder der Datastore blockweise aus dem Storage rekonstruiert werden muss.

Bei beschädigtem RAID, SAN oder NAS beginnt die Sicherung unterhalb der VM-Datei. Laufwerksreihenfolge, Controllerzustand und Lesefehler werden erhalten. Die RAID- und NAS-Datenrettung behandelt diese physische beziehungsweise logische Verbundebene. Eine VM-Kette kann erst dann belastbar sein, wenn die Extents des Datastores aus konsistenten Arbeitsabbildern stammen.

Datastore-Metadaten, Journale und Allocation Maps werden zusammen mit den VM-Dateien kopiert. Gelöschte oder verwaiste Deltas können außerhalb des aktuellen Verzeichnisbaums liegen. Ein Storage-Snapshot ist als zusätzliche Quelle nützlich, ersetzt aber keine unabhängige Sicherung, wenn er auf demselben beschädigten Pool liegt. Replikate und Backups behalten ihre Herkunft und ihren Zeitstand.

Der Produktivdatastore bleibt unverändert und wird nicht als Ziel einer Testkonsolidierung verwendet

Erst auf diesen Kopien werden Deskriptoren korrigiert, Snapshots verbunden oder gelöschte Dateien gesucht. Wenn eine blockweise Sicherung technisch nicht vollständig möglich ist, wird der verfügbare Bestand samt Grenzen dokumentiert, bevor eine Rekonstruktionshypothese gestartet wird.

Nicht gelesene Zonen werden nicht still mit Nullen aufgefüllt

Für jedes Quellabbild werden Größe, Leseprotokoll und Prüfsumme festgehalten. Thin Provisioning bleibt semantisch erhalten; ein Export, der alle nicht belegten Bereiche materialisiert, kann Speicherbedarf und Blockbedeutung verändern. Sie bleiben positionsbezogen dokumentiert, damit spätere Gastdateifehler technisch erklärt werden können.

Rekonstruierte virtuelle Festplatte wird schreibgeschützt geöffnet, bevor das Gastsystem erneut startet

Gastdateisystem

Die rekonstruierte virtuelle Disk zuerst schreibgeschützt öffnen

Ein konsistenter logischer Blockstream wird nicht sofort als virtuelle Maschine gestartet. Zuerst werden Partitionen und Dateisysteme schreibgeschützt geprüft, damit Windows, Linux oder eine Appliance keine Journale wiedergibt und keine automatischen Reparaturen ausführt. Der Gast bleibt vom Produktivnetz getrennt. Eine weitere Arbeitskopie nimmt unvermeidbare Tests auf.

Partitionstabellen, LVM, NTFS, ReFS, ext, XFS und anwendungseigene Volumes werden in ihrer Reihenfolge geöffnet. Ein sichtbarer Ordnerbaum ist nur ein erster Befund. Große Dateien über mehrere Extents, Sparse Files, Archive und Datenbanken zeigen, ob die Snapshotkette tatsächlich zusammenpasst. Blöcke aus falschen Zeitständen können sich erst tief in einer Datei bemerkbar machen.

Sind Reparaturen erforderlich, laufen sie auf einer duplizierten Arbeitsversion und werden protokolliert. Die unveränderte Rekonstruktion bleibt als Referenz erhalten. Ein Starttest erfolgt erst, wenn Dateisystem und kritische Dateien plausibel sind. Netzwerkadapter bleiben deaktiviert, damit Domänen-, Replikations- oder Updateprozesse keine externen Systeme beeinflussen und keine neuen Daten in die VM schreiben.

Bei verschlüsselten Gastvolumes werden gültige Schlüssel, Recovery-Informationen und Eigentumsnachweis benötigt. Die Rekonstruktion umgeht keine intakte Verschlüsselung. Schlüssel werden getrennt von allgemeinen Logs übermittelt. Der entschlüsselte Export erhält seine Herkunft zum konkreten VM- und Snapshotstand, damit spätere Versionen nicht miteinander verwechselt werden.

Gastpartitionen zunächst ausschließlich lesend prüfen
Reparaturversuche auf einer zweiten Arbeitskopie protokollieren
Starttest ohne Produktivnetz und automatische Dienste durchführen

Lesender Strukturtest

Partitionen, Volumes und bekannte Dateien werden geprüft, ohne Journale oder Gastdienste auszuführen.

Isolierter Starttest

Eine zusätzliche Arbeitskopie startet ohne Produktivnetz. Schreibvorgänge und Anwendungsreaktionen bleiben von der Referenz getrennt.

Ein erfolgreicher Bootvorgang beweist nicht, dass Dateisystem, Datenbank und alle später gelesenen Extents denselben Zeitstand besitzen.

Datenbankdateien, Transaktionslogs und virtuelle Dienste werden nach dem Mounten auf zeitliche Konsistenz geprüft

Anwendungsprüfung

Datenbanken und Dienste auf Anwendungskonsistenz statt Mountbarkeit prüfen

Eine Datenbankdatei, die sich kopieren lässt, ist noch kein verwendbarer Dienst. Datenfiles, Transaktionslogs, Konfiguration, Zertifikate und externe Volumes müssen zu demselben Zeitpunkt passen. Bei Domain Controllern, Mailservern oder ERP-Systemen kommen Replikationszustand und weitere Abhängigkeiten hinzu. Die Prüfung orientiert sich am gewünschten fachlichen Ergebnis, nicht nur am Startsignal.

Datenbank und Logs werden in einer isolierten, kompatiblen Umgebung geöffnet. Native Wiederherstellungsmechanismen dürfen ausschließlich auf einer Arbeitskopie schreiben. Objektzahlen, bekannte Datensätze und Zeiträume werden kontrolliert. Wenn ein sauberer Instanzstart nicht möglich ist, kann ein nachvollziehbarer Export intakter Tabellen sinnvoller sein als eine aggressive Reparatur, die Beziehungen entfernt.

Anwendungen mit externen LUNs benötigen auch diese Datenträger

Bei virtuellen Dateiservern werden Freigaben, Rechte und priorisierte Projekte geprüft; bei Mailarchiven ausgewählte Postfächer und Anhänge. Eine allein gerettete Systemdisk kann funktionsfähig erscheinen, während Nutzdaten fehlen. Die Inventarliste verbindet jede virtuelle Disk mit ihrer Rolle und den benötigten Schlüsseln.

Diese Entscheidung wird mit Zeitlinie und fachlichen Stichproben belegt

Der Ergebnisbericht unterscheidet konsistent gestarteten Dienst, validierten Datenexport und nur technisch kopierbare Dateien. Fehlende Blöcke, unvollständige Logs oder widersprüchliche Snapshotstände bleiben sichtbar. Ein älterer konsistenter Stand kann verlässlicher sein als der jüngste beschädigte.

Rekonstruierter VM-Stand wird mit Snapshotzeit, Prüfsummen und markierten fehlenden Blöcken dokumentiert

Nachweis

Rekonstruierten VM-Stand und fehlende Blöcke nachvollziehbar dokumentieren

Jede rekonstruierte Version erhält eine eindeutige Kennzeichnung aus Quellbestand, Snapshotkette, Zielzeitpunkt und Prüfsumme. Ein Ordner mit dem Namen „recovered“ ohne Herkunft und Blockstatus ist für eine virtuelle Infrastruktur nicht ausreichend. Manifest und Kettenübersicht zeigen, welche Basis, Deltas und Datastore-Abbilder verwendet wurden.

Nicht gelesene oder fehlende Blöcke werden positionsbezogen erhalten. Soweit möglich, werden sie Gastpartitionen und betroffenen Dateien zugeordnet. Sparse oder nie belegte Bereiche bleiben davon getrennt. Eine Datei mit plausibler Größe kann einen fehlenden Extent enthalten; formatgerechte Tests und fachlich bekannte Beispiele müssen deshalb die technische Blockkarte ergänzen.

Mehrere mögliche Zeitstände werden nicht automatisch überschrieben. Ein älterer konsistenter Dienst, ein jüngerer Dateiexport und Fragmente aus dem letzten Delta können getrennt geliefert werden. Die Dokumentation erklärt, warum eine Kombination nicht vorgenommen wurde. Dadurch kann der Auftraggeber den Betriebswiederanlauf planen, ohne eine künstlich verschmolzene Version als sichere Wahrheit zu übernehmen.

Die Übergabe erfolgt auf einem gesunden Zielspeicher oder über einen vereinbarten geschützten Transfer. Startfähige VMs bleiben bis zur fachlichen Abnahme isoliert. Vertrauliche Inhalte werden nur in dem Umfang geprüft, den Prioritäten und Berechtigungen verlangen. Nach bestätigter Übernahme werden Aufbewahrung und Löschung technischer Arbeitskopien nach Vereinbarung festgelegt.

Basis, Deltas und Zielzeitpunkt im Manifest festhalten
Fehlende Blöcke von Sparse-Bereichen unterscheiden
Technische und fachliche Stichproben gemeinsam dokumentieren

Protokoll der Kette

Parent, Child, Kennungen und verwendete Quellabbilder bleiben für jede Ergebnisversion nachvollziehbar.

Blockbezogene Grenzen

Nicht gelesene Bereiche werden nicht versteckt, sondern mit den wahrscheinlich betroffenen Gastdateien verknüpft.

Eine startfähige virtuelle Maschine ist erst belastbar, wenn ihr Zeitstand, ihre Abhängigkeiten und priorisierten Anwendungsdaten geprüft wurden.

VM-Inventar, Hypervisor-Protokolle und vollständige Snapshot-Kette liegen geordnet für die Diagnose bereit

Auftrag

VM-, Hypervisor- und Snapshotinventar für die Diagnose vollständig vorbereiten

Für die Erstbewertung werden Hypervisor und Version, VM-Name, Gastbetriebssystem, virtuelle Disks, Datastore-Pfad, Snapshotliste und Fehlermeldung benötigt. Ein Verzeichnislisting mit Größen und Zeitstempeln ist hilfreicher als ein einzelner Screenshot. Beschreiben Sie Konsolidierungen, Migrationen, Backups, Umbenennungen und Startversuche in ihrer Reihenfolge. Keine Datei wird vorab gelöscht oder verschoben.

Bei physischem Storagefehler werden Controller-, RAID- und Hostinformationen ergänzt. Die Datenrettung für Server ordnet Hardware und Dienste ein. Der Ablauf der Datenrettung beschreibt Diagnose, Freigabe und Übergabe. Für eine Bewertung kann ein Angebot zur Datenrettung mit Inventar und fachlichen Prioritäten angefragt werden.

Bereits vorhandene Backups oder Replikate behalten Datum und Herkunft

Die Prioritätenliste nennt den gewünschten Zeitpunkt, wichtige VM, Datenbank, Freigabe oder einzelne Dateien. Verschlüsselungsschlüssel und Zugangsdaten werden sicher getrennt übermittelt. So lässt sich entscheiden, ob eine vollständige VM-Rekonstruktion oder ein gezielter Export den verlässlichsten und wirtschaftlich sinnvollsten Weg bietet.

Die Kapazität der virtuellen Disk allein beschreibt den Aufwand nicht

Originaldatastore und vorhandene Dateien bleiben schreibgeschützt erhalten. Das Angebot richtet sich nach Kettenlänge, fehlenden Komponenten, Storagezustand, Format und Anwendungsprüfung. Ein Ergebnis wird auf einem gesunden Zielspeicher eingebunden und niemals als Test auf den beschädigten Produktivbestand zurückgeschrieben.

Häufige Fragen

Warum darf eine beschädigte Snapshot-Kette nicht direkt konsolidiert werden?

Eine Konsolidierung schreibt die angenommene Parent-Child-Beziehung dauerhaft fort. Ist der Parent falsch oder fehlt ein Delta, werden Blöcke verschiedener Zeitpunkte vermischt. Zuerst werden Datastore, Deskriptoren, Extents und Snapshots kopiert. Mehrere Kettenhypothesen lassen sich anschließend getrennt und ohne Änderung des Originals prüfen.

Welche Angaben belegen den richtigen Parent einer VMDK oder VHDX?

CID, parentCID, UUIDs, Headerverweise, Hypervisor-Konfiguration, Logs und bekannte Snapshotnamen werden gemeinsam ausgewertet. Dateigröße und Änderungsdatum sind nur Indizien. Die gewählte Kette muss zudem Partitionen, Dateisystem und bekannte Nutzdaten über verschiedene Blockbereiche konsistent wiedergeben.

Wie beeinflussen Thin Provisioning und Sparse Files die Datenrettung?

Nicht jeder logische Block ist physisch belegt. Beschädigte Allocation Maps können aber auch tatsächlich geschriebene Daten verschwinden lassen. Die Analyse trennt nie zugewiesene Bereiche von fehlenden Datastore-Extents und dokumentiert nicht gelesene Blöcke positionsbezogen. Eine bloße Folge von Nullen erklärt diese Herkunft nicht.

Wann gilt eine virtuelle Datenbank als wirklich verwendbar?

Datenfiles, Transaktionslogs, Konfiguration und externe Volumes müssen zu einem konsistenten Zeitpunkt passen. Eine isolierte Prüfung kontrolliert Start, Objektzahlen und bekannte Datensätze. Das Auffinden der Datenbankdatei oder Mounten des Gastvolumes reicht nicht; möglich bleibt auch ein klar dokumentierter Export intakter Teilbestände.

Datenträger

Weitere Fachbereiche

Diagnose

Unsicher bei Datenträger oder Schadenbild?

Datastrophe bewertet das Risiko vor jedem Eingriff und nennt den vorsichtigsten nächsten Schritt.

Diagnose anfragen