Proxmox-Umzug: VMware-Rückweg bleibt ungebaut
In VMware-plus-Proxmox-Beständen bleibt der Rückweg auf ESXi der harte Fall: zwei bis vier Stunden plus ein halber Tag Netz.
Ein gemischter Bestand aus VMware und Proxmox kann nachts grüne Sicherungen liefern. Sobald die Produktionsdaten auf Proxmox liegen, fehlt oft ein belastbarer Rückweg. Der harte Fall braucht zwei bis vier Stunden für die Rücksicherung plus einen halben Tag für Netz und Inbetriebnahme, bis die Maschine auf ESXi wieder antwortet.
Mit Einschätzungen von Sergei Serdyuk, VP of Product Management bei NAKIVO
Das Wichtigste in Kürze
- Die Bitmap stirbt mit dem Prozess. VMware-CBT überlebt Reboot und vMotion auf dem Datastore. Die QEMU-Dirty-Bitmap lebt im Speicher des laufenden Prozesses und fällt nach Gast-Reboot, Host-Reboot oder Live-Migration aus.
- Grün zählt gelesene Blöcke. Ein erfolgreicher Job belegt die Wiederherstellbarkeit nicht. Dafür bleiben zwei Tests: ein Restore bis zur Antwort der Maschine und ein Immutability-Fenster, das über die Verweildauer reicht.
- Der harte Rückweg dauert Stunden. Liegt die Produktion auf Proxmox, ist die Anmeldung auf ESXi erst nach der Rücksicherung und der Netzarbeit wieder da.
Verwandt:VMware ist weg, das Backup nicht mitgezogen / VMware-Preisschock: DACH-Firmen vor harter Wahl
Was ist Changed Block Tracking? CBT ist VMwares persistente Map geänderter Blöcke auf dem Datastore. Sie überlebt Reboot und vMotion. Die QEMU-Dirty-Bitmap übernimmt dieselbe Rolle unter Proxmox und lebt im Speicher des laufenden Prozesses.
| Lage | Zeit bis zur Anmeldung |
|---|---|
| Unfertige Migration, VMware-Original da | Minuten |
| Harter 2-TB-Rückweg auf ESXi | 2 bis 4 Stunden plus ein halber Tag für Netz und Inbetriebnahme |
Quelle: Sergei Serdyuk, schriftliche Antworten, 17. September 2026.
Die Bitmap, die den Reboot nicht überlebt
VMware legt Changed Block Tracking auf den Datastore. Die Map überlebt Power-Cycle, Reboot und vMotion, weil sie mit der virtuellen Maschine auf der Platte liegt. Unter Proxmox übernimmt die QEMU-Dirty-Bitmap dieselbe Rolle und lebt im Speicher des laufenden QEMU-Prozesses. Endet der Prozess, endet die Map.
Die erste Nacht nach dem Cutover täuscht hier. Die migrierte Maschine ist für das Backup-Produkt ein neues Objekt. Der erste Lauf ist deshalb ein geplanter Full, unabhängig davon, wie gut CBT auf der VMware-Seite vorher gearbeitet hat. Ungeplant wird es später: nach einem Gast-Reboot, einem Host-Reboot oder einer Live-Migration fehlt die flüchtige Bitmap. Der nächste inkrementelle Lauf liest die Platte wieder vollständig. Der Job hat dann Full-Größe in einem Fenster, das für Inkremente dimensioniert ist. In der Woche sieht das aus wie ein Ausreißer. In Wahrheit ist die Map tot.
Proxmox VE 9.0 stellt persistente Bitmaps in qcow2 bereit. Hersteller ziehen nach. Ceph RBD und raw ZFS haben dafür keinen Speicherort; dort bleibt die Map flüchtig. Der Data Mover läuft in der Regel auf dem Proxmox-Host und teilt sich die CPU mit den Produktionsgästen. Produkte drosseln die Parallelität deutlich unter das, was ein VMware-Proxy bekommt. Pro Disk im Flug braucht der Host ein freies NBD. Sind die Geräte aufgebraucht, schlägt der Job fehl, statt sich einzureihen. Mehr Disks in einem Lauf bedeuten mehr offene NBD-Kanäle und mehr Last auf demselben Host, der die Gäste schon rechnet.
Grün zählt gelesene Blöcke
Ein grünes Job-Ergebnis heißt: Das Produkt hat die Blöcke gelesen, die es lesen sollte. Es hat sie geschrieben. Ob sich daraus eine bootfähige Maschine bauen lässt, misst dieser Status nicht. Die Kopie kann crash-consistent sein, obwohl die Anwendung app-consistent brauchte. Das Repository kann degenerieren. Ein schlechter Punkt in einer Forever-Incremental-Kette zieht alles danach mit. Ransomware kann den Bestand treffen. Die Retention kann den letzten guten Punkt räumen. Der Schlüssel kann nur in dem System liegen, das wiederhergestellt werden soll. Nach einem Plattformwechsel kann die Kopie stimmen und der Restore-Pfad trotzdem fehlen.
Zwei Tests ersetzen die Annahme. Der erste ist Verification: Restore, Boot, Antwort der Maschine. Der zweite ist Immutability: ein Fenster, das weiter reicht als die Zeit, eine Intrusion zu merken. Teams mit Übungsbetrieb finden die Lücke bei der nächsten Probe, oft in der Migrationsrehearsal. Kleinere Betriebe finden sie im Ernstfall, wenn die Maschine wieder laufen soll. Der Status im Dashboard bleibt in beiden Fällen grün, bis jemand den Restore ausführt.
Der Rückweg auf ESXi dauert Stunden
Solange die Migration unfertig ist, bleibt der leichte Weg offen. Das VMware-Original existiert noch. Die Proxmox-Maschine endet, die VMware-Maschine startet, die Anmeldung ist in Minuten wieder da. Der harte Fall ist die gegenteilige Lage: Die Migration ist gelaufen, die virtuelle Maschine hat auf Proxmox Produktionsdaten gesammelt, der aktuelle Stand muss zurück auf ESXi. Das ist ein Cross-Platform-Restore.
Für eine konventionelle Rücksicherung von 2 TB nennt Serdyuk zwei bis vier Stunden und einen weiteren halben Tag für Netz und den Rest der Inbetriebnahme, bis die Anmeldung steht. Die Übersetzung der virtuellen Hardware ist Aufgabe des Backup-Produkts: Disk-Format, Storage-Controller, Netzadapter, Firmware-Modus, Boot-Reihenfolge. Das Produkt legt die Maschine so an, wie ESXi sie erwartet. Es spielt Treiber ein. Ohne diesen Pfad bleibt der aktuelle Datenstand auf Proxmox und kommt nicht zurück auf ESXi. Wer den Rückweg erst nach dem Cutover sucht, sucht ihn unter Zeitdruck und mit gewachsener Datenmenge.
Der geplante Umzug bleibt der leichte Fall
Ordentliche Migrationen mit POC, Freigabe und Failback fangen den Großteil der Migrationsfehler ab. Wer in POC, Freigabe und Failback denkt, hält das VMware-Original, bis die Probe auf Proxmox gelingt. Die erste Nacht bleibt ein geplanter Full. Persistente Bitmaps in qcow2 unter Proxmox VE 9.0 verkürzen die später ungeplanten Full-Läufe. Beim Backup-Produkt ist Compatibility ein Smoke-Test und geht schnell. Full Support heißt Regression über Storage, Restore und Cross-Version-Restore, danach erst Shipping.
Die Supported-Versions-Liste gilt vor apt. Bis Full Support steht, bleibt ein Canary-Node, hochwertige Maschinen liegen woanders. Das erste Backup nach dem Upgrade zählt erst als Restore-Punkt, wenn davon restored wurde. Ein Upgrade, das mit dem Retention-Rollover zusammenfällt, lässt den letzten guten Punkt verfallen, während noch offen ist, ob der neue trägt.
Ein Immutability-Fenster kürzer als die Zeit, einen Einbruch zu merken, ist die Fehlkonfiguration, die Serdyuk beschreibt. Der Angreifer bleibt zwei Monate. Er löscht Sicherungen außerhalb des Lock-Fensters. Alles im Lock ist nach der Kompromittierung geschrieben. Das Fenster muss weiter reichen als die plausible Verweildauer. Recovery-Punkte brauchen einen Malware-Scan. Der günstigste Test bleibt ein Restore einer Maschine aus einem Punkt älter als gedacht, 45 oder 60 Tage zurück, nur über das lokale Konto des Backup-Systems, mit der Domain als untrusted.
Häufige Fragen
Warum ist die erste Sicherung nach dem Cutover ein Full?
Die migrierte Maschine ist für das Backup-Produkt ein neues Objekt. Der erste Lauf nach dem Wechsel auf Proxmox ist deshalb ein geplanter Full, unabhängig von der CBT-Historie auf VMware.
Was belegt ein grünes Job-Ergebnis?
Es belegt, dass die angeforderten Blöcke gelesen und geschrieben wurden. Boot, Anwendung und Netz prüft dieser Status nicht. Dafür bleiben Restore bis zur Antwort der Maschine und ein Immutability-Fenster über der Verweildauer.
Wie lange dauert der Rückweg eines 2-TB-Fileservers auf ESXi?
Im unfertigen Migrationsstand Minuten, weil das VMware-Original noch läuft. Im harten Fall mit Produktionsdaten auf Proxmox nennt Serdyuk zwei bis vier Stunden für die Rücksicherung und einen weiteren halben Tag für Netz und den Rest der Inbetriebnahme, bis die Anmeldung steht.
Bleibt die Dirty-Bitmap unter Proxmox VE 9.0 erhalten?
In qcow2 stellt Proxmox VE 9.0 persistente Bitmaps bereit. Ceph RBD und raw ZFS haben keinen Speicherort dafür.
Welches Immutability-Fenster beschreibt Serdyuk als Fehlkonfiguration?
Ein Fenster, das kürzer ist als die Zeit, eine Intrusion zu merken. Als Muster nennt er zwei Monate Verweildauer. Der Test: Restore 45 oder 60 Tage zurück, lokales Backup-Konto, Domain untrusted.
Lesetipps der Redaktion
cloudmagazinHashiCorp gibt Machine Images einen HerkunftsnachweiscloudmagazinKarmada mit höchstem CNCF-Siegel: Bloomberg fährt mitcloudmagazinCloud-Repatriation: Wann sich Rückholen rechnetMehr aus dem MBF Media Netzwerk
MyBusinessFutureHersteller melden CRA-Vorfälle an ENISA vor dem CSIRTDigital ChiefsBundeskanzlei: 3000 Beschäftigte wechseln auf openDeskSecurityTodayScreenConnect-Client führt Dateien ohne Host-OK ausBildquelle: KI-generiert (September 2026)
Auch verfügbar in
