VMware Backup: Image-Level Options and What to Test

Updated: October 2026

A VMware host can run twenty servers, and one bad night can take all twenty with it. Copying files out of each guest doesn't scale, and a snapshot on its own won't save you. Here's how VMware backup works at the image level, which transport and consistency settings matter, and what to test before you trust a restore.

How Image-Level VMware Backup Works

Image-level backup copies the whole virtual machine, disks and configuration, from the host side. You don't install a backup agent in every guest. The backup software talks to vCenter or the ESXi host through the vSphere storage APIs for data protection, usually shortened to VADP.

A backup job runs the same four steps every time:

1. The backup software asks vSphere to take a snapshot of the VM. The disks freeze at that moment and new writes go to a delta file.
2. It reads the frozen disks through a transport mode (more on those below).
3. It asks Changed Block Tracking which blocks changed since the last run, and copies only those.
4. It deletes the snapshot, and vSphere merges the delta file back into the base disk.

Step 4 is the one people forget. Broadcom's own snapshot guidance says: "When using third-party backup software, ensure that snapshots are deleted after a successful backup."

Changed Block Tracking: Why Incrementals Are Fast

Changed Block Tracking (CBT) is what keeps a nightly backup of a large VM short. Broadcom describes it as "a VMkernel feature that keeps track of the storage blocks of virtual machines as they change over time." The backup software asks for the blocks changed since its last run and reads nothing else.

CBT keeps its map in a small -ctk.vmdk file next to each disk in the VM's folder. It needs virtual hardware version 7 or later and doesn't work on independent disks.

Two things reset it. Broadcom warns that "disabling and enabling CBT will result in full backup," and a power failure or hard shutdown can reset the change tracking too. So if a job that normally moves 20 GB suddenly moves the whole disk, check whether the host crashed or someone toggled CBT. That's also why full-versus-incremental planning matters, which our guide to incremental vs differential backup covers.

Transport Modes: SAN, HotAdd and NBD

The transport mode decides the path the data takes from the datastore to the backup server. It's the biggest single factor in backup speed after CBT.

Broadcom's programming guide calls SAN "the fastest transport method for software deployed on SAN-connected ESXi hosts." HotAdd works only with SCSI virtual disks, not IDE. NBD is the fallback when nothing else is available, and the guide notes "NBD is faster and consumes fewer resources than NBDSSL."

For a small cluster, HotAdd through a proxy VM is usually the sweet spot. If backups crawl, check the job log for the mode the job used. A silent fallback to NBD is a common cause of slow VMware backup jobs.

Crash-Consistent vs Application-Consistent

A plain snapshot is crash-consistent. It captures the disk the way a sudden power cut would. Windows boots from it fine, but a database in the middle of a write may need recovery, or may lose the last transactions.

Application-consistent backup asks the guest to flush first. On Windows, VMware Tools calls the Volume Shadow Copy Service (VSS), and SQL Server, Exchange and Active Directory writers put their data in a clean state before the snapshot. Broadcom notes that the VM setting disk.EnableUUID must be true for this to work, because VSS needs to match each virtual disk to its volume.

When quiescing fails, the job either errors or falls back to a crash-consistent copy. Broadcom lists the usual causes: a broken VSS writer, a third-party VSS provider getting in the way, or services that aren't running. The error to watch for says the snapshot "exceeded the time limit for holding off I/O in the frozen virtual machine." Your backup report should show which VMs got application-consistent copies. If it doesn't, you don't know.

Domain controllers get one extra safeguard. Since Windows Server 2012, a DC checks a VM-Generation ID from the hypervisor. After a restore from an old image, the ID won't match, so the DC resets its invocation ID and discards its RID pool. Microsoft built this to stop the USN rollback that used to wreck replication after a snapshot restore.

Snapshot Pitfalls That Break VMware Backups

A snapshot is not a backup. Broadcom's guidance is blunt: "The snapshot file is only a change log of the original virtual disk." Lose the base disk and the snapshot is worthless.

