Eine virtuelle Maschine startet nicht mehr, ein Sicherungspunkt lässt sich nicht zurücknehmen, oder der Ordner der VM ist verschwunden: Bei der VirtualBox Datenrettung stellen wir virtuelle Festplatten im Format VDI wieder her, ebenso VMDK, VHD und HDD aus einer Umgebung mit Oracle VirtualBox. Wir arbeiten ausschließlich an einer Kopie, nie am Original.
- Gelöschte oder nicht mehr registrierte virtuelle Maschinen
- Unterbrochene Ketten aus Basisabbild und Differenzabbildern
- Beschädigte Beschreibungsdateien mit der Endung vbox
- Fehlgeschlagenes Zusammenführen von Sicherungspunkten
- Dateisystemschäden im Gastsystem, etwa NTFS oder ext4
- Ausgefallene Datenträger des Wirtssystems, auch im RAID-Verbund
Nach der Analyse erhalten Sie ein Festpreisangebot. Die Abholung ist kostenfrei, die telefonische Erstberatung ebenfalls. RecoveryLab rettet Daten seit 2004, im eigenen Labor in Leipzig.
Erste Hilfe bei ausgefallenen VirtualBox-Systemen
Was in den ersten Minuten geschieht, entscheidet über den Aufwand der späteren Datenrettung. Diese Schritte erhalten den Zustand, in dem Ihre Daten noch erreichbar sind:
- Die VM nicht erneut starten. Jeder Start schreibt in das oberste Differenzabbild und überschreibt Blöcke, die für die Wiederherstellung noch gebraucht werden.
- Keine Sicherungspunkte löschen oder zusammenführen. Bricht dieser Vorgang ab, ist die Kette an genau dieser Stelle unterbrochen.
- Die Dateien im VM-Ordner nicht verändern. Dazu gehören die Datei mit der Endung vbox, ihre Sicherheitskopie vbox-prev und die Abbilder selbst.
- Auf dem Host nichts mehr schreiben, wenn dort Dateien gelöscht wurden. Auch ein Neustart und jede Installation legen neue Daten an.
- Keine Datenwiederherstellungssoftware am Original starten und den Datenträger nicht formatieren oder reparieren lassen.
- Bei Klackern oder Schleifen das Gerät ausschalten. Ein mechanischer Schaden verschlimmert sich mit jeder Minute Betrieb.
Ist die VM bereits mehrfach gestartet worden, ist der Fall damit nicht verloren. Er wird aufwendiger, und wir brauchen genauere Angaben darüber, was seit dem Datenverlust auf dem Gerät passiert ist. Schildern Sie uns das Schadensbild am Telefon, die Erstberatung kostet nichts.
Was danach noch möglich ist, klärt die Analyse. In den meisten Fällen lässt sich eine VirtualBox-Maschine vollständig wiederherstellen, solange der Datenträger darunter sicher liest und niemand die Abbilder überschrieben hat.
Typische Ursachen für Datenverlust in VirtualBox
Fast jeder Fall, der unter dem Stichwort VirtualBox bei uns eingeht, gehört zu einer der folgenden Gruppen. Welche es ist, verrät oft schon die Meldung, die beim Start erscheint:
| Was Sie sehen | Was meist dahintersteckt | Aussicht für die Daten |
|---|---|---|
| VirtualBox meldet, ein Datenträger werde nicht gefunden | Ein Differenzabbild fehlt, die Kette ist unterbrochen | Hängt davon ab, welche Abbilder noch vorhanden sind |
| Die Maschinenliste ist leer | Die Registrierung fehlt, die Dateien liegen noch da | Meist vollständig, oft ohne Datenrettung |
| Schwarzer Bildschirm, kein Startvorgang | Bootsektor oder Bootdateien im Gastsystem überschrieben | Nutzdaten meist vollständig lesbar |
| Bluescreen kurz nach dem Start | Beschädigtes Dateisystem im Gastsystem | Nutzdaten meist vollständig lesbar |
| Die VM lässt sich gar nicht mehr öffnen | Die Beschreibungsdatei mit der Endung vbox ist unvollständig | Gut, die Nutzdaten liegen nicht in dieser Datei |
| Der Host erkennt sein Laufwerk nicht mehr | Defekte Festplatte, SSD oder ein RAID-Verbund im Fehlerzustand | Zuerst muss der Datenträger gesichert werden |
Diese Warnzeichen sehen wir am häufigsten
- Die VM startet nicht mehr oder bleibt beim Startvorgang stehen
- VirtualBox meldet einen fehlenden Datenträger
- Ein Sicherungspunkt lässt sich nicht mehr zurücknehmen
- Der Ordner der VM ist verschwunden oder wurde verschoben
- Das Wirtssystem erkennt seine Festplatte oder SSD nicht mehr
- Ein RAID-Verbund steht im Fehlerzustand
Was daraus für Ihre Daten folgt
- Die Nutzdaten liegen im Abbild, nicht in der Beschreibungsdatei
- Ein fehlendes Glied kostet einen Zeitraum, nicht die ganze VM
- Gelöschte Abbilder bleiben lesbar, solange nichts überschrieben wird
- Ein defekter Datenträger wird zuerst kopiert, dann gelesen
- Jeder weitere Startversuch verkleinert die Aussichten
- Die Analyse sagt vor dem Angebot, was erreichbar ist
Snapshot-Kette unterbrochen
Ein Differenzabbild wurde verschoben, umbenannt oder gelöscht. Das Basisabbild ist dann meist unversehrt, zeigt aber nur den Zustand vor dem ersten Sicherungspunkt. Alles, was seither in der VM passiert ist, steckt in den fehlenden Gliedern.
Der häufigste Auslöser ist das Aufräumen. Wer einen Sicherungspunkt löscht, stößt ein Zusammenführen an: Oracle VirtualBox schreibt die Differenz in das darunterliegende Abbild. Geht dabei der Plattenplatz aus oder fällt der PC aus, bleiben beide Abbilder in einem inkonsistenten Zustand zurück. An dieser Stelle entscheidet, dass nicht weiter geschrieben wird.
Für die Datenrettung ist diese Gruppe die dankbarste. Solange die einzelnen Abbilder als Dateien vorhanden sind, lässt sich die Kette an einer Kopie neu zusammensetzen und die VM anschließend wiederherstellen. Sind Glieder gelöscht, suchen wir sie auf dem Laufwerk des Hosts, bevor irgendetwas anderes geschieht.
Beschreibungsdatei beschädigt oder VM nicht registriert
Die Datei mit der Endung vbox ist eine XML-Datei. Bricht ein Schreibvorgang ab, ist sie unvollständig; ist zusätzlich die Sicherheitskopie vbox-prev betroffen, wird der Fall aufwendiger, bleibt aber bearbeitbar. Die Nutzdaten liegen in den Abbildern, nicht in dieser Datei.
Der harmlosere Verwandte: Nach einer Neuinstallation des Betriebssystems zeigt Oracle VirtualBox eine leere Liste, die Maschinenordner liegen noch auf dem Datenträger. Der Stammordner zeigt dann meist wieder auf das Benutzerprofil, während die alten VMs auf einem zweiten Laufwerk geblieben sind. Wer im Explorer nur unter dem neuen Pfad nachsieht, hält seine Maschinen für verloren, obwohl sie vollständig vorhanden sind.
Gastsystem startet nicht mehr
Häufig sind die Containerdateien vollständig und die VM startet trotzdem nicht. Im Gastsystem gilt dieselbe Technik wie auf einem echten PC: Ist der Bootsektor überschrieben oder fehlen die Bootdateien, findet die Maschine nichts zum Starten. Bei NTFS trifft es meist die Master File Table, bei ext4 das Journal; daraus entstehen die Bluescreens mit dem Hinweis auf eine unlesbare Systemdatei.
Die Nutzdaten liegen dabei unversehrt im Dateisystem. Wir binden das Abbild schreibgeschützt ein und lesen das Gastdateisystem an einer Kopie neu auf. Bootdateien lassen sich später neu anlegen, überschriebene Nutzdaten nicht.
Wichtig ist die Unterscheidung: Fehlende Bootdateien sind ein Schaden am Startvorgang, ein Bluescreen dagegen kann beides bedeuten. Bluescreens mit dem Hinweis auf eine Systemdatei entstehen im Gastsystem, Bluescreens direkt nach dem Laden der Bootdateien deuten eher auf ein beschädigtes Abbild. Ob Bootdateien fehlen oder das Abbild selbst beschädigt ist, ändert für die Datenrettung wenig, für Ihre Einschätzung am Telefon aber hilfreich.
Altsysteme wie Windows XP in VirtualBox
VirtualBox ist der übliche Weg, ein XP am Leben zu halten, an dem eine Maschinensteuerung oder eine alte Fachanwendung hängt. Für solche VMs gibt es keine zweite Installation mehr: Das Medium ist verschwunden, der Hersteller der Software existiert nicht mehr, die Lizenz hängt am Namen des Rechners. Ein Schaden an einer XP-Maschine ist deshalb regelmäßig teurer als einer am Server daneben, obwohl die VDI eines XP selten größer als zwanzig Gigabyte ist.
Bei diesen Maschinen lohnt der Blick auf die Gasterweiterungen. Daten, die über einen gemeinsamen Ordner der Gasterweiterungen erreichbar waren, liegen physisch auf dem Host, nicht im Abbild. Wer nach einem Datenverlust nur die VDI sucht, sucht dann an der falschen Stelle.
Abgebrochene Umwandlung aus VMware oder Hyper-V
Oracle VirtualBox bindet eine VMDK aus VMware direkt ein, eine VHDX aus Hyper-V dagegen nicht: Sie muss vorher in ein VDI oder eine VMDK umgewandelt werden. Jede Umwandlung braucht den doppelten Plattenplatz, weil Quelle und Ziel gleichzeitig bestehen.
Genau daran scheitern die Vorgänge, meist nachts. Zurück bleibt eine halb geschriebene Zieldatei, und wenn die Quelle zu diesem Zeitpunkt bereits gelöscht war, fehlt beides. Dann gilt: die unvollständige Datei nicht löschen und auf dem Laufwerk nichts mehr schreiben, damit die gelöschte Quelle auffindbar bleibt.
Welches Format aus welcher Richtung kommt, entscheidet über den Aufwand:
- VMDK aus VMware: bindet VirtualBox direkt ein, ist aber oft in mehrere Dateien geteilt. Fehlt eine davon, ist die virtuelle Festplatte unvollständig, auch wenn die größte Datei intakt aussieht.
- VHD der älteren Microsoft-Generation: wird direkt gelesen, eine Umwandlung ist nicht nötig.
- VHDX aus Hyper-V: wird nicht unterstützt und muss umgewandelt werden. Genau hier brechen die Vorgänge ab.
Bei einer abgebrochenen Umwandlung sind je nach Zeitpunkt beide Dateien brauchbar: die Quelle ganz, das Ziel teilweise. Wir lesen VMDK, VHD und VHDX genauso aus wie ein VDI und setzen die virtuelle Festplatte aus dem zusammen, was von beiden Seiten lesbar ist. Eine Umwandlung sollte deshalb nie der letzte verbliebene Stand einer Maschine sein.
Eigene Versuche mit Datenwiederherstellungssoftware
Die naheliegende Reaktion auf eine verschwundene VDI ist ein Programm zur Datenrettung. Bei einer einzelnen gelöschten Datei auf einem intakten Laufwerk kann das gut gehen. Bei virtuellen Maschinen geht es meist schief, und zwar aus drei Gründen:
- Die Größe. Ein Abbild ist zwanzig, hundert oder fünfhundert Gigabyte groß. Datenwiederherstellungssoftware setzt große Dateien häufig aus Bruchstücken zusammen. Im Explorer sieht das Ergebnis vollständig aus, in der VM ist es unbrauchbar.
- Der Zielort. Wird das Ergebnis auf denselben Datenträger geschrieben, überschreibt der Vorgang genau die Blöcke, die noch gebraucht werden. Jeder weitere Versuch verschlechtert die Ausgangslage.
- Die Kette. Ein Programm kennt den Zusammenhang zwischen Basisabbild und Differenzabbildern nicht. Es findet Dateien, keine Strukturen. Genau diese Struktur ist aber das, was fehlt.
Bei defekter Hardware kommt hinzu, dass jede Software das Laufwerk unter Dauerlast setzt. Eine defekte Festplatte mit beginnendem Schaden an den Schreib-Leseköpfen übersteht das selten lange. Wir setzen dieselben Verfahren durchaus ein, nur unter anderen Bedingungen: an einer Kopie, mit Kenntnis der gesuchten Struktur und erst, wenn das Speichermedium stabil liest.
Der Unterschied wird am Bildschirm sichtbar. Ein Programm, das am PC im laufenden Betrieb sucht, zeigt nach Stunden ein Fenster mit tausenden Fundstücken. Welche davon zu einer VM gehören, sieht man dem Fenster nicht an, und im Explorer wirken auch unbrauchbare Bruchstücke vollständig. Wer mehrere solcher Versuche unternimmt, verliert vor allem Zeit.
Am PC des Kunden endet das oft so: mehrere Versuche mit Datenwiederherstellungssoftware, ein Fenster voller Fundstücke, und an der entscheidenden Stelle fehlt trotzdem die VM. Rufen Sie an, bevor Sie diesen Weg gehen, die Einschätzung kostet nichts.
Datenwiederherstellungssoftware ist deshalb kein schlechtes Werkzeug, sondern das falsche für diesen Fall. Ein Programm sucht nach Dateien, nicht nach der Struktur einer virtuellen Festplatte. Wo Datenwiederherstellungssoftware auf einem intakten Laufwerk hilft, braucht eine VM die Rekonstruktion der Kette, und die setzt eine sichere Kopie voraus.
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 virtuellen Maschinen zählt dabei der Inhalt, nicht die Zahl der Dateien: Eine VDI, die sich öffnen lässt, deren Gastdateisystem aber leer bleibt, ist für uns kein Erfolg. Uns ist kein weiterer Anbieter bekannt, der sich in dieser Form festlegt.
Welche VirtualBox-Daten sich wiederherstellen lassen
Am Telefon kommt diese Frage zuerst. Die Antwort hängt an einer einzigen Bedingung, nämlich daran, ob die Blöcke noch auf dem Speichermedium stehen. Alles Weitere ist Handwerk.
- Vollständige VMs. Sind Basisabbild und alle Snapshots vorhanden, stellen wir die komplette Virtual Machine wieder her. Sie startet danach wieder in Oracle VirtualBox, mit derselben Konfiguration wie zuvor.
- Einzelne Daten aus dem Gast. Startet die Maschine nicht mehr, stellen wir die Daten aus dem Abbild wieder her: Datenbanken, Postfächer, Projektordner, einzelne Verzeichnisse.
- Gelöschte VMs. Wurde der Maschinenordner gelöscht, suchen wir die Containerdateien über ihre Signatur im Dateisystem des Hosts. Das gelingt umso besser, je weniger seither geschrieben wurde.
- Teilstände aus unterbrochenen Ketten. Fehlt ein Glied, ist der aktuelle Stand verloren, ein älterer aber meist nicht.
- Daten aus Fremdformaten. Eine VMDK oder eine VHDX, die unter Oracle VirtualBox lief oder laufen sollte, behandeln wir wie eine VDI.
Dateien aus Windows- und Linux-Gastsystemen
Für die meisten Kunden ist das der eigentliche Zweck: Die VM selbst ist ersetzbar, die Daten darin sind es nicht. Das Gastdateisystem wird dafür an einer Kopie eingebunden, nie im laufenden Betrieb.
Aus einem Windows-Gast
- Nutzerprofile mit Dokumenten und Desktop
- Datenbanken der Warenwirtschaft und Buchhaltung
- Postfächer aus Outlook und Exchange
- Anwendungsdaten unter ProgramData und AppData
Aus einem Linux-Gast
- Verzeichnisse unter home, var und srv
- Datenbanken aus MySQL, MariaDB und PostgreSQL
- Webverzeichnisse und Konfigurationen unter etc
- Container- und Anwendungsdaten
Ist eine Datei im Gastsystem nur gelöscht, gilt dort dasselbe wie auf einem echten Datenträger: Der Verzeichniseintrag fehlt, die Blöcke stehen zunächst noch. Wird die VM danach weiter betrieben, überschreibt das Gastsystem sie nach und nach. Auch deshalb sollte eine betroffene Maschine ausgeschaltet bleiben.
Welches Betriebssystem im Gast läuft, ändert am Vorgehen wenig. Ein Windows-Gast bringt NTFS mit, ein Linux-Gast ext4 oder XFS, ein altes XP ebenfalls NTFS, nur in einer älteren Fassung. Alle drei lesen wir an der Kopie aus. Aus einem XP holen wir regelmäßig genau die eine Datenbank, an der eine Fachanwendung hängt.
Daten aus unterbrochenen Snapshot-Ketten
Fehlt ein Differenzabbild, rechnen wir den Zustand aus den vorhandenen Gliedern zusammen und stellen offen dar, welcher Zeitraum fehlt. In vielen Fällen liegt das gesuchte Dokument in einem älteren Glied und ist damit vollständig wiederherstellbar, auch wenn der letzte Arbeitstag nicht mehr erreichbar ist.
Nicht wiederherstellen lässt sich, was überschrieben wurde. Ein Differenzabbild, über das eine Installation gelaufen ist, ist weg, und daran ändert kein Verfahren etwas. Was wiederhergestellt wurde, prüfen wir vor der Rückgabe: Eine wiederhergestellte VM wird einmal gestartet, wiederhergestellte Datenbanken werden geöffnet.
VDI, VMDK, Snapshots und beschädigte virtuelle Festplatten
Eine VM in VirtualBox besteht nicht aus einer einzigen Datei. Im Stammordner für virtuelle Maschinen legt Oracle VirtualBox je Maschine einen eigenen Ordner an, benannt nach dem Namen der VM. Darin liegen die Beschreibungsdatei, das Basisabbild der virtuellen Festplatte und ein Unterordner mit den Sicherungspunkten. Erst zusammen ergeben diese Dateien den aktuellen Zustand.
Die Abbilder selbst sind Containerdateien. Der Name VDI steht für Virtual Disk Image, und genau das ist es: eine Datei, die eine ganze Festplatte enthält. Ein VDI mit dynamischer Größe belegt nur den tatsächlich beschriebenen Plattenplatz und wächst mit, ein Abbild mit fester Größe belegt seinen Platz sofort. Für die Datenrettung ist der Unterschied erheblich: Bei fester Größe liegen die Blöcke der Reihe nach, bei dynamischer Größe verstreut über die Datei, und ihre Reihenfolge steht in einer Zuordnungstabelle am Anfang.
| Bestandteil | Datei | Was darin steckt |
|---|---|---|
| Beschreibungsdatei | Name.vbox | XML mit der Konfiguration der VM, der Reihenfolge der Abbilder und den UUID der Datenträger |
| Sicherheitskopie | Name.vbox-prev | Der vorherige Zustand der Beschreibungsdatei, oft die Rettung |
| Basisabbild | Name.vdi | Der Zustand vor dem ersten Sicherungspunkt, dynamisch wachsend oder mit fester Größe |
| Differenzabbilder | Snapshots/{UUID}.vdi | Je Sicherungspunkt die seither geänderten Blöcke, verkettet mit dem Vorgänger |
| Zustandsdateien | Snapshots/{UUID}.sav | Der eingefrorene Arbeitsspeicher, wenn die VM im laufenden Zustand gesichert wurde |
| Protokoll | Logs/VBox.log | Zeigt, welche Dateien die VM zuletzt geöffnet hat, und ist für die Analyse oft der schnellste Weg |
Jedes Abbild trägt eine UUID. Die Beschreibungsdatei verweist über diese Kennung auf die Datei, nicht über deren Namen. Sie führt je Abbild einen Harddisk-Eintrag mit Pfad, Format und UUID; aus diesen Einträgen ergibt sich die Kette.
Wer ein Abbild kopiert und die Kopie zusätzlich registriert, erzeugt eine zweite Harddisk mit derselben UUID, und Oracle VirtualBox verweigert die Arbeit. Ist die Konfiguration beschädigt, die Harddisk-Einträge aber lesbar, lässt sich eine VM in aller Regel vollständig wiederherstellen.
Basisabbild, Differenzabbilder und die Kette dazwischen
Ein Sicherungspunkt, in der englischen Oberfläche Snapshot genannt, friert den Zustand einer Virtual Machine ein. Oracle VirtualBox schreibt danach nicht mehr in das Basisabbild, sondern legt ein Differenzabbild an. Jeder weitere Snapshot hängt ein Glied an die Kette. Der Zustand, den Sie zuletzt gesehen haben, ergibt sich erst aus allen Gliedern zusammen.
Das ist der Grund, warum das Sichern des Basisabbilds allein nichts nützt. Wir bekommen regelmäßig eine einzelne VDI mit der Bitte, daraus die Buchhaltung des letzten Jahres wiederherzustellen, während die Snapshots mit genau diesen Daten auf dem formatierten Laufwerk geblieben sind. Wer eine virtuelle Festplatte sichert, muss die Snapshots mitnehmen.
| Vorgang | Was mit den Dateien geschieht | Worauf es ankommt |
|---|---|---|
| Sicherungspunkt anlegen | Das bisherige Abbild wird schreibgeschützt, ein neues Differenzabbild entsteht | Der Plattenplatz muss für die Differenz reichen |
| Sicherungspunkt zurücknehmen | Das oberste Differenzabbild wird verworfen | Alles seit dem Snapshot ist damit weg |
| Sicherungspunkt löschen | Die Differenz wird in das darunterliegende Abbild geschrieben | Bricht der Vorgang ab, ist die Kette inkonsistent |
| VM klonen | Die Kette wird zu einem Abbild zusammengerechnet | Der Klon braucht so viel Plattenplatz wie die Summe der Abbilder |
Snapshots sind kein Backup
Sicherungspunkte liegen auf demselben Speichermedium wie das Basisabbild. Fällt die Festplatte des Hosts aus, sind beide gemeinsam betroffen. Ein Sicherungspunkt ersetzt deshalb kein Backup, und der Wiederherstellungspunkt von Windows im Gastsystem erst recht nicht: Der sichert Einstellungen, keine Nutzdaten, und liegt im selben Abbild.
Ein Backup ist eine Kopie auf einem anderen Gerät. Es umfasst den ganzen Maschinenordner, nicht nur die VDI, und es erfasst die VM im angehaltenen Zustand oder nach einem gesetzten Sicherungspunkt. Backups einer laufenden Maschine erfassen sonst einen inkonsistenten Zustand. Bei vielen Aufträgen, die uns erreichen, war ein Backup durchaus vorhanden. Es war nur unvollständig, veraltet oder als System nicht mehr lesbar.
Auch alte Backups sind wertvoll. Ein Backup von vorgestern und ein wiederhergestellter Stand von heute schließen zusammen die Lücke, die keiner von beiden allein schließt. Sagen Sie uns deshalb, welchen Zeitpunkt Ihre Backups abdecken. Wir richten die Wiederherstellung dann auf den Zeitraum aus, der fehlt.
Ein Wiederherstellungspunkt im Gastsystem hilft dabei nicht weiter. Er gehört zu Windows, sichert Systemeinstellungen und liegt in derselben Datei wie alles andere. Wer sich auf einen Wiederherstellungspunkt verlässt, hat nicht die VM gesichert, sondern nur ihre Einstellungen.
Für die Praxis heißt das:
- Den ganzen Maschinenordner sichern, nicht nur die VDI
- Die VM vorher anhalten oder einen Sicherungspunkt setzen
- Auf ein Gerät schreiben, das nicht dauerhaft am Host hängt
- Zusätzlich im Gastsystem sichern, für einzelne Dateien
- Die Wiederherstellung einmal im Jahr ausprobieren
VDI, VMDK, VHD, VHDX und HDD
Oracle VirtualBox bindet mehr als sein eigenes Format ein. Welches Format vorliegt, entscheidet mit darüber, wie ein beschädigtes Abbild gelesen wird:
| Format | Herkunft | Rolle in VirtualBox |
|---|---|---|
| VDI, Virtual Disk Image | Oracle VirtualBox | Das eigene Format, dynamisch wachsend oder mit fester Größe |
| VMDK, Virtual Machine Disk | VMware | Wird gelesen und geschrieben, auch als Satz geteilter Dateien |
| VHD, Virtual Hard Disk | Microsoft, ältere Generation | Wird gelesen und geschrieben |
| VHDX | Microsoft Hyper-V, aktuelle Generation | Wird nicht unterstützt, eine VHDX muss vorher umgewandelt werden |
| HDD | Parallels, ältere Versionen | Wird gelesen |
| QCOW2 | KVM, QEMU und Proxmox VE | Wird nicht unterstützt, Umwandlung nötig |
- Gastsysteme mit NTFS, ReFS und ext4, dazu ext2, ext3, XFS, Btrfs und APFS
- Windows von XP bis Windows 11, Linux in allen verbreiteten Ausgaben, macOS und BSD als Gast
- Wirtssysteme unter Windows, Linux und macOS, auch auf verschlüsselten Laufwerken
- Abbilder auf Festplatten und SSD, auf NAS und Server, auf RAID-Verbund, LVM, ZFS und Ceph
Ob sich ein beschädigtes Abbild lesen lässt, entscheiden vier Dinge:
Die englischen Namen sagen, worum es geht: Virtual Disk Image bei Oracle VirtualBox, Virtual Machine Disk bei VMware, Virtual Hard Disk bei Microsoft. Alle drei sind Containerdateien für eine virtuelle Festplatte, und alle drei lesen wir aus, gleich in welchem Zustand die Maschine darum herum ist.
- Wie viel der Containerdatei noch lesbar ist
- Ob die Zuordnungstabelle am Anfang der Datei intakt ist
- Ob alle Teile eines geteilten Abbildes vorliegen
- Welches Dateisystem im Gastsystem darin liegt
In der Praxis erreichen uns neben dem VDI vor allem VMDK und VHDX. Eine VMDK stammt fast immer aus einer VMware-Umgebung und läuft danach unter Oracle VirtualBox weiter; eine VHDX kommt aus Hyper-V und wurde für VirtualBox umgewandelt. Beide Formate lesen wir aus, auch wenn die Umwandlung nie fertig geworden ist. Für das Ergebnis zählt nicht, welches Format vorliegt, sondern wie viel von der Disk noch lesbar ist.
Aus Sicht der Datenrettung ist das Format zweitrangig. Ob eine VDI, eine VMDK aus VMware, eine VHD oder eine VHDX vorliegt, ändert die Werkzeuge, nicht das Vorgehen: Wir lesen die Disk sektorweise aus, bestimmen die Struktur der Disk und rekonstruieren das Dateisystem des Gastes. Auch eine VHDX, die Oracle VirtualBox selbst nie öffnen könnte, lässt sich so wiederherstellen.
Das gilt in beide Richtungen. Eine VMDK aus VMware, die in VirtualBox eingebunden war, lesen wir wie eine VMDK aus VMware selbst; eine VHDX aus Hyper-V bleibt eine VHDX, auch wenn sie zuletzt auf einem Notebook mit VirtualBox lag. Entscheidend ist nicht das Programm, das die Disk zuletzt geöffnet hat, sondern die Struktur in der Datei.
Liegt der Schaden nicht bei VirtualBox, sondern im Nachbarsystem, helfen die eigenen Seiten dazu weiter: VMware mit VMDK und VMFS, Hyper-V mit VHDX, Proxmox VE, KVM und QEMU sowie XCP-ng und Citrix Hypervisor. Den Überblick über die Datenrettung in virtualisierten Systemen gibt der Hub zu virtuellen Maschinen.
Wenn Host, Festplatte, SSD oder RAID ausgefallen sind
Die zweite große Gruppe hat mit VirtualBox selbst wenig zu tun: Die VM ist in Ordnung, das Speichermedium darunter nicht. Hier gilt eine feste Reihenfolge. Erst entsteht eine sektorweise Kopie der physischen Datenträger, dann beginnt die Arbeit an den Abbildern, nie umgekehrt. Alles andere setzt die Abbilder aufs Spiel, die noch zu retten wären.
Ein einzelnes Laufwerk ist betroffen
- Erst die sektorweise Kopie, dann die Abbilder
- Defekte Bereiche werden übersprungen und später erneut angefahren
- Die Dauer bestimmt die Kopie, nicht die Rekonstruktion
- Bei Geräuschen sofort ausschalten
Ein Verbund ist betroffen
- Alle Laufwerke des Verbundes werden gebraucht
- Kein Rebuild auf defekter Basis starten
- Die Ebene darunter wird zuerst rekonstruiert
- Erst danach werden die Abbilder gesucht
Defekte Festplatte oder SSD im Wirtssystem
Bei defekten Festplatten mit Schäden an der Oberfläche kommt die Kopie nur langsam voran, weil beschädigte Bereiche zunächst übersprungen und später gezielt erneut angefahren werden. Dieser Teil bestimmt die Dauer eines Auftrags, nicht die Rekonstruktion der Kette. Was dabei technisch geschieht, steht auf der Seite zur Festplatten-Datenrettung.
Bei einer ausgefallenen SSD liegt der Fall anders: Dort entscheidet der Controller darüber, ob die Blöcke überhaupt erreichbar sind. Für die Abbilder bedeutet beides dasselbe. Solange der Datenträger nicht stabil liest, hat kein Zugriff auf die VDI Sinn.
Abbilder auf RAID, NAS und Server
Liegen die Abbilder auf einem Netzwerkspeicher, brauchen wir alle Laufwerke des Verbundes. Ein NAS von Synology, QNAP oder Buffalo legt seine Daten über LVM oder Btrfs auf einem Software-RAID ab; diese Struktur lässt sich nur aus dem vollständigen Satz rekonstruieren. Eine einzelne Festplatte aus einem Synology- oder QNAP-Gehäuse ergibt kein Bild, auch wenn sie technisch einwandfrei ist.
Unter einem NAS von Buffalo liegt meist ein Linux-Software-RAID mit XFS. Ein Server mit ZFS verlangt den vollständigen Pool, ein Ceph-Verbund alle beteiligten Knoten. Welche Laufwerke wir brauchen, sagen wir vor der Abholung. Einen Rebuild auf defekter Basis sollten Sie bis dahin nicht starten, er überschreibt die Abbilder unwiederbringlich.
In der Praxis heißt das: Bei einem Gehäuse von Synology oder QNAP kommen alle Festplatten zu uns, bei einem Server mit ZFS der ganze Pool, bei Ceph alle Knoten des Verbundes. Wir rekonstruieren zuerst die Ebene darunter, also LVM, Btrfs oder ZFS, und suchen erst im wiederhergestellten Dateisystem nach den Abbildern der VMs.
Welches System darunter liegt, ändert den Aufwand deutlich. Ein Synology mit Btrfs über LVM ist ein anderer Fall als ein QNAP mit ext4, ein Buffalo mit XFS wieder ein anderer, und ein Server mit ZFS oder ein Ceph-Verbund noch einmal. Sagen Sie uns beim ersten Anruf Hersteller und Zahl der Laufwerke, dann ist die Einschätzung deutlich genauer.
Windows, Linux und macOS als Wirtssystem
Welches Betriebssystem den Host stellt, ändert nichts an den Abbildern, aber viel an der Arbeit darunter. Unter Windows liegt der Stammordner im Benutzerprofil auf NTFS oder ReFS; gelöschte Abbilder sind hier gut zu finden, weil die Master File Table ihre Einträge lange behält.
Unter Linux liegen die VMs meist im Home-Verzeichnis auf ext4, häufig über LVM, in Serverumgebungen auch auf ZFS oder Btrfs. Ein ext4 mit beschädigtem Journal ist Routine, ein LVM mit fehlenden Metadaten mehr Arbeit, aber lösbar. Unter macOS bringt APFS mit seinen eigenen Snapshots eine weitere Ebene mit, die eine Wiederherstellung manchmal einfacher macht: Ein gelöschter Maschinenordner steht dort noch in einem älteren Stand des Dateisystems.
Verschlüsselte Wirtssysteme. BitLocker unter Windows und LUKS unter Linux sind auf Notebooks der Regelfall. Ohne Wiederherstellungsschlüssel ist auch eine technisch einwandfreie Kopie wertlos. Suchen Sie den Schlüssel heraus, bevor das Gerät auf den Weg geht.
- Eigenes Reinraumlabor & Ersatzteillager
- 95% Datenrettungsgarantie
- Qualitätssicherung nach ISO 9001:2015
- Diskretion & Datenschutz nach DSGVO
- Persönlicher Ansprechpartner
Datenrettung anfragen
So läuft die VirtualBox-Datenrettung im Labor ab
Jede Datenrettung an einer VM läuft in denselben Schritten ab. Die Reihenfolge ist nicht verhandelbar, weil jeder Schritt die Grundlage des nächsten ist. In virtualisierten Systemen gibt es dabei immer zwei Ebenen: das Dateisystem des Hosts und das Dateisystem im Abbild. Welche der beiden betroffen ist, klärt die Analyse.
- Sektorweise Kopie. Zuerst entsteht ein vollständiges Abbild jeder physischen Festplatte. Ist ein Laufwerk defekt, geschieht das an einem Kopiergerät, das defekte Bereiche zunächst überspringt und später gezielt erneut anfährt.
- Dateisystem des Hosts. Aus der Kopie lesen wir das Dateisystem des Wirtssystems neu auf und suchen die Containerdateien. Gelöschte Abbilder finden wir über ihre Signatur, nicht über den Verzeichniseintrag.
- Prüfung der Kette. Jedes gefundene Abbild wird geöffnet, seine UUID gelesen und mit den Harddisk-Einträgen der Konfiguration verglichen. Aus den Harddisk-Einträgen entsteht die Reihenfolge neu, auch ohne intakte vbox-Datei.
- Datenrekonstruktion im Abbild. Erst jetzt wird das Gastdateisystem gelesen. Fehlt ein Differenzabbild, rechnen wir den Zustand aus den vorhandenen Gliedern zusammen.
- Prüfung der Ergebnisse. Wiederhergestellte Datenbanken, Postfächer und Office-Dateien werden geöffnet, nicht nur gezählt. Eine Datei, die sich nicht öffnen lässt, gilt uns nicht als wiederhergestellt.
Ablauf einer VirtualBox-Datenrettung
Alle Wiederherstellungsvorgänge finden an Kopien statt. Das Original wird nach der ersten Kopie nicht mehr angefasst, damit ein zweiter Anlauf jederzeit möglich bleibt. Kommt ein Wiederherstellungsvorgang an seine Grenze, weil ein Glied der Kette fehlt, sagen wir das vor dem Angebot und nicht danach.
Fehlt die vbox-Datei ganz, also auch die Harddisk-Einträge, rekonstruieren wir die Reihenfolge aus den Abbildern selbst: Jedes Differenzabbild trägt im Kopf die UUID seines Vorgängers. Aus diesen Verweisen entsteht die Kette auch ohne Konfiguration, und die Datenrekonstruktion im Gastdateisystem kann beginnen. Eine Datenrekonstruktion ohne diese Reihenfolge wäre Raten.
Diese Reihenfolge gilt bei RecoveryLab für jedes virtualisierte System, unabhängig davon, welches System die Maschine betreibt. In virtualisierten Umgebungen entscheidet nicht die Zahl der Dateien über den Aufwand, sondern die Frage, auf welcher Ebene die Struktur fehlt.
Die Virtualisierung zieht dafür eine Ebene ein. Ohne Virtualisierung liegt ein Dateisystem auf einem Datenträger; mit Virtualisierung liegt ein Dateisystem in einer Datei, die selbst auf einem Datenträger liegt. Eine Datenrettung muss deshalb auf vier Ebenen ansetzen können:
- Das physische Speichermedium: Festplatte, SSD oder RAID-Verbund des Wirtssystems
- Das Dateisystem des Hosts: NTFS, ext4 oder APFS, in dem die Containerdateien liegen
- Die virtuelle Festplatte: das VDI mit seiner Kette aus Basisabbild und Differenzabbildern
- Das Dateisystem im Gast: die Partitionstabelle und das Dateisystem innerhalb des Abbildes
Was aus Ihrer Umgebung dazugehört, klären wir vorher: die Zahl der VMs, die Konfiguration der virtuellen Festplatten und die Frage, ob die Containerdateien überhaupt noch am selben Ort liegen. Erst mit diesen Angaben lässt sich sagen, wie viele Wiederherstellungsvorgänge nötig sind.
Praxisfälle aus der VirtualBox-Datenrettung
Vier Fälle aus der Werkstatt, jeweils von der Ausgangslage bis zum Ergebnis:
- Gelöschter Sicherungspunkt. Zwei Snapshots einer Entwicklungs-VM wurden gelöscht, um Plattenplatz zu schaffen. Das Zusammenführen brach in der Nacht ab, am Montag startete die Maschine nicht mehr; Basisabbild und Differenzabbild lagen in einem inkonsistenten Zustand vor. Nach der Kopie beider Dateien ließ sich der Stand von Freitagmittag vollständig wiederherstellen.
- Formatierte Systemplatte. Windows wurde neu aufgesetzt, die VMs lagen entgegen der Annahme nicht auf dem zweiten Laufwerk, sondern im Benutzerprofil. Aus der formatierten SSD wurden vier VDI wiederhergestellt, darunter eine XP-Maschine mit einer Fachanwendung, für die es kein Installationsmedium mehr gab.
- Defektes NAS. Die VMs lagen auf einem Synology-NAS mit zwei Festplatten im RAID 1. Eine Platte fiel aus, die zweite hatte defekte Sektoren. Nach der sektorweisen Kopie beider Festplatten und der Rekonstruktion des Verbundes standen die Abbilder wieder zur Verfügung; die Datenrettung dauerte vier Tage, davon zwei allein für die Kopie.
- Halb umgezogene VM. Drei VMs wurden von einem VMware-Host auf ein Notebook mit VirtualBox geholt. Zwei VMDK ließen sich einbinden, die dritte nicht, sie war beim Kopieren über das Netz abgebrochen. Da die Quelle bereits gelöscht war, blieb nur der Weg über die Festplatten des VMware-Hosts. Zwei der drei Snapshots wurden wiederhergestellt, der jüngste fehlte.
Was die vier Fälle verbindet: Der Datenverlust selbst war klein. Teuer wurde er erst durch das, was danach versucht wurde. In drei von vier Fällen wäre der aktuelle Stand erreichbar geblieben, wenn nach dem ersten Fehler nichts mehr geschrieben worden wäre.
Das dritte Beispiel zeigt zugleich, warum sich die Dauer schwer vorhersagen lässt. Nicht die Datenrettung an den Abbildern kostet Zeit, sondern die sektorweise Kopie der defekten Festplatte darunter. Beim vierten Beispiel war der Datenverlust in zwei Tagen erledigt, weil kein Datenträger defekt war.
Analyse, Kosten und häufige Fragen
Der Festpreis richtet sich nach dem Schadensbild, nicht nach der Zahl der Dateien oder der Größe der Abbilder. Entscheidend ist, ob nur die Kette zu rekonstruieren ist oder zusätzlich Datenträger des Hosts ausgefallen sind.
Nach der Analyse nennen wir einen Festpreis, der alle Wiederherstellungsvorgänge einschließt. Erst mit Ihrer Zustimmung beginnt die Datenrekonstruktion. Gelingt sie nicht, bleibt es bei der Analyse.
- Abholung des Datenträgers, für Sie kostenfrei
- Analyse von Wirtssystem und Abbildern, kostenpflichtig und mit einem klaren Befund
- Festpreis mit Aussage zu Aufwand, Aussichten und Dauer
- Datenrettung ausschließlich an einer sektorweisen Kopie, nie am Original
- Rückgabe verschlüsselt auf einem neuen Datenträger, auf Wunsch mit Auftragsverarbeitungsvertrag
RecoveryLab arbeitet seit 2004 an Datenverlusten, das Labor steht in Leipzig, das Qualitätsmanagement ist nach ISO 9001:2015 zertifiziert. Aus diesen Jahren stammt die Erfahrung, auf die es bei virtualisierten Systemen ankommt: zuerst die Ebene zu bestimmen, auf der der Fehler sitzt, und erst danach etwas anzufassen.
Aus denselben Jahren stammt die Reihenfolge im Angebot: Der Festpreis steht fest, bevor die Arbeit beginnt, und er ändert sich nicht mehr. Auf Wunsch beginnen wir mit dem Teil, den Sie zuerst brauchen. Für Geschäftskunden arbeiten wir mit Auftragsverarbeitungsvertrag.
- Eigenes Labor mit Reinraum in Leipzig, seit 2004 auf Datenrettung spezialisiert
- Qualitätsmanagement nach ISO 9001:2015
- Vertragliche Datengarantie ab 95 Prozent
- TÜV-Bewertung 4,9 von 5 aus 311 Kundenmeinungen
In den Jahren seit 2004 hat sich die Technik mehrfach gewandelt, die Reihenfolge der Arbeitsschritte nicht. Geändert hat sich vor allem der Anteil virtualisierter Systeme: Vor zehn Jahren war eine VM in einem Auftrag die Ausnahme, heute ist sie bei Geschäftskunden der Regelfall. Die Erfahrung aus diesen Jahren steckt genau in der Frage, die am Anfang jeder Analyse steht: Auf welcher Ebene fehlt etwas?
Ein Beispiel dafür, was das praktisch bedeutet: Meldet VirtualBox einen fehlenden Datenträger, ist ein Datenverlust auf Ebene der Abbilder wahrscheinlich und die Wiederherstellung meist schnell möglich. Erkennt dagegen schon das Betriebssystem des Hosts sein Laufwerk nicht mehr, liegt der Datenverlust eine Ebene tiefer, und vor jeder Datenrettung steht die sektorweise Kopie.
Diese Einschätzung ist am Telefon in wenigen Minuten möglich. Sie ersetzt keine Analyse, sagt Ihnen aber, ob RecoveryLab überhaupt gebraucht wird oder ob wenige Schritte am eigenen System genügen. Nach über zwanzig Jahren Erfahrung ist das der ehrlichere Anfang als ein Angebot ins Blaue.
Steht ein Termin im Weg, läuft der Auftrag auf Wunsch als 24h-Express, dann wird rund um die Uhr an Ihrem Fall gearbeitet. Was eine Datenrettung insgesamt kostet, steht auf der Seite Preise und Abrechnung.
Was wir für die Analyse von Ihnen brauchen
Je genauer die Ausgangslage beschrieben ist, desto schneller ist die Analyse durch. Diese Angaben helfen am meisten:
- Welches Betriebssystem auf dem Host läuft und welche Version von Oracle VirtualBox zuletzt installiert war.
- Wo der Stammordner lag: im Benutzerprofil oder auf einem eigenen Laufwerk. Ein Blick in die Einstellungen genügt, falls das Programm noch startet.
- Wie viele VMs betroffen sind und wie ihre Konfiguration aussah: Größe der virtuellen Festplatte, Format der Abbilder, Zahl der Sicherungspunkte.
- Was seit dem Datenverlust geschehen ist: eine Neuinstallation, Reparaturversuche, Datenwiederherstellungssoftware, ein Rebuild am RAID. Diese Angabe entscheidet oft über die Aussichten.
- Ob eine Verschlüsselung im Spiel ist und wo der Wiederherstellungsschlüssel liegt.
- Welche Daten Vorrang haben. Auf Wunsch beginnen wir mit einem klar benannten Teil, zum Beispiel der Datenbank der Warenwirtschaft.
Ist das Gerät noch bedienbar, sagt ein Foto des Fensters mit der Fehlermeldung mehr als eine Beschreibung aus dem Gedächtnis. Ist es das nicht, genügt der Anruf. Die Erstberatung am Telefon kostet nichts und klärt in wenigen Minuten, ob eine Datenrettung überhaupt nötig ist oder ob wenige Schritte genügen.
Häufige Fragen zur VirtualBox-Datenrettung
Häufig ja. Beim Löschen verschwindet zunächst nur der Verweis im Dateisystem des Wirtssystems, die Blöcke der Abbilder bleiben zunächst liegen. Entscheidend ist, dass auf diesem Datenträger ab sofort nicht mehr geschrieben wird. Jeder Neustart und jede Installation legt neue Daten an und verringert die Aussichten. Sagen Sie uns beim Anruf, was seit dem Löschen auf dem Rechner passiert ist.
Das Basisabbild trägt den Stand vor dem ersten Sicherungspunkt. Alles, was danach in der Maschine passiert ist, steckt in den Differenzabbildern. Fehlen sie, fehlt dieser Zeitraum. Ob sich die Abbilder wiederherstellen lassen, hängt davon ab, was auf dem Wirtssystem seither geschrieben wurde. Bringen Sie den ganzen Datenträger, nicht nur den Maschinenordner.
In der Regel nicht. Die Nutzdaten liegen in den Abbildern, nicht in der Beschreibungsdatei. Wie aufwendig der Fall wird, hängt davon ab, welche Dateien im Maschinenordner noch vollständig sind. Lassen Sie den Ordner unverändert und schildern Sie uns, was zuletzt passiert ist.
Das entscheidet das Schadensbild. Eine unterbrochene Kette bei intakten Datenträgern ist deutlich schneller erledigt als ein Fall, bei dem zusätzlich Laufwerke des Wirtssystems ausgefallen sind. Nach der Analyse erhalten Sie ein Festpreisangebot, das alle Kosten abdeckt. Erst mit Ihrer Zustimmung beginnt die Rettung; gelingt sie nicht, bleibt es bei der Analyse.
Eine reine Rekonstruktion der Abbilder ist meist in wenigen Tagen erledigt. Sind physische Datenträger betroffen, kommt die Zeit für die sektorweise Kopie hinzu, die bei beschädigter Oberfläche nur langsam vorankommt. Eine belastbare Angabe für Ihren Fall erhalten Sie zusammen mit dem Festpreisangebot. Ist der Termin knapp, läuft der Auftrag im 24h-Express.
Nicht zwingend. Bei einem einzelnen Rechner genügt der Datenträger, auf dem der Maschinenordner liegt. Stammen die Abbilder aus einem RAID-Verbund oder einem Netzwerkspeicher, brauchen wir alle Laufwerke des Verbundes, weil sich die Struktur nur aus dem vollständigen Satz rekonstruieren lässt. Die Abholung übernehmen wir.
Solange die VM keine Sicherungspunkte hat, genügt das Abbild. Sobald Snapshots im Spiel sind, brauchen Sie den ganzen Maschinenordner: die Beschreibungsdatei mit der Endung vbox, das Basisabbild und den Unterordner mit den Differenzabbildern. Fehlt ein Glied der Kette, startet die Maschine nur mit dem Zustand vor dem ersten Sicherungspunkt.
Zunächst nicht. Jedes Abbild trägt eine eindeutige Kennung, und VirtualBox verweigert die Arbeit, wenn dieselbe UUID zweimal auftaucht. Das ist eine Schutzfunktion, kein Schaden. Riskant wird es erst, wenn die Kennung am Original geändert wird und dabei die Verweise der Beschreibungsdatei nicht mehr passen. Arbeiten Sie in solchen Fällen an einer Kopie.
Meist ist ein Zusammenführen abgebrochen, oft weil der Plattenplatz ausging. Basisabbild und Differenzabbild stehen dann in einem inkonsistenten Zustand zueinander. Wichtig ist jetzt, die VM nicht erneut zu starten und keinen weiteren Vorgang anzustoßen. Wir lesen beide Abbilder an einer Kopie aus und setzen die Kette neu zusammen.
Ja, bei Geschäftskunden ist das der Regelfall. In virtualisierten Umgebungen liegen mehrere Systeme auf demselben Speichermedium; fällt es aus, sind alle VMs gleichzeitig betroffen. Wir sichern zuerst das Speichermedium und rekonstruieren die Abbilder der Maschinen nacheinander. Welche VM zuerst wiederhergestellt wird, entscheiden Sie.
In aller Regel ja. Ob das Betriebssystem des Hosts startet, sagt nichts darüber aus, ob die Daten lesbar sind. Wir bauen den Datenträger aus, sichern ihn sektorweise und suchen die Abbilder im Dateisystem. Liegt es nicht an einem defekten Laufwerk, sondern an einer misslungenen Installation, ist die Datenrettung meist unkompliziert.
Weil die Virtualisierung eine Ebene einzieht. Ohne Virtualisierung liegt ein Dateisystem auf einem Datenträger. Mit Virtualisierung liegt ein Dateisystem in einer Datei, die selbst auf einem Datenträger liegt. Die Arbeit muss deshalb auf vier Ebenen ansetzen können: physisches Speichermedium, Dateisystem des Hosts, virtuelle Festplatte und Dateisystem im Gast. Welche Ebene betroffen ist, verrät die Fehlermeldung nicht.
Analyse und Wiederherstellungsvorgänge finden im eigenen Labor in Leipzig statt, nicht bei Dritten. Das Qualitätsmanagement ist nach ISO 9001:2015 zertifiziert, auf Wunsch schließen wir einen Auftragsverarbeitungsvertrag. Die Rückgabe erfolgt verschlüsselt, die Arbeitskopien löschen wir nach Ihrer Freigabe sicher.
Direkt selten. Die Gasterweiterungen sorgen für die Auflösung des Bildschirms, für gemeinsame Ordner und die Zwischenablage. Gefährlich sind sie nur mittelbar: Wer über einen gemeinsamen Ordner arbeitet, legt seine Daten auf dem Host ab, nicht in der VDI. Nach einem Datenverlust wird dann im Abbild gesucht, obwohl die Dateien auf dem Wirtssystem lagen. Prüfen Sie deshalb, welche Gasterweiterungen eingerichtet waren, bevor Sie die Suche eingrenzen.
In den meisten Fällen ja. Alte Backups und ein wiederhergestellter Stand von heute schließen zusammen die Lücke, die keiner von beiden allein schließt. Sagen Sie uns, welchen Zeitpunkt Ihre Backups abdecken. Wir richten die Wiederherstellung dann auf den Zeitraum aus, der fehlt.
Nichts weiter starten und die halb geschriebene Zieldatei nicht löschen. Bei einer abgebrochenen Umwandlung sind je nach Zeitpunkt beide Dateien brauchbar: die Quelle ganz, das Ziel teilweise. Ist die VHDX bereits gelöscht, suchen wir sie auf dem Laufwerk. Auch dafür gilt, dass ab sofort nicht mehr geschrieben werden darf.
Meistens nicht. Ein schwarzer Bildschirm oder ein Bluescreen im Fenster der Maschine sagt nur, dass das Gastsystem nicht startet. Die Daten liegen im Abbild und lassen sich in aller Regel vollständig wiederherstellen, auch wenn die VM selbst nie wieder startet. Unternehmen Sie an dieser Stelle keine weiteren Versuche mit Reparaturwerkzeugen, denn die schreiben in das oberste Differenzabbild.
Dass der Verzeichniseintrag fehlt, nicht zwingend, dass die Daten fehlen. Ein Ordner, der im Explorer nicht mehr auftaucht, kann gelöscht, verschoben oder auf einem Laufwerk liegen, das der PC gerade nicht einbindet. Prüfen Sie zuerst, ob der Stammordner in den Einstellungen noch auf denselben Pfad zeigt. Ist der Ordner tatsächlich gelöscht, gilt ab sofort: nichts mehr auf dieses Laufwerk schreiben.
Das entscheiden Sie, aber die Erfahrung spricht dafür. Eine XP-VM enthält oft eine Fachanwendung, die es nicht mehr zu kaufen gibt, mit einer Lizenz, die an diesen einen Rechner gebunden ist. Der Wert steckt nicht in den Gigabyte, sondern darin, dass die Maschine sonst nie wieder läuft. Solche VMs stellen wir regelmäßig wieder her.
Ja, das ist bei Geschäftskunden der Regelfall. Liegen die Abbilder auf einem RAID-Verbund, einem NAS von Synology, QNAP oder Buffalo oder auf einem Server mit ZFS, brauchen wir alle Laufwerke des Verbundes. Die Struktur darunter lässt sich nur aus dem vollständigen Satz rekonstruieren, einzelne Festplatten ergeben kein Bild.
Ihre Frage steht nicht dabei? Rufen Sie an, die telefonische Erstberatung kostet nichts. Schildern Sie dabei möglichst genau, was zuletzt an der VM und am Wirtssystem gemacht wurde. Das ist die wichtigste Angabe für die Einschätzung.
