bizIT

Zusammenfassung (Answer first)

Ihre VM bootet nicht mehr, ein Snapshot hängt fest oder die VHDX/VMDK meldet „corrupt“? Dann zählt vor allem eins: nichts weiter „reparieren“, was dabei schreibt. In vielen Fällen sind die Daten im virtuellen Datenträger noch vorhanden – nur Metadaten, Snapshot-Ketten oder das Dateisystem sind beschädigt. Wenn Sie jetzt sauber stoppen, klonen und gezielt auslesen, lassen sich Projekte, Buchhaltung, Mail-Archive und ganze Benutzerprofile häufig wiederherstellen. Dieser Beitrag führt Sie Schritt für Schritt durch die sicheren Optionen – vom schnellen Reality-Check bis zur professionellen Labor- und Forensik-Route.

Inhalt

• Wenn die VM streikt: typische Symptome
• Sofortmaßnahmen: Was Sie jetzt tun (und lassen)
• Was ist eigentlich kaputt? Container vs. Dateisystem vs. Snapshot-Kette
• Hyper-V: VHDX, Checkpoints & „AVHDX-Drama“
• VMware: VMDK, Snapshots, „Descriptor missing“
• Proxmox/KVM: QCOW2, LVM-Thin & ZFS – und die kleinen Fallen
• Daten retten ohne Boot: Datei-Extraktion aus dem Image
• Wenn Verschlüsselung im Spiel ist: BitLocker & Co. in VMs
• Typische Ursachen – und wie Sie sie künftig vermeiden
• Wann lohnt sich der Profi-Weg (und wann ist DIY ok)?
• Kurz-Checkliste zum Mitnehmen

Wenn die VM streikt: typische Symptome

Virtuelle Maschinen sind wie Umzugskartons: außen sieht alles stabil aus – bis innen etwas verrutscht. Häufige Alarmzeichen:

• „The file is corrupted and unreadable“ bei VHDX/VMDK/QCOW2
• Snapshot/Checkpoint lässt sich nicht löschen oder zusammenführen
• VM bleibt beim Booten hängen, Blue Screen, Kernel Panic
• Datastore voll, Host friert, danach startet die VM nicht mehr
• „Descriptor file missing“ (VMware) oder AVHDX-Kettenchaos (Hyper‑V)
• Plötzliche 0-Byte/kleine Dateigröße beim virtuellen Datenträger (sehr kritisch)

In Berliner Büros – etwa rund um Treptow, Neukölln oder Kreuzberg – passiert das oft nach Stressmomenten: Update-Fenster, Stromunterbrechung, knappes Storage, „nur schnell Snapshot machen“.

Sofortmaßnahmen: Was Sie jetzt tun (und lassen)

Hier entscheidet sich, ob Sie eine elegante Rettung bekommen – oder eine Endlos-Baustelle.

Tun Sie das:

1. VM sofort herunterfahren (wenn sie noch „zuckt“). Wenn es schon knallt: Host stabilisieren, keine hektischen Reboots.

2. Autostart deaktivieren, damit die VM nicht beim nächsten Host-Start wieder losrennt.

3. Sichern Sie die VM-Dateien im Ist-Zustand: Kopie/Backup der gesamten VM-Struktur (inkl. Snapshots, Konfig, NVRAM).

4. Wenn möglich: Read-only arbeiten oder auf einem separaten Storage klonen.

Lassen Sie das unbedingt:

• Keine „Reparatur“ direkt am Original (z. B. Snapshot-Merge, chkdsk/fsck im Image ohne Kopie).
• Keine hektischen „Cleanup“-Aktionen im Datastore.
• Keine „Ich probier mal ein Tool“-Orgie, die am Ende Metadaten überschreibt.

Ein guter Merksatz: Erst konservieren, dann operieren.

Was ist eigentlich kaputt? Container vs. Dateisystem vs. Snapshot-Kette

Das klingt nerdig, hilft aber enorm:

• Container beschädigt: Die VHDX/VMDK/QCOW2-Struktur oder Metadaten sind inkonsistent.
• Dateisystem im Gast beschädigt: NTFS/ext4 ist kaputt, Container ist ok.
• Snapshot-Kette defekt: Es fehlen Delta-Dateien oder die Reihenfolge stimmt nicht.

Warum das wichtig ist? Weil die „richtige“ Rettung völlig anders aussieht:

• Bei Snapshot-Ketten brauchen Sie oft rekonstruiertes Zusammenführen – nicht blindes Merge.
• Bei Dateisystem-Schäden kann dateibasiertes Auslesen oder eine logische Rekonstruktion reichen.
• Bei Container-Schäden geht’s um strukturierte Reparatur oder Rohdaten-Extraktion.

Hyper-V: VHDX, Checkpoints & „AVHDX-Drama“

Hyper‑V ist robust – bis Checkpoints eskalieren.

Typische Hyper‑V-Fälle:

• AVHDX-Dateien wachsen, Datenträger läuft voll.
• Checkpoint-Löschung startet, bleibt hängen, danach Inkonsistenzen.
• Host-Crash mitten im Merge.

Sicherer Ansatz:

• Prüfen, ob alle AVHDX-Dateien vorhanden sind.
• Keine manuelle „Umbenennung nach Gefühl“.
• Wenn möglich: Kopie der gesamten VM ziehen und erst dort mit Analysen starten.

Gerade in kleineren Umgebungen in Alt-Treptow oder Friedrichshain sieht man oft „Quick-and-dirty“-Setups: ein Host, ein Storage, viele Checkpoints. Das funktioniert… bis es nicht mehr funktioniert.

VMware: VMDK, Snapshots, „Descriptor missing“

