Eine virtuelle Maschine ist nicht wie ein klassisches System in einer Partition abgelegt: Sie ist eine grosse Datei auf einer Festplatte, fast immer einem Server im RAID-Verbund. Wenn der Hypervisor abstürzt, das RAID ausfällt oder diese Datei beschädigt wird, sind die Daten nicht zwangsläufig verloren, doch müssen zwei Ebenen nacheinander wiederhergestellt werden: zunächst die Datei der virtuellen Maschine auffinden, dann das darin liegende System wiederherstellen. Der richtige Reflex ist derselbe wie bei jedem Server: alles abschalten, nichts neu anlegen und die Festplatten einem Labor anvertrauen.

Der folgende Text erklärt, was Virtualisierung wirklich ist, wie eine virtualisierte Umgebung ausfällt und warum bestimmte Reparaturversuche die Daten endgültig zerstören.

Virtualisierung verständlich erklärt

Virtualisieren bedeutet, eine vollständige Maschine mit ihrem eigenen Betriebssystem innerhalb einer anderen laufen zu lassen. Diese virtuelle Maschine ist nicht Teil der Partitionierung der Festplatte: Sie wird in einer grossen Datei gespeichert, was es ermöglicht, sie wie ein einfaches Dokument von einem Server auf einen anderen zu verschieben.

Es gibt zwei Arten zu virtualisieren, und die Unterscheidung ist wichtig. Die erste ist die sogenannte Desktop-Virtualisierung mit einer Software wie VMware Workstation oder Oracle VirtualBox, installiert innerhalb eines bestehenden Betriebssystems, etwa Windows. Diese Software lässt ein zweites System in einem Fenster laufen. Man stapelt also die Ebenen: Die virtuelle Maschine kommuniziert mit der Virtualisierungssoftware, die mit Windows spricht, das schliesslich auf die reale Hardware zugreift, das Mainboard, die Netzwerkkarte und den Rest. Das ist praktisch, um zu testen oder zwei Systeme auf einem Arbeitsplatz nebeneinander zu betreiben, doch das setzt man nicht im Produktivbetrieb ein.

Für einen Unternehmensserver setzt man einen Hypervisor ein: VMware ESXi, Microsoft Hyper-V oder Proxmox, wobei Letzterer auch in einer quelloffenen und kostenlosen Community-Version existiert. Hier gibt es kein grosses Betriebssystem, über dem man eine Software installieren würde. Der Hypervisor ist selbst eine kleine, leichtgewichtige Software, die direkt auf der Maschine liegt, und auf ihm installiert man echte virtuelle Maschinen unter Windows, Linux, macOS oder leichteren Systemen.

Der Nutzen ist wirtschaftlicher und praktischer Natur. Eine leistungsstarke physische Maschine wird fast nie dauerhaft voll ausgelastet. Statt diese Leistung ungenutzt zu lassen, lässt man zwei, drei oder vier virtualisierte Server auf einer einzigen Maschine laufen, die sich deren Ressourcen teilen. Mehr noch: Man kann jeder VM eine Anzahl an Prozessoren und eine Menge an Arbeitsspeicher zuweisen und diese bei Bedarf erhöhen, wenn ein Server unter Last gerät. Diese Flexibilität macht den Erfolg der Virtualisierung aus, und sie ist zugleich der Grund, weshalb sich viele kritische Daten auf einer einzigen Maschine bündeln.

Desktop-Virtualisierung und Hypervisor: der Unterschied

Kriterium	Desktop-Virtualisierung	Hypervisor (Server)
Beispiele	VMware Workstation, Oracle VirtualBox	VMware ESXi, Microsoft Hyper-V, Proxmox
Installation	In einem bestehenden System (Windows)	Direkt auf der Maschine
Gestapelte Ebenen	VM, Software, Windows, Hardware	VM, Hypervisor, Hardware
Typische Nutzung	Testen, zwei Systeme nebeneinander betreiben	Produktivserver
Speicherung	Eine Datei auf der Festplatte des Arbeitsplatzes	Eine Datei auf einem Datastore, fast immer im RAID-Verbund

Wie eine virtualisierte Umgebung ausfällt

Da alles auf ein und derselben physischen Maschine und einem Software-Stack beruht, gibt es mehrere Bruchstellen. Hier sind die, die wir sehen.

Defekt	Folge
Hypervisor stürzt ab	Kein Zugriff mehr auf die Dateien der virtuellen Maschinen
Server-RAID fällt aus	Der Speicher der VMs wird unzugänglich
Datastore beschädigt	Der Bereich, der die VMs beherbergt, ist nicht mehr lesbar
VMDK- oder VHDX-Datei beschädigt	Wie ein Defekt der Partition der VM
Interne Partition der VM beschädigt	Die VM startet nicht mehr

