Seit den Anfängen der Virtualisierung sind die Plattformen von VMware in Unternehmen weit verbreitet. In Rechenzentren wie in kleinen und mittleren Unternehmen laufen Server heute überwiegend virtualisiert. Das erhöht die Auslastung und macht unabhängig von der Hardware, verschiebt im Schadensfall aber alles auf eine Ebene: Fällt der Speicher unter dem Hypervisor aus, stehen nicht ein System, sondern alle gleichzeitig.
Erste Hilfe bei ausgefallenen VMware-Systemen
Bei einem Datenverlust unter VMware entscheidet die erste Stunde. Diese Schritte erhalten den Zustand, in dem Ihre Daten noch erreichbar sind:
- Das Hostsystem herunterfahren, sobald der Verlust auffällt. Jeder Schreibvorgang auf der Ebene des Dateisystems kann verlorene Bereiche überschreiben.
- Den Datenspeicher nicht neu formatieren. Auch nicht neu signieren. Broadcom empfiehlt in seiner Wissensdatenbank bei beschädigten VMFS-Metadaten ausdrücklich, das Gerät zu räumen und neu zu formatieren. Für den Betrieb ist das folgerichtig, für Ihre Daten ist es das Ende.
- Die Reparaturfunktion nicht mit Korrekturoption starten. Sie schreibt auf genau die Metadaten, die für die Rekonstruktion gebraucht werden.
- Die Partitionstabelle nicht neu schreiben. Ein um wenige Sektoren falscher Startwert macht das Volume unlesbar, obwohl alles vorhanden ist.
- Keine Delta-Dateien löschen. Und keine laufende Konsolidierung abbrechen. Damit reißt die Snapshot-Kette endgültig.
- Kein RAID neu aufbauen. Der Wiederaufbau überschreibt genau die Bereiche, in denen die virtuellen Festplatten liegen.
Zur Einordnung: Broadcom stellt selbst klar, dass VMware keine Datenrettungsleistungen anbietet. Der Herstellersupport endet damit genau dort, wo eine Datenrettung beginnt.
Halten Sie den Wortlaut der Meldung fest, bevor Sie etwas unternehmen. Danach folgt die Analyse: Sie sagt, welche Ebene betroffen ist und was sich aus dem Datastore wiederherstellen lässt. Eine VMware-Datenrettung beginnt immer mit diesem Befund, nie mit einem Reparaturversuch am laufenden System.
Typische Fehlerbilder und Ursachen bei VMware
Fast jeder Fall, der uns erreicht, gehört in eine dieser vier Gruppen. Der Wortlaut der Meldung sagt dabei mehr aus als jede Beschreibung, halten Sie ihn deshalb fest, bevor Sie etwas unternehmen.
| Fehlerbild | Typische Meldung | Was das bedeutet |
|---|---|---|
| Datenspeicher verschwunden, Gerät sichtbar | Gerät erscheint als "Not Consumed", partedUtil meldet "unknown" statt "gpt", im vmkernel.log steht "LVM: ... detected to be a snapshot" | Partitionstabelle oder Kennung im LVM-Kopf zerstört. Die Nutzdaten liegen unverändert dahinter. |
| Datenspeicher eingebunden, Dateien unlesbar | "Invalid argument" beim Lesen, im vmkernel.log "Volume ... may be damaged on disk. Corrupt heartbeat detected at offset ..." | Beschädigte Heartbeat- oder Journalregion nach einem Speicherausfall. |
| Snapshot-Kette gerissen | "Cannot open the disk ... or one of the snapshot disks it depends on. Reason: The parent virtual disk has been modified since the child was created." | Die Verkettung stimmt nicht mehr, meist nach Kopieren, Verschieben oder einem abgebrochenen Zusammenführen. Die Daten sind vollständig vorhanden. |
| vSAN-Objekte nicht erreichbar | Maschine erscheint als "Inaccessible" oder "Orphaned", Komponenten als "Degraded" oder "Absent" | Es fehlt ein vollständiges Replikat oder die Mehrheit der Stimmen im Cluster. |
In drei dieser vier Fälle sind die Nutzdaten physisch noch vollständig vorhanden. Was den Fall entscheidet, ist nicht der Datenverlust selbst, sondern die Reaktion darauf.
Was hinter diesen Fehlerbildern steckt
Die Auslöser eines VMware-Datenverlusts sind überschaubar. Diese Ursachen führen zu den Meldungen aus der Tabelle:
- RAID-Verbund unterhalb der VMware-Ebene defekt
- Virtuelle Maschinen oder Snapshots versehentlich gelöscht
- Beschädigtes VMFS-Volume oder beschädigte VMDK-Dateien
- Ausfall mehrerer Laufwerke oder Fehler in der iSCSI-Anbindung
- Datenspeicher überschrieben, etwa durch versehentliche Neuinstallation oder Formatierung
- Fehler innerhalb der virtuellen Maschine, etwa beschädigte SQL- oder Exchange-Datenbanken
Der Unterschied zwischen diesen Ursachen ist für die VMware-Datenrettung geringer, als er wirkt. Entscheidend für die Datenwiederherstellung ist, auf welcher Ebene der Schaden sitzt: unter dem Datastore, im VMFS, in der VMDK oder erst im Dateisystem der virtuellen Maschine.
Wenn vCenter oder der ESXi-Host ausfällt
Ein Ausfall der Verwaltung ist kein Datenverlust. Startet vCenter nicht mehr oder verweigert vSphere den Zugriff, liegen die VMs weiterhin unversehrt auf dem Datastore. Verloren ist die Sicht darauf, nicht der Inhalt. Dasselbe gilt, wenn ein ESXi-Host selbst nicht mehr startet: Die virtuellen Festplatten liegen auf dem Speicher, nicht im Hypervisor.
Kritisch wird es erst, wenn in dieser Lage neu installiert wird. Eine Neuinstallation von ESXi auf denselben Datenträger kann die Partitionierung des Datastores überschreiben. Wer vCenter oder den Host wiederherstellen will, sollte deshalb vorher wissen, wo der Datastore physisch liegt, und diesen Datenträger unangetastet lassen.
Eine Maschine oder der ganze Datenspeicher
Eine einzelne VM ist betroffen
- Die übrigen VMs laufen weiter
- Meist eine beschädigte VMDK oder eine gerissene Snapshot-Kette
- Der Datastore selbst ist lesbar
- Die betroffene VM bleibt ausgeschaltet, der Rest darf laufen
Der Datenspeicher ist betroffen
- Alle VMs auf diesem Datastore stehen gleichzeitig still
- Meist ein Schaden am VMFS oder am RAID darunter
- Der ESXi-Host meldet das Gerät als nicht eingebunden
- Das Hostsystem gehört heruntergefahren, nicht neu gestartet
Diese Unterscheidung bestimmt Aufwand und Dringlichkeit. Trifft der Datenverlust eine einzelne VM, ist der Betrieb eingeschränkt. Trifft er den Datastore, steht das Unternehmen still. Beide Fälle bearbeiten wir, aber der zweite läuft in aller Regel als Express-Auftrag.
Welche VMware-Daten sich wiederherstellen lassen
Die Frage, die am Telefon zuerst kommt. Eine belastbare Antwort gibt erst die technische Analyse der VMware-Umgebung, weil sie vom Beschädigungsgrad abhängt. Diese Szenarien einer VMware-Datenrettung bearbeiten wir regelmäßig:
- Virtuelle Maschinen und VMDK-Dateien. Sind Deskriptor und Datendatei vorhanden, lässt sich die virtuelle Festplatte in aller Regel vollständig wiederherstellen.
- Daten aus beschädigten VMFS-Datastores. Ist nur die Partitionstabelle oder die Kennung im LVM-Kopf zerstört, liegen die Nutzdaten unverändert dahinter.
- Gelöschte VMs. Solange auf den Datenträgern nicht weiter geschrieben wurde, sind die Bereiche der VMDK meist noch vorhanden.
- Daten aus beschädigten oder verwaisten Snapshot-Ketten. Bei einem Kettenbruch sind die Daten in aller Regel vollständig da, nur die Verkettung stimmt nicht mehr.
- Dateien und Datenbanken innerhalb des Gastsystems. Auch wenn die VM selbst nicht mehr startet, lassen sich SQL- und Exchange-Datenbanken, Postfächer und Nutzerdaten aus dem Gastdateisystem holen.
- Daten nach Ausfall des Storage-Systems. Nach der Datenrettung auf der Ebene des Verbundes wird der Datastore wieder lesbar und die VMs daraus entnommen.
Was sich davon in Ihrem Fall erreichen lässt, sagt die Analyse und nicht eine Zusage vorab. Wenn relevante Datenbereiche überschrieben wurden, fehlen sie; ein Datenspeicher, über den eine Neuinstallation gelaufen ist, gibt diese Bereiche nicht mehr her. Nach der Analyse benennen wir, welcher Stand erreichbar ist, und erst dann entscheiden Sie.
Wiederherstellung innerhalb der Maschine
Ein Teil der Aufträge betrifft gar nicht den Datastore. Die VMDK ist lesbar, die Maschine startet, aber im Gastsystem fehlen Daten: eine gelöschte Freigabe auf dem Dateiserver, eine beschädigte SQL-Datenbank, ein formatiertes Laufwerk innerhalb der VM. Dann liegt der Datenverlust eine Ebene höher, im Dateisystem des Gastes.
Für die Datenwiederherstellung ändert das die Reihenfolge, nicht das Vorgehen: Statt Verbund und VMFS ist das Dateisystem in der VMDK wiederherzustellen. Wichtig ist auch hier, die betroffene Maschine auszuschalten. Solange sie läuft, schreibt das Gastsystem weiter und überschreibt genau die Bereiche, die wiederherzustellen wären.
Warum Recovery-Software hier selten hilft
Für Windows-Datenträger gibt es brauchbare Software zur Datenwiederherstellung. Bei VMware scheitert sie meist an drei Punkten, und der Vorgang kostet dabei Zeit, die der Fall nicht hat:
- Das Dateisystem. Übliche Tools kennen NTFS und ext4, aber nicht VMFS. Ohne Zugriff auf den Datastore finden sie die VMDK-Dateien gar nicht erst.
- Die Größe. Eine flache VMDK ist hunderte Gigabyte bis mehrere Terabyte groß. Programme, die große Dateien aus Bruchstücken zusammensetzen, liefern eine Datei, die sich nicht mehr einbinden lässt.
- Die zweite Ebene. Selbst eine vollständig wiederhergestellte VMDK ist nur ein Container. Das Dateisystem darin muss anschließend gelesen werden, und dafür braucht es eine Wiederherstellung auf der Ebene des Gastsystems.
Dazu kommt das Risiko: Solche Programme schreiben ihre Zwischenstände gern auf denselben Datenträger. Bei einem RAID-Verbund unter dem Datastore genügt ein solcher Vorgang, um die Bereiche zu überschreiben, in denen die virtuellen Festplatten liegen.
Auch Software mit VMFS-Funktion löst das Problem selten. Solche Tools lesen den Datastore im Normalzustand; bei beschädigten Metadaten fehlt ihnen genau die Funktion, die gebraucht wird. Was danach als Recovery angeboten wird, ist meist eine Auswahl von Bruchstücken ohne Zusammenhang.
Wo die Datenrettung an Grenzen stößt
Ehrlich bleibt nur, wer die Grenzen einer Datenwiederherstellung nennt. Überschriebene Bereiche sind weg: Ein Datenspeicher, der neu formatiert und danach beschrieben wurde, gibt die alten Daten in diesem Umfang nicht mehr her. Dasselbe gilt nach einem RAID-Neuaufbau, der bereits durchgelaufen ist.
Bei vSAN liegt der Fall anders: Dort verteilt vSphere die Objekte einer virtuellen Maschine über mehrere Knoten des Clusters. Fehlt die Mehrheit der Komponenten dauerhaft, lässt sich das Objekt nicht mehr zusammensetzen. Einzelne ausgebaute Datenträger helfen in solchen Umgebungen wenig; der Weg führt über die Instandsetzung des Clusters.
Kennen Sie schon unsere Datengarantie?
Eine Datenrettung gilt bei uns erst dann als erfolgreich, wenn mindestens 95 % Ihrer Daten wiederhergestellt sind, in der Regel sind es 100 %. Das halten wir vertraglich fest. Erreichen wir diese Schwelle nicht, entstehen Ihnen für die Wiederherstellung keine Kosten.
Bei VMware zählt dabei der Inhalt der virtuellen Maschinen, nicht die Zahl der wiederhergestellten Dateien: Eine VMDK, die sich einbinden lässt, deren Gastdateisystem aber leer bleibt, ist für uns kein Erfolg.
VMDK, VMFS und beschädigte Snapshot-Ketten
Für die Datenwiederherstellung ist entscheidend, dass eine virtuelle Festplatte aus zwei Dateien besteht: einem Deskriptor von wenigen Kilobyte, der Geometrie und Verweise enthält, und der eigentlichen Datendatei. Zusammen bilden sie die Virtual Machine Disk, kurz VMDK. Kommt ein Snapshot dazu, wird die Basis eingefroren und alle Änderungen laufen in eine Delta-Datei. Der Zustand, den die Virtual Machine sieht, ergibt sich erst aus allen Gliedern der VMDK-Kette zusammen.
Für die VMware-Datenrettung folgt daraus alles Weitere. Eine VM besteht nicht aus einer Datei, und bei Snapshots hängt der aktuelle Datenstand an mehreren verknüpften Bestandteilen. Fehlt ein Deskriptor oder ist eine Delta-Kette beschädigt, muss diese Struktur rekonstruiert werden, bevor überhaupt auf das Gast-Dateisystem zugegriffen werden kann.
Wo die virtuellen Maschinen liegen
Der Speicherort der VMDK entscheidet mit darüber, wie eine Datenwiederherstellung bei VMware abläuft. In kleineren Umgebungen liegt der Datastore auf einem lokalen RAID-Verbund im Server, in größeren auf einem eigenen Speichersystem, das mehrere ESXi-Hosts gleichzeitig bedient. Beides ist in Unternehmen verbreitet, und beides ändert nichts daran, dass die virtuellen Festplatten als VMDK-Dateien auf einem VMFS-Datastore liegen.
Für die Analyse brauchen wir deshalb immer die Angabe, wo der Datastore physisch liegt. Ein Zugriff über den laufenden ESXi-Host hilft im Schadensfall nicht weiter: Wenn ESXi den Datastore nicht mehr einbindet, gibt auch vSphere keine Dateien mehr heraus. Der Weg über die Verwaltungsoberfläche ist damit versperrt.
Virtualisierung fügt dem Speicher eine Ebene hinzu, und genau daran unterscheidet sich eine VMware-Datenrettung von der an einem einzelnen Server. Ohne Virtualisierung liegt ein Dateisystem auf dem Datenträger. Mit Virtualisierung liegt das Dateisystem des Gastes in einer Datei, die selbst in einem Dateisystem auf dem Datenträger liegt. Beide Ebenen können unabhängig voneinander beschädigt sein.
Was im Ordner einer virtuellen Maschine liegt
Auf dem VMFS-Datastore hat jede VM einen eigenen Ordner. Welche Datei fehlt, entscheidet über den Aufwand der VMware-Datenrettung:
| Datei | Inhalt | Wenn sie fehlt oder beschädigt ist |
|---|---|---|
| Name.vmx | Konfiguration der Maschine | Die Maschine startet nicht, die Daten in der VMDK bleiben unberührt |
| Name.vmdk | Deskriptor mit Geometrie und Verweisen | Die Zuordnung zur Datendatei fehlt und muss rekonstruiert werden |
| Name-flat.vmdk | Die eigentliche Datendatei | Hier liegen die Nutzdaten; ohne sie hilft kein anderer Bestandteil |
| Name-00000n-delta.vmdk | Die Änderungen seit einem Snapshot | Der Stand seit dem Snapshot fehlt, ältere Stände bleiben erreichbar |
| Name.vmsd, Name.vmsn | Verwaltung und Zustand der Snapshots | Die Reihenfolge der Kette muss neu bestimmt werden |
| Name.nvram, vmware.log | BIOS-Einstellungen und Protokoll | Für die Daten ohne Bedeutung, für die Analyse oft aufschlussreich |
Die Datendatei mit der Endung flat.vmdk ist der eigentliche Datenträger der virtuellen Maschine. Sie ist so groß wie die eingerichtete virtuelle Festplatte und enthält das Dateisystem des Gastes, meist NTFS oder ext4, mit eigener Partitionstabelle. Für eine Datenwiederherstellung heißt das: Nach dem VMFS kommt eine zweite Ebene, die genauso gelesen werden will.
Für die Anfrage genügt uns der Name des Ordners und der Speicherort des Datastores. Aus dem Ordner ergibt sich, welche Maschine betroffen ist; aus dem Speicherort, welche Datenträger wir brauchen. Beides steht in der Regel noch in der Konfiguration, auch wenn der Datastore selbst nicht mehr eingebunden ist.
Wenn die Snapshot-Kette reißt
Der häufigste Auslöser ist harmlos gemeint: Eine VM wird kopiert oder verschoben, eine Konsolidierung bricht ab, ein Snapshot wird gelöscht, um Platz zu schaffen. Danach passen Deskriptor und Delta-Datei nicht mehr zusammen, und die VM meldet beim Start, die übergeordnete virtuelle Festplatte sei verändert worden.
Die Daten sind bei diesem Problem in aller Regel vollständig vorhanden. Verloren geht der aktuelle Stand erst, wenn Delta-Dateien gelöscht oder überschrieben werden. Deshalb steht am Anfang jeder Bearbeitung eine Kopie und nicht der Versuch, die Kette am Original zu richten.
Ältere VMFS-Stände und ESXi-Versionen
Der Bestand an VMware-Umgebungen ist uneinheitlich, und das ist im Schadensfall relevant. Für die Rekonstruktion zählen drei Punkte:
- ESXi 7.0 ist seit Oktober 2025 aus dem Support. Viele dieser Hosts laufen weiter, bekommen aber keine Korrekturen mehr.
- Ab Version 9.0 heißt das Produkt wieder ESX, nicht mehr ESXi. Das ist eine Umbenennung, keine neue Produktlinie; für die Datenrettung ändert sich dadurch nichts.
- Ein VMFS-5-Datenspeicher lässt sich nicht auf VMFS-6 aktualisieren. Wer umsteigen will, muss einen neuen Datenspeicher anlegen und die Maschinen verschieben. Deshalb sind auch 2026 noch viele VMFS-5-Volumes im Einsatz, teils mit einer Partitionierung aus VMFS-3-Zeiten.
Für die Datenwiederherstellung ist die Version des Hypervisors zweitrangig. Wir bearbeiten VMware-Systeme von ESXi 5.5 an aufwärts, ebenso ESXi 6.5, ESXi 6.7, ESXi 7 und ESXi 8, und ebenso die als ESX 9 ausgelieferten Stände. Entscheidend ist nicht, welche Fassung lief, sondern welcher Schaden vorliegt und was seit dem Datenverlust am System gemacht wurde.
In der Praxis erreichen uns Datenverluste aus allen diesen Ständen. Ein ESX 9 verhält sich beim Speicher wie ein ESXi 8, und ein ESXi 6.7 legt seine VMDK-Dateien genauso ab wie ein ESXi 7. Was sich zwischen den Versionen unterscheidet, ist die Verwaltung, nicht der Aufbau des Datastores.
Erhöhtes Risiko tragen zwei Gruppen: Umgebungen, die auf einem alten Stand eingefroren wurden, und Umgebungen mitten in der Migration, etwa nach Proxmox VE. Im ersten Fall fehlen Korrekturen, im zweiten ist die Sicherungskette noch nicht eingespielt. Für die Analyse ist deshalb wichtig, welche Version zuletzt lief und ob ein Umzug im Gange war.
Wenn RAID, SAN oder Storage ausgefallen sind
Bei VMware liegt der Datastore fast immer auf einem RAID-Verbund im Server. Deshalb benötigen wir in aller Regel die physischen Datenträger dieses Verbundes, nicht einzelne Dateien und nicht eine Kopie des Datenspeichers. Erst aus den Originalen lässt sich der Verbund und darauf das Dateisystem für die Datenrettung rekonstruieren. Wie das im Detail abläuft, steht auf unserer Seite zur RAID-Datenrettung.
Je nach Schaden setzt die VMware-Datenrettung auf mehreren Ebenen an, und zwar immer von unten nach oben:
- Physischer Datenträger und RAID-Verbund: defekte Festplatten werden zuerst gesichert, dann wird der Verbund rekonstruiert
- VMFS-Datenspeicher: Partitionstabelle, LVM-Kopf und Metadaten des Dateisystems
- VMDK und Snapshot-Kette: Deskriptor, Datendatei und Delta-Dateien in der richtigen Reihenfolge
- Gast-Dateisystem: NTFS, ext4 oder VMFS-fremde Formate innerhalb der virtuellen Festplatte
- Nutzdaten: Datenbanken, Postfächer und Dateien, die am Ende zurückgehen
Diese Reihenfolge ist der Grund, warum eine professionelle VMware-Datenrettung mehr leistet als eine Reparatur im laufenden System oder ein einfacher Restore. Ein Restore setzt voraus, dass die Ebenen darunter stimmen. Genau das ist im Schadensfall nicht gegeben.
Lokaler Verbund, SAN oder vSAN
Wo der Datastore liegt, bestimmt, was wir brauchen. Bei einem lokalen RAID-Verbund im ESXi-Host sind es die Festplatten dieses Verbundes. Bei einem SAN über iSCSI oder Fibre Channel liegt der Datenspeicher auf einem eigenen Speichersystem, und der Ausfall trifft häufig mehrere Hosts gleichzeitig.
In vSAN-Clustern verteilt vSphere die Daten über die Datenträger mehrerer ESXi-Hosts. Erscheint eine VM als nicht erreichbar oder verwaist, fehlt ein Replikat oder die Mehrheit der Stimmen. Nennen Sie uns in diesem Fall die Zahl der Knoten und den Zustand der Komponenten, bevor am Cluster etwas verändert wird.
Was wir für die Analyse brauchen
- Alle Festplatten des Verbundes, auch die scheinbar heilen, mit Beschriftung der Position
- Angabe zu Controller, RAID-Ebene und Datenspeichergröße, soweit bekannt
- Den Wortlaut der Meldung und den Zeitpunkt des Datenverlusts
- Was seit dem Datenverlust unternommen wurde, besonders Reparatur- und Neuaufbauversuche
Einzelne Dateien oder eine Kopie des Datenspeichers reichen nicht. Bei einem SAN oder einem Speichersystem mit eigenem Controller nennen Sie uns zusätzlich Hersteller und Modell, damit wir die Anbindung einordnen können. Details zur Ebene darunter stehen auf der Seite zur RAID-Datenrettung.
In Unternehmen hängt an einem VMware-Server selten nur ein System. Dateiserver, Warenwirtschaft, Terminalserver und Datenbanken laufen als einzelne VMs auf demselben Datastore. Ein Datenverlust auf dieser Ebene legt den Betrieb still, und die Datenwiederherstellung wird zur Frage von Stunden. Auf Server-Datenrettung steht, wie wir mit Systemen von Dell, HPE und Lenovo umgehen.
Praxisfall: ein übersehener Plattenausfall
Ausgangslage. Ein mittelständisches Unternehmen betreibt Dateiserver, Warenwirtschaft und Terminalserver als fünf VMs auf einem ESXi-Host. Der Datastore liegt auf einem RAID 5 aus vier Festplatten im Server. Der zuständige Administrator ist im Urlaub, die Vertretung übernimmt für zwei Wochen.
Schaden. Der Controller meldet den Ausfall einer Festplatte. Die Meldung landet in einem Sammelpostfach, das in der Vertretung niemand liest. Zwölf Tage später fällt eine zweite Platte aus. Der Datastore verschwindet, alle fünf Maschinen stehen gleichzeitig.
Ursache. Ein RAID 5 verkraftet den Ausfall einer Festplatte, nicht den einer zweiten. Damit ist der Verbund unvollständig und das VMFS darüber nicht mehr einzubinden. Der eigentliche Fehler lag zwei Wochen vorher: Die erste Meldung wurde nicht bemerkt.
Vorgehen. Die Vertretung startet den Host neu und lässt den Controller einen Rebuild versuchen, der abbricht. Danach kommen alle vier Festplatten zu uns. Nach der sektorweisen Kopie jeder Platte wird der Verbund rekonstruiert, darauf das VMFS und daraus die VMDK-Dateien der fünf Maschinen.
Ergebnis. Alle fünf VMs ließen sich wiederherstellen. Bei zweien war der abgebrochene Rebuild bereits über Teile der VMDK gelaufen; diese Bereiche wurden von Hand rekonstruiert, was den Auftrag um zwei Tage verlängert hat. Ohne den Rebuild wäre die Datenrettung deutlich schneller abgeschlossen gewesen.
- Eigenes Reinraumlabor & Ersatzteillager
- 95% Datenrettungsgarantie
- Qualitätssicherung nach ISO 9001:2015
- Diskretion & Datenschutz nach DSGVO
- Persönlicher Ansprechpartner
Datenrettung anfragen
So läuft die VMware-Datenrettung ab
Vor jedem Angebot steht die Analyse der VMware-Umgebung. Sie ermittelt den technischen Zustand der Datenträger und des RAID-Verbundes, des VMFS-Datenspeichers, der VMDK-Dateien mit ihrer Snapshot-Struktur und des Dateisystems in der virtuellen Maschine. Erst danach lässt sich sagen, welcher Aufwand nötig ist und welcher Datenstand erreichbar bleibt.
Die eigentliche VMware-Datenrettung läuft danach ausschließlich an einer sektorweisen Kopie. Das Original wird nach dieser Kopie nicht mehr angefasst, damit ein zweiter Anlauf jederzeit möglich bleibt. Welche Wiederherstellungsoptionen bestehen und welcher Datenstand erreichbar ist, steht im Befund der Analyse und nicht in einer Zusage vorab.
So läuft die VMware-Datenrettung ab
Wie lange eine VMware-Datenrettung dauert, hängt an der Zahl der Datenträger im Verbund und am Zustand der Hardware. Sind die Festplatten lesbar, liegt der Schwerpunkt auf der Rekonstruktion von Verbund, Dateisystem und Snapshot-Struktur. Ist Hardware defekt, kommt die sektorweise Kopie hinzu, und sie bestimmt dann die Dauer. Für dringende Fälle arbeiten wir im 24h-Express, auch am Wochenende.
Analyse, Kosten und häufige Fragen
Den Preis einer VMware-Datenrettung nennen wir nach der Analyse als Festpreis, und er ändert sich danach nicht mehr. Er richtet sich nach dem Schadensbild, nicht nach der Menge der Daten: Ein gerissener Kettenverbund bei intakten Datenträgern ist deutlich schneller erledigt als ein Datenspeicher auf einem RAID mit mehreren defekten Laufwerken. Die Abholung ist für Sie kostenfrei, die telefonische Erstberatung ebenfalls.
- Welche Ebene betroffen ist: Datenträger, RAID, VMFS, VMDK oder Gastsystem
- Welche VMs vollständig, teilweise oder nicht lesbar sind
- Welcher Datenstand erreichbar ist, bei Snapshots mit Zeitpunkt
- Wie lange die Wiederherstellung voraussichtlich dauert
- Den Festpreis, zu dem wir die Datenrettung durchführen
Aus diesem Befund ergeben sich die Wiederherstellungsoptionen. Häufig gibt es mehrere: die komplette VM wiederherzustellen, nur einzelne Datenbanken aus dem Gastsystem wiederherzustellen, oder einen älteren Stand aus der Snapshot-Kette zu nehmen, wenn der aktuelle nicht mehr vollständig ist. Welche Option für Sie die richtige ist, entscheiden Sie nach der Analyse; wir sagen dazu, was jede Variante an Zeit kostet.
Wenn das Backup nicht greift
Die meisten Unternehmen, die uns mit einem VMware-Datenverlust erreichen, haben ein Backup. Es hilft nur nicht: Die Sicherung lief auf denselben Datenspeicher, sie war seit Wochen fehlerhaft, oder sie erfasst die virtuellen Maschinen im laufenden Betrieb und damit in einem inkonsistenten Zustand. Häufig fehlt auch genau der Zeitraum, um den es geht.
Ein vorhandenes Backup schließt eine Datenrettung nicht aus, sondern ergänzt sie: Alte Backups und ein wiederhergestellter aktueller Stand schließen zusammen die Lücke. Sagen Sie uns deshalb bei der Anfrage, welchen Zeitpunkt Ihre Sicherung abdeckt.
In vielen Fällen ja. Für Administratoren ist oft nicht nachvollziehbar, warum eine virtuelle Festplatte plötzlich fehlt. Wir benötigen dafür immer die originalen Datenträger aus dem RAID-Verbund unter dem Datenspeicher. Einzelne Dateien oder Ordner reichen nicht, weil die Zuordnung erst aus dem Verbund entsteht.
Nichts erzwingen. Diese Meldung entsteht, wenn die Kennung des Volumes nicht mehr zur erwarteten passt, etwa nach einem Controllertausch oder einer geänderten LUN-Nummer. Ein Neusignieren scheint zu helfen, verändert aber Metadaten. Sichern Sie den Zustand und lassen Sie ihn prüfen, bevor Sie ihn verändern.
Das ist der klassische Kettenbruch: Deskriptor und Delta-Datei passen nicht mehr zusammen, meist nach Kopieren, Verschieben oder einem abgebrochenen Zusammenführen. Die Daten sind in aller Regel vollständig vorhanden. Löschen Sie auf keinen Fall Delta-Dateien, um die Maschine zum Start zu bewegen.
Ja. Wir unterstützen alle Versionen des Hypervisors, auch ältere Stände, die längst aus dem Support gefallen sind. Entscheidend ist nicht die Version, sondern der Schadensverlauf. Schildern Sie diesen bei der Anfrage möglichst genau.
Das hängt vom System, der Zahl der Datenträger im Verbund und dem Schaden ab. Nach einer Express-Analyse können wir in der Regel binnen 24 Stunden eine belastbare Aussage treffen. Häufig erfolgt bereits währenddessen ein Großteil der Wiederherstellung, sodass die Rückgabe innerhalb von 24 bis 48 Stunden möglich ist.
Ohne Kenntnis der Umgebung und des Schadens lässt sich das nicht seriös beziffern. Durch die Komplexität des Dateisystems liegt der Aufwand meist höher als bei nicht virtualisierten Systemen; im Durchschnitt bewegen sich VMware-Aufträge im vierstelligen Bereich. Nach der Analyse erhalten Sie ein Festpreisangebot und entscheiden erst dann.
Ja. vCenter und vSphere sind die Verwaltung, nicht der Speicher. Fällt die Verwaltung aus, liegen die virtuellen Maschinen weiterhin auf dem Datastore. Für die Datenwiederherstellung brauchen wir den Datenträger unter dem Datastore, nicht einen laufenden ESXi-Host. Installieren Sie in dieser Lage nichts neu, denn eine Neuinstallation kann die Partition des Datastores überschreiben.
Bei einem intakten Dateisystem lesen solche Tools den Datastore durchaus. Bei beschädigten Metadaten fehlt ihnen genau die Funktion, die gebraucht wird, und das Ergebnis sind Bruchstücke ohne Zusammenhang. Dazu kommt das Risiko, dass Recovery-Software ihre Zwischenstände auf denselben Datenträger schreibt und damit Probleme erzeugt, die vorher nicht bestanden.
RecoveryLab arbeitet seit 2004 an Datenverlusten und bearbeitet VMware-Systeme aus Unternehmen und Behörden, vom einzelnen ESXi-Host mit lokalem RAID bis zum Server am SAN. Aus dieser Erfahrung stammt die Reihenfolge, mit der wir arbeiten: erst der Datenträger, dann der Verbund, dann das Dateisystem, dann die VMDK.
Sofort ausschalten und nichts weiter schreiben. Eine Neuinstallation legt eine neue Partition an und kann den Anfang des Datastores überschreiben. Ob der Datenverlust damit endgültig ist, hängt davon ab, wie viel danach geschrieben wurde. In vielen Fällen liegen die VMDK-Dateien noch dahinter und lassen sich wiederherstellen.
Ihre VMware-Umgebung gibt keine Daten mehr frei? Nennen Sie uns die Meldung im Wortlaut, den Aufbau des Speichers und was seit dem Datenverlust unternommen wurde. Wir sagen Ihnen, was jetzt sinnvoll ist. Für dringende Fälle steht der 24h-Express-Service bereit, auch am Wochenende.
