What Happens to Your VMware Backups When You Leave vSphere

Every VMware® exit plan we see counts the virtual machines. Some of them count the desktops. Very few of them count the restore points.

That is the expensive omission, because the backup estate is not a feature of the platform you are leaving. It is a separate product, with its own licensing, its own hardware, its own retention policy, and its own auditor. It happens to be plugged into vSphere in four specific places, and all four of those plugs come out when the hypervisor changes. What looked like one migration turns into two, and the second one is discovered late, usually by the person who has to sign the data-protection attestation.

This post takes the backup half of the estate and runs the same translation the rest of this series runs for server features: what the mechanism actually did, what does the equivalent job on the destination platform, and which parts of the answer are decided by a storage choice rather than a platform choice. It follows the vMotion and Storage vMotion translation, the HA, DRS and Fault Tolerance translation and the VDI desktop translation.

One scoping line before anything else, because the rest of the post depends on it being said plainly. Simplyblock is not a backup product and does not replace one. Catalog, indexing, granular file-level restore, retention policy, long-term tiering and compliance reporting are backup-product functions and they stay that way. What a storage layer changes is what the backup product has to do to get a consistent point-in-time copy in the first place, and that single change is what decides whether your second migration is a rebuild or a reconnection.

The four things your backup estate is actually plugged into

A vSphere backup deployment looks like one product from the console. Structurally it is four separate dependencies on the hypervisor, and they fail independently.

The hypervisor backup API. Your backup product does not read virtual disks off a datastore by itself. It asks vSphere to quiesce the guest, take a VM-level snapshot, and expose the disks for reading, then release the snapshot when the copy is done. That whole conversation is a vSphere API contract. It has no counterpart on the other side, because on Kubernetes there is no host to ask.

Changed block tracking. The reason your nightly job finishes in twenty minutes instead of nine hours is that vSphere maintains a per-disk map of which blocks changed since a given point, and hands that map to the backup product on request. The map lives with the VM, in vSphere. It does not travel. On the day you cut over, every workload’s delta map is empty, which is why the first job on the new platform is a full copy of everything, and why the network and repository sizing for that first week looks nothing like steady state.

The proxy topology and transport mode. Backup proxies exist because somebody had to solve the question of how the copy gets from the datastore to the repository without going through the management network. Direct SAN access, hot-add of the snapshot disks to a proxy VM, or network transport over the management path: each is a different set of hosts, zoning, and firewall rules that were designed around the vSphere data path. None of that geometry survives when the data path becomes a fabric and a CSI driver.

The chain format and everything expressed in it. Full plus incremental chains, synthetic fulls, retention counts, immutability windows and the restore-test procedure are all written in terms of the backup product’s own file format. Those files remain readable. What they do not do is accept new increments from a workload that no longer exists as a vSphere VM. The chain stops, and the clock on your retention policy starts running against a repository that is now historical.

Here is the row-by-row translation, including the column most migration plans skip.

Table 1: The four hypervisor dependencies inside a VMware backup estate, and what each becomes after the exit.

The pattern in that last column is the point. Two of the five rows are things a storage layer can genuinely take over. Three of them are process, product configuration and audit work that nobody else can do for you. A vendor claiming to solve the whole table is selling you something, and the honest version of this conversation is more useful to a backup administrator than the optimistic one.

Working out how many restore points you have to carry across a vSphere exit? Talk to us when the backup window, the first-full sizing and the parallel-run overlap are the parts of the migration plan that still have question marks in them. Talk to a storage architect

Why the incremental primitive is the whole argument

Strip the table down and one row decides the shape of everything else: where the point-in-time copy is taken.

In the vSphere model it is taken above the guest, by the hypervisor, on request from the backup product. That is why it is hypervisor-specific, and it is why changing hypervisors invalidates it. If your destination platform is KubeVirt or Red Hat® OpenShift® Virtualization, you can reproduce something similar at the VM layer, and the platforms do offer VM-level snapshot objects with guest-agent freeze and thaw for application consistency. But you have now rebuilt the same dependency one platform over, and you will do this again the next time the platform changes.