Der Hypervisor kann abstürzen und den Neustart verweigern: Man verliert dann den Zugriff auf die Dateien, die die verschiedenen virtuellen Maschinen enthalten. Das Server-RAID kann ausfallen, und da Virtualisierungsserver fast immer auf einem RAID laufen, ist das ein Klassiker. Der Datastore, jener Bereich, der die VMs beherbergt und ihre Organisation beschreibt, kann beschädigt werden. Die Datei der virtuellen Maschine selbst, eine VMDK bei VMware, eine VHDX bei Hyper-V, kann beschädigt werden, was einem Defekt der Partition der VM gleichkommt. Schliesslich kann der Defekt im Inneren der virtuellen Maschine selbst liegen, in ihrem Dateisystem, und sie am Starten hindern.

In der Praxis sind die beiden häufigsten Fälle der Ausfall des RAID und der defekte Hypervisor. Der Rest kommt hinzu oder ergibt sich daraus.

Die Falle des Snapshots

Eine sehr verbreitete Verwechslung kommt teuer zu stehen: Viele halten einen Snapshot für eine Sicherung. Das ist falsch und gefährlich.

Ein Snapshot ist nur eine differenzielle Momentaufnahme: Er zeichnet die seit einem bestimmten Punkt eingetretenen Änderungen auf und hängt vollständig von der übergeordneten Festplatte ab, auf die er sich stützt. Ist diese übergeordnete Festplatte verloren oder beschädigt, oder ist die Snapshot-Kette unterbrochen, ist der Snapshot allein nichts mehr wert. Schlimmer noch: Eine lange, nie konsolidierte Snapshot-Kette schwächt das Ganze und erschwert jede Datenrettung. Ein Snapshot hilft, um schnell zurückzugehen, doch er ersetzt in keinem Fall eine echte, unabhängige Sicherung.

Die doppelte Ebene: die Datei auffinden, dann ihren Inhalt

Das ist es, was die Datenrettung eines virtualisierten Servers von der einer gewöhnlichen Festplatte unterscheidet: Es gibt zwei Ebenen wiederherzustellen, eine nach der anderen.

Die erste besteht darin, die Datei der virtuellen Maschine, die VMDK oder die VHDX, dort aufzufinden, wo sie sich befindet, das heisst meistens auf einem defekten RAID. Man muss also zunächst das RAID rekonstruieren, um Zugriff auf den Datastore zu erhalten, und dann die Virtualisierungsdateien daraus extrahieren. Die zweite Ebene besteht darin, diese Datei zu öffnen und das darin enthaltene System mit seinem eigenen Dateisystem und seinen Daten wiederherzustellen.

Der Bedarf des Kunden lenkt dann die Arbeit. Manche möchten die virtuellen Dateien selbst wiederherstellen, um sie unverändert auf einem anderen Server aufzusetzen. Andere haben für die Virtualisierung keine Verwendung mehr: Sie möchten auf einen neueren Windows Server migrieren, und nicht die VMDK interessiert sie, sondern ihr Inhalt. In diesem Fall exportieren wir die VM-Datei und analysieren dann ihren Inhalt, um die darin enthaltenen Dateien, Datenbanken oder Mailsysteme separat wiederherzugeben.

Unsere Methode ändert sich nicht. Wie bei jeder Datenrettung beginnen wir damit, den Zustand einzufrieren: kein direkter Eingriff an den Originalen, sondern bitgenaue Sicherungskopien, auf denen allein wir anschliessend arbeiten. Wir rekonstruieren das RAID im laufenden Betrieb aus diesen Kopien, finden die Virtualisierungsdateien auf, exportieren sie und stellen dann ihren Inhalt wieder her. Wir benötigen im Übrigen nicht den gesamten Server: Alles lässt sich virtuell nachbearbeiten, ausgehend von den Festplatten.

Die Fehler, die verschlimmern, und die Prävention

Gegenüber einer defekten virtualisierten Umgebung ist Verbissenheit der schlimmste Feind. Einen Datastore neu anlegen, neue Snapshots erzeugen, den Hypervisor auf den Festplatten neu installieren oder einen riskanten RAID-Rebuild starten: Jede dieser Handhabungen schreibt auf den Speicher und kann noch wiederherstellbare Daten endgültig zerstören. Je mehr man versucht, selbst blind zu reparieren, desto mehr verringert man die Chancen. Der richtige Reflex ist, den Server abzuschalten und die Festplatten einem Labor anzuvertrauen, bevor man irgendetwas anderes versucht.

