Proxmox move: the way back to VMware stays unbuilt
In VMware-plus-Proxmox estates, the way back to ESXi remains the hard case: two to four hours plus half a day for network and commissioning.
A mixed estate of VMware and Proxmox can deliver green backups at night. Once the production data is on Proxmox, a dependable way back is often missing. The hard case takes two to four hours for the restore plus half a day for network and commissioning until the machine responds again on ESXi.
With insights from Sergei Serdyuk, VP of Product Management, NAKIVO
Key takeaways
- The bitmap dies with the process. VMware CBT survives reboot and vMotion on the datastore. The QEMU dirty bitmap lives in the memory of the running process and fails after a guest reboot, a host reboot or a live migration.
- Green counts blocks read. A successful job does not prove recoverability. Two tests remain for that: a restore until the machine answers and an immutability window that reaches further than the plausible dwell time.
- The hard way back takes hours. When production is on Proxmox, the login on ESXi only comes back after the restore and the network work.
Related:VMware is gone, the backup didn’t come along / VMware price shock: DACH companies face a hard choice
What is Changed Block Tracking? CBT is VMware’s persistent map of changed blocks on the datastore. It survives reboot and vMotion. The QEMU dirty bitmap takes on the same role under Proxmox and lives in the memory of the running process.
| Situation | Time until login |
|---|---|
| Unfinished migration, VMware original still running | Minutes |
| Hard 2 TB restore back to ESXi | 2 to 4 hours plus half a day for network and commissioning |
Source: Sergei Serdyuk, written answers, September 17, 2026.
The bitmap that doesn’t survive the reboot
VMware places Changed Block Tracking on the datastore. The map survives power-cycle, reboot and vMotion because it lives on disk alongside the virtual machine. Under Proxmox, the QEMU dirty bitmap takes on the same role and lives in the memory of the running QEMU process. When the process ends, the map ends.
The first night after the cutover is deceptive here. To the backup product, the migrated machine is a new object. The first run is therefore a planned full, no matter how well CBT worked on the VMware side beforehand. It becomes unplanned later: after a guest reboot, a host reboot or a live migration, the volatile bitmap is missing. The next incremental run reads the entire disk again. The job then runs at full size in a window sized for incrementals. In that week, it looks like an outlier. In truth, the map is dead.
Proxmox VE 9.0 provides persistent bitmaps in qcow2. Vendors are catching up. Ceph RBD and raw ZFS have no storage location for them; there, the map remains volatile. The data mover typically runs on the Proxmox host and shares the CPU with the production guests. Products throttle parallelism well below what a VMware proxy gets. Per disk in flight, the host needs a free NBD. When the devices are used up, the job fails instead of queuing. More disks in a single run mean more open NBD channels and more load on the same host that is already doing the computing for the guests.
Green counts the blocks read
A green backup-job result means: the product has read the blocks it was supposed to read. It has written them. Whether a bootable machine can be built from that is not what this status measures. The copy can be crash-consistent even though the application needed app-consistent. The repository can degrade. One bad point in a Forever-Incremental chain drags everything after it down. Ransomware can hit the stored backups. Retention can clear out the last good point. The key may reside only in the very system that is to be restored. After a platform change, the copy can be fine and the restore path still be missing.
Two tests replace the assumption. The first is verification: restore, boot, response of the machine. The second is immutability: a window that reaches further than the time it takes to notice an intrusion. Teams that run regular drills find the gap at the next rehearsal, often during the migration rehearsal. Smaller operations find it in the real emergency, when the machine is supposed to run again. In both cases the status in the dashboard stays green until someone actually runs the restore.
The way back to ESXi takes hours
As long as the migration is unfinished, the easy way remains open. The VMware original still exists. The Proxmox machine shuts down, the VMware machine starts and login is back within minutes. The hard case is the opposite situation: the migration has run, the virtual machine has accumulated production data on Proxmox and the current state has to go back to ESXi. That is a cross-platform restore.
For a conventional restore of 2 TB, Serdyuk names two to four hours, plus another half day for networking and the rest of commissioning until login is up. Translating the virtual hardware is the backup product’s job: disk format, storage controller, network adapter, firmware mode, boot order. The product creates the machine the way ESXi expects it. It installs the drivers. Without this path, the current data state stays on Proxmox and never makes it back to ESXi. Anyone who looks for the way back only after the cutover looks for it under time pressure and with a grown data volume.
The planned move stays the easy case
Proper migrations with POC, sign-off and failback catch the majority of migration errors. Anyone thinking in POC, sign-off and failback keeps the VMware original until the trial run on Proxmox succeeds. The first night remains a planned full. Persistent bitmaps in qcow2 under Proxmox VE 9.0 shorten the later unplanned full runs. For the backup product, compatibility is a smoke test and it is quick. Full Support means regression across storage, restore and cross-version restore; only after that comes shipping.
The supported-versions list applies before apt. Until full support ships, one canary node stays in the window and high-value machines stay elsewhere. The first backup after the upgrade only counts as a restore point once something has been restored from it. An upgrade that coincides with the retention rollover lets the last good point expire while it is still open whether the new one holds.
An immutability window shorter than the time it takes to notice a breach is the misconfiguration Serdyuk describes. The attacker stays for two months. They delete backups outside the lock window. Everything inside the lock was written after the compromise. The window has to reach further than the plausible dwell time. Recovery points need a malware scan. The cheapest test remains a restore of a machine from a point older than expected, 45 or 60 days back, using only the local account of the backup system, with the domain treated as untrusted.
Frequently asked questions
Why is the first backup after the cutover a full?
The migrated machine is a new object for the backup product. The first run after the switch to Proxmox is therefore a planned full, regardless of the CBT history on VMware.
What does a green backup-job result prove?
It proves that the requested blocks were read and written. This status does not check boot, application or network. For that, what remains is a restore up to the machine’s response and an immutability window that extends beyond the plausible dwell time.
How long does the return path of a 2 TB file server to ESXi take?
In the unfinished migration state, minutes, because the VMware original is still running. In the hard case with production data on Proxmox, Serdyuk names two to four hours for the restore and another half day for the network and the rest of commissioning, until the login is up.
Is the dirty bitmap preserved under Proxmox VE 9.0?
In qcow2, Proxmox VE 9.0 provides persistent bitmaps. Ceph RBD and raw ZFS have no storage location for them.
Which immutability window does Serdyuk describe as a misconfiguration?
A window that is shorter than the time it takes to notice an intrusion. As a pattern, he names a two-month dwell. The test: a restore going back 45 or 60 days, a local backup account, an untrusted domain.
Editor’s Picks
cloudmagazinHashiCorp gives machine images a provenance recordcloudmagazinKarmada with the highest CNCF seal: Bloomberg joins incloudmagazinCloud repatriation: When bringing it back pays offMore from the MBF Media Network
MyBusinessFutureVendors report CRA incidents to ENISA before the CSIRTDigital ChiefsFederal Chancellery: 3000 employees switch to openDeskSecurityTodayScreenConnect client executes files without host OKImage source: AI-generated (September 2026)
Also available in