The alternative is to take the copy beneath the guest, at the volume. A CSI snapshot on simplyblock is a point-in-time copy of the block volume itself. The guest is not asked to participate beyond an optional filesystem freeze for consistency, and the hypervisor is not asked to participate at all. The consequences are worth stating one at a time:

• The primitive is the same on every platform above it. KubeVirt VMs, OpenShift Virtualization VMs, bare-metal Kubernetes pods and containerized databases all get their point-in-time copy from the same place, which means one snapshot policy covers a mixed estate rather than one per platform.
• It survives the next migration too. The reason this migration is painful is that the previous generation’s copy mechanism was welded to the hypervisor. Moving it to the volume layer is the change that stops the problem recurring.
• It is independent of the deployment model. Whether simplyblock runs hyperconverged on the same nodes as the workloads or as a separate storage tier over an NVMe/TCP or NVMe/RoCE fabric, the snapshot semantics do not change.
• It does not make simplyblock your backup. A snapshot on the same system as the source volume is a fast restore point, not an off-platform copy. It still has to be read by a mover and written somewhere with a different failure domain before it counts as a backup to anybody who audits you.

On the delta side, be careful about what you promise your capacity planner. The Kubernetes ecosystem has been standardizing an interface for retrieving changed-block metadata between two snapshots, so that a mover can copy only what changed instead of re-reading whole volumes. Treat its availability as a question to ask about your specific driver, your specific mover, and your specific cluster version, not as an assumption. Verify it against current documentation before you size the backup window on it, because the difference between delta-aware and full-read incrementals is the difference between a nightly job and a weekend job.

Planning the overlap, which is the part that surprises people

The two estates run at the same time. That is not a failure of planning, it is arithmetic, and the arithmetic is usually longer than the migration itself.

Your retention policy says something like thirty-five daily restore points, twelve monthly, and seven annual. Those restore points live in the old repository, in the old chain format, readable only by the old backup infrastructure. The moment the source VM stops existing on vSphere, that chain gets no new increments. But you cannot decommission the repository, the licenses or the proxies until the longest retention obligation on the oldest workload has expired. If you have a seven-year regulatory hold on anything, the honest plan says the old estate stays reachable for seven years, or it says you are paying to migrate historical restore points into a new format, which is a project of its own with its own validation burden.

Three practical consequences, in the order they bite:

1. Size the first full copy, not the steady state. Every migrated workload’s first job on the new platform is a full read. If you cut over in waves, the read load lands in waves, and the fabric and repository ingest have to absorb a peak that steady-state sizing never sees. Stagger the waves against the backup window, not only against the maintenance window.
2. Decide the read-only cutoff date per workload, in writing. For each workload, name the date after which the old chain is restore-only. Without that date, teams keep both estates running “just in case” and the parallel-run cost quietly becomes permanent.
3. Re-run the restore test on the new platform before you trust it. A backup that has never been restored is a hypothesis. The disaster recovery runbook you had for vSphere describes booting a VM from a restore point in an environment that no longer exists. Rewriting it is unavoidable, and doing it before the cutover rather than after is the cheap version.

There is a design decision hiding in point two. If your new-platform restore points come from volume-layer snapshots on a storage tier that is independent of the compute nodes, then a restore is a volume operation followed by a VM start, and it does not depend on which node is free or which hypervisor build you are running. That is the operational property worth optimizing for, and it is the same property that makes day 2 storage operations after a VMware exit tractable in general.

Where storage stops and the backup product starts

It is worth being blunt about the boundary, because the buyers who take this topic seriously are the ones who will notice if a vendor blurs it.