Was die Prävention betrifft, entbindet die Virtualisierung nicht vom Sichern, im Gegenteil, da sie mehrere Server auf einer einzigen Maschine bündelt. Bestimmte Lösungen, wie Proxmox, können echte Sicherungen auf ein entferntes NAS durchführen, was ein echter Vorteil ist. Doch selbst ein automatisiertes Backup schützt nicht vor allem, da eine Ransomware beispielsweise die VM-Dateien wie den Rest erreichen kann. Eine virtuelle Maschine auf einem RAID ist keine Sicherung: Auch hier braucht es eine unabhängige, anderswo aufbewahrte Kopie.

Was man sich merken sollte

Eine virtuelle Maschine ist eine Datei, in der Regel auf einem Server im RAID-Verbund gespeichert, und ihre Datenrettung spielt sich auf zwei Ebenen ab: die VMDK- oder VHDX-Datei auffinden, dann das System und die darin enthaltenen Daten wiederherstellen. Die häufigsten Defekte gehen auf den Ausfall des RAID oder den Absturz des Hypervisors zurück, und ein Snapshot, oft für eine Sicherung gehalten, ist keine.

Im Problemfall gilt die Regel jedes ernsthaften Servervorfalls: nichts neu anlegen, nichts neu installieren, abschalten und die Festplatten anvertrauen. Ein Labor arbeitet auf Kopien, rekonstruiert das RAID virtuell, extrahiert die VM-Dateien und ihren Inhalt, ohne je die Originale zu berühren. Und für die Zukunft bleibt eine echte externe Sicherung das einzige Netz, das trägt.

Häufige Fragen

Was ist eine virtuelle Maschine genau?

Es ist ein vollständiger Computer mit seinem eigenen Betriebssystem, der innerhalb einer anderen Maschine läuft. Im Gegensatz zu einem klassischen System belegt sie keine Partition: Sie wird in einer grossen Datei gespeichert (einer VMDK bei VMware, einer VHDX bei Hyper-V), was es ermöglicht, sie wie ein Dokument von einem Server auf den anderen zu verschieben.

Kann ein Snapshot als Sicherung dienen?

Nein. Ein Snapshot ist eine differenzielle Momentaufnahme, die nur die Änderungen seit einem bestimmten Punkt aufzeichnet und die vollständig von der übergeordneten Festplatte abhängt. Ist das übergeordnete Element verloren oder ist die Snapshot-Kette unterbrochen, ist der Snapshot allein nichts mehr wert. Er hilft, um zurückzugehen, ersetzt aber keine unabhängige Sicherung.

Welches sind die häufigsten Defekte auf einem virtualisierten Server?

In der Praxis überwiegen zwei: der Ausfall des Server-RAID (Virtualisierungsserver laufen fast immer auf einem RAID) und der Hypervisor, der abstürzt und den Neustart verweigert. Danach folgen der beschädigte Datastore, die beschädigte VMDK- oder VHDX-Datei und die interne Partition der VM.

Kann man die Daten ohne den physischen Server wiederherstellen?

Ja. Die Festplatten genügen. Wir erstellen davon bitgenaue Kopien, rekonstruieren das RAID virtuell aus diesen Kopien, finden die Virtualisierungsdateien auf und stellen dann ihren Inhalt wieder her. Alles lässt sich virtuell nachbearbeiten, ohne die gesamte Maschine zu benötigen.

Was tun und vor allem nicht tun, wenn eine VM nicht mehr startet?

Keinen Datastore neu anlegen, keine neuen Snapshots erzeugen, den Hypervisor nicht auf den Festplatten neu installieren und keinen riskanten RAID-Rebuild starten: Jede dieser Handhabungen schreibt auf den Speicher und kann noch wiederherstellbare Daten zerstören. Der richtige Reflex ist, den Server abzuschalten und die Festplatten einem Labor anzuvertrauen.

Entbindet die Virtualisierung vom Erstellen von Sicherungen?

Im Gegenteil. Da sie mehrere Server auf einer einzigen Maschine bündelt, erhöht sie das Risiko im Schadensfall. Lösungen wie Proxmox können auf ein entferntes NAS sichern, doch kein Backup schützt vor allem (eine Ransomware kann die VM-Dateien erreichen). Eine VM auf einem RAID ist keine Sicherung: Es braucht eine unabhängige, anderswo aufbewahrte Kopie.