VMware trennt gern in Descriptor + Flat-/Delta-Dateien. Wenn der Descriptor weg ist oder nicht zur Flat-Datei passt, sieht es schlimm aus – ist aber oft lösbar.

Typische VMware-Meldungen:

• „Descriptor file missing“
• Snapshot chain broken
• „File locked“ nach Crash

Sicherer Ansatz:

• Snapshot-Struktur vollständig sichern.
• Locks nicht mit roher Gewalt „wegklicken“, wenn unklar ist, warum sie da sind.
• Bei fehlenden Descriptoren: Rekonstruktion ist möglich – aber nur, wenn Geometrie/Größe sauber ermittelt wird.

In Büros rund um Mitte oder Prenzlauer Berg trifft man das oft nach Storage-Migrationen: „Wir haben nur den Ordner kopiert“. Tja – und die Snapshots gleich mit in die Falle.

Proxmox/KVM: QCOW2, LVM-Thin & ZFS – und die kleinen Fallen

Proxmox ist beliebt, weil’s schnell und flexibel ist. Genau das ist manchmal das Problem.

Typische Stolpersteine:

• QCOW2 nach Host-Absturz inkonsistent
• LVM-Thin: Metadaten voll oder beschädigt
• ZFS: Pool-Status kritisch, Scrub-Funde, falsche „Fixes“

Sicherer Ansatz:

• Keine Experimente am Pool/Thin-Metadaten ohne Plan.
• Erst prüfen: Ist das Problem wirklich die VM-Datei – oder der Storage-Layer?

Wenn Sie in Schöneberg ein kleines Rechenrack betreiben oder in Adlershof eine Testumgebung „produktiv geworden“ ist: Genau da entstehen diese Fälle.

Daten retten ohne Boot: Datei-Extraktion aus dem Image

Die gute Nachricht: Sie müssen die VM oft gar nicht wieder bootfähig bekommen, um Daten zu retten.

Gängige Wege (sicher gedacht):

• Image read-only mounten und Dateien kopieren
• Dateisystem-Rekonstruktion aus einem Abbild
• Bei Datenbanken: gezielt DB-Files extrahieren und konsistent wiederherstellen

Das ist häufig der schnellste Weg, wenn Sie „nur“ an Inhalte müssen: Kundenordner, CAD-Projekte, DATEV-Exports, Mailstore, Fotos – eben das, was wirklich zählt.

Wenn Verschlüsselung im Spiel ist: BitLocker & Co. in VMs

Verschlüsselung macht alles sicherer – und die Rettung anspruchsvoller.

• Wenn BitLocker im Gast aktiv ist, brauchen Sie Recovery-Key/TPM-Kontext.
• Ein reines Kopieren der VHDX bringt dann nur verschlüsselte Blöcke.

Heißt nicht „hoffnungslos“. Heißt nur: Schlüsselmanagement ist Teil der Rettung. Und genau da trennt sich „schnell probieren“ von „sauber wiederherstellen“.

Typische Ursachen – und wie Sie sie künftig vermeiden

Ein paar Klassiker, die immer wieder auftauchen:

• Datastore läuft voll (Snapshots wachsen heimlich)
• Host verliert Strom oder wird hart ausgeschaltet
• Storage-Latenzen → Timeouts → inkonsistente Writes
• Snapshot-Spam: „Nur kurz“, „nur zur Sicherheit“, „nur noch einen“
• Backup ohne Restore-Test (das tut beim Ernstfall extra weh)

Praktische Vorbeugung, die nicht nervt:

• Snapshot-Regeln: kurz, dokumentiert, automatisches Aufräumen
• Monitoring: Storage-Füllstand + Snapshot-Alarme
• Backups: 3-2-1, und ja: Restore testen

Wann lohnt sich der Profi-Weg (und wann ist DIY ok)?

DIY ist oft ok, wenn:

• Sie ein frisches Backup haben und nur schnell zurückspielen müssen.
• Die VM-Dateien vollständig sind und das Dateisystem „nur“ einen sauberen Check braucht – aber erst nach Kopie.

Professionelle Datenrettung ist sinnvoll, wenn:

• Snapshot-Kette unklar oder gebrochen ist.
• Container-Dateien korrupt sind.
• Storage (RAID/ZFS/LVM) mit betroffen ist.
• Business-kritische Systeme betroffen sind (ERP, Buchhaltung, Mail, Projekte).

Und ja: Viele Kund:innen aus Potsdam, Teltow oder Köpenick kommen genau dann, wenn’s nicht nur um Dateien geht – sondern um Betriebsfähigkeit.

Kurz-Checkliste zum Mitnehmen

• [ ] VM stoppen, Autostart aus
• [ ] VM-Ordner vollständig kopieren (inkl. Snapshots)
• [ ] Nur mit Kopie arbeiten, Original unangetastet lassen
• [ ] Ursache eingrenzen: Container / Dateisystem / Snapshot / Storage
• [ ] Wenn unklar: nicht „herumklicken“, sondern strukturiert vorgehen

CTA: Wenn Ihre VM gerade brennt – lassen Sie uns das sauber lösen

Sie wollen keine weiteren Risiken eingehen und brauchen eine klare Einschätzung, ob Ihre VHDX/VMDK/QCOW2 noch zu retten ist? Dann melden Sie sich – mit ein paar Eckdaten (Hyper‑V/VMware/Proxmox, Snapshot ja/nein, Fehlermeldung, Größe des Datastores) können wir oft schnell sagen, welcher Weg sinnvoll ist.

bizIT (Standort: bizIT)

Heidelberger Str. 64a , 12435 Berlin

Telefon: +49 30 588008800

Website: https://www.bizit.de/