The same guidance sets the limits. vSphere supports up to 32 snapshots in a chain, but Broadcom recommends 2 to 3 for performance and says not to keep a single snapshot for more than 72 hours. The delta file keeps growing the longer it lives, and it can fill the datastore.

Backup jobs are a common source of forgotten snapshots. A job fails halfway, the delete step never runs, and a delta file grows for weeks. Add a daily check for snapshots older than a day, and alert on any VM that needs consolidation. Broadcom also warns never to cancel a running consolidation, because it "can lead to data corruption."

Restore Options: Full VM, Instant Recovery and File-Level

A good VMware backup gives you three ways back, and each fits a different bad day.

Full VM restore writes the whole machine back to a datastore. It's the cleanest option and the slowest, because every block has to travel.

Instant recovery boots the VM straight from the backup storage, then moves it to production storage in the background with Storage vMotion. Users are back in minutes, but the VM runs slowly until the move finishes.

File-level restore mounts the backup and pulls out a single file or folder. For SQL, Exchange and AD, application-aware tools can pull out a database, a mailbox or an object without restoring the server.

If restoring on your own hardware still takes too long, disaster recovery as a service moves the failover to a provider's cloud. Pick the restore type in your runbook before you need it. The choice sets your recovery time far more than the backup product does.

Test the Restore, Not the Job

A green backup job proves the data was copied. It doesn't prove the VM boots, the database mounts or the application answers. This r/sysadmin thread asks the question every team hits: is booting the restored VM enough, or do you test the services on it?

The replies land on levels. Level one: the VM powers on, the OS boots, you can sign in, and the file system is clean. Level two: the application works. Open files on the file server, run a query on the SQL box, check the domain controller replicates.

Run level one on a schedule for every VM, in an isolated network so the restored copy doesn't clash with production. Run level two for the systems the business can't live without. Write down how long each restore took, because that number is your real recovery time. Our disaster recovery testing guide covers the wider test types. OpenFrame can run a post-restore check script across a client's devices and collect the output in one place.

What Broadcom Changed for VMware Backup

The Broadcom era changed two things that affect backup.

First, the free hypervisor can't be backed up the normal way. Broadcom made ESXi 8.0 Update 3e (released 10 April 2025) available as a free hypervisor again, but its own knowledge base lists "No access to vMotion, DRS, HA, VADP-based backups" and no vCenter management. It's meant for labs. If a client runs production on free ESXi, image-level backup tools can't use the storage APIs, so you're back to shutting VMs down and copying files.

Second, the Virtual Disk Development Kit (VDDK), the library backup and migration tools use to read VM disks, stopped being a public download in August 2026. The Register reported on 10 September 2026 that access continues "through select TAP for its licensed use case, which has always been backup and recovery." Established backup vendors are covered. Smaller migration tools and open-source projects that relied on the download are not.

If you're weighing a move off VMware, check that your backup product supports the target hypervisor before you migrate, not after. Our guide to what virtualization is covers the hypervisor options.

VMware Backup Tools

The common image-level VMware backup products share the same plumbing: VADP, CBT and the same transport modes. Veeam Backup & Replication, Commvault, Veritas NetBackup, Nakivo, Vinchin and Acronis all work this way. They differ in restore features, licensing, storage targets and how well they report on application consistency.

When you compare them, ask four questions. Which transport modes does it support in your setup? Does it report per VM whether the copy was application-consistent? Can it run instant recovery and file-level restore? Can it test restores automatically in an isolated network? Our Veeam review goes deeper on one of them.

Charles Chow's short explainer covers the difference between snapshots, backups and replication, three things that often get treated as one.

VMware Backup, in Short

Image-level VMware backup is snapshot, read, track changes, delete. Get CBT working, check which transport mode your jobs really use, and make application-consistent copies for anything with a database. Keep snapshots short-lived, and prove each backup with a timed restore, not a green job. For the wider picture on protecting client data, read our guide to MSP backup solutions.