A storage layer gives you the copy. It can give you a consistent point in time, cheaply, frequently, and without asking the hypervisor for permission. On simplyblock those snapshots are thin, so keeping many of them costs capacity proportional to change rather than to volume size, and the licensing follows usable capacity rather than CPU cores, which means a denser node does not cost you more to protect. Independent scaling of the storage tier means the backup repository target and the primary pool grow on their own schedules.

A backup product gives you everything that makes the copy usable a year later: the catalog that knows what is in it, the index that finds a single file inside a VM disk, the retention engine, the immutability enforcement, the off-platform copy, the reporting your auditor reads. None of those are storage functions. If you replace your backup product during a VMware exit, do it as a deliberate, separately scoped decision with its own restore testing, not as a side effect of changing hypervisors.

The realistic target for most teams is narrower and better than “replace everything”: keep the backup product and the policies you already validated, and change only what the product has to talk to in order to get a copy. If the copy comes from the volume layer, the answer to “does our backup product support the new platform” stops being a question about hypervisor plug-ins and becomes a question about whether it can read a snapshot, which is a much easier question to get a yes to. For the destination-side design work, the companion piece on backup and restore for KubeVirt VM workloads covers the tooling and consistency mechanics in detail, and the migration guide for moving VMware VMs to KubeVirt covers the disk side of the same cutover.

Questions and Answers

What happens to my existing VMware restore points when I migrate off vSphere?

They stay readable in the old repository and stop receiving new increments. That is the core planning problem: you cannot decommission the old backup infrastructure until the longest retention obligation on the oldest protected workload expires, so budget for a parallel run measured in your retention period rather than your migration timeline. Give each workload an explicit date after which its old chain is restore-only, otherwise both estates run indefinitely.

Does changed block tracking work after a move to KubeVirt or OpenShift Virtualization?

Not in the form you have today. Changed block tracking is a vSphere mechanism and its delta maps do not migrate, so the first job for every workload on the new platform is a full copy. On the destination side, the Kubernetes ecosystem has been standardizing an interface for changed-block metadata between snapshots, but availability depends on your CSI driver, your data mover and your cluster version. Verify all three against current documentation before you size the backup window around delta-aware incrementals.

Is simplyblock a backup product?

No, and it should not be sold to you as one. Simplyblock provides the point-in-time copy at the volume layer through CSI snapshots and clones, which is the primitive a backup product needs in order to read a consistent image. Catalog, indexing, file-level restore, retention policy, immutability enforcement and compliance reporting remain backup-product functions. The value of moving the primitive down to the volume is that it works identically under KubeVirt, OpenShift Virtualization, bare-metal Kubernetes and containerized workloads, so you rebuild your protection design once instead of once per platform.

Why take the snapshot at the volume layer instead of the VM layer?

Because a VM-layer snapshot recreates the same hypervisor dependency that made this migration expensive. A volume-layer snapshot is taken beneath the guest, so it is unaffected by which virtualization platform sits above it and by whether the deployment is hyperconverged or uses a separate storage tier over an NVMe fabric. VM-layer snapshots are still useful for application-consistent quiesce through the guest agent, and the two compose: freeze the guest filesystem, take the volume snapshot, thaw.

How should I size the first backup cycle after a cutover?

For a full read of every migrated workload, not for your steady-state incremental load. Because every delta map starts empty on the new platform, the first cycle after each migration wave is a complete copy, and if you migrate in waves those full reads stack up against the backup window. Stagger the migration waves against backup capacity as well as against maintenance windows, and confirm the repository ingest rate and fabric bandwidth can absorb the peak rather than the average.

Can I keep my existing backup software after leaving VMware?

Often yes, and it is usually the cheaper path. Changing hypervisor and changing data-protection product in the same quarter means revalidating two things at once, which is exactly what the audit process punishes. Check what your existing product supports on the destination platform, and note that if the copy comes from a CSI snapshot at the storage layer rather than a hypervisor API, the compatibility question narrows to whether the product can read a snapshot-backed volume. Whatever you conclude, re-run a full restore test on the new platform before you retire the old runbook.