How Does VMware Cloud Backup Work?

VMware cloud backup isn’t a single product you buy from VMware. It’s an architecture where VMware’s own APIs, backup software such as Veeam, and cloud or off-site storage work together to protect your VMs.

The backup software connects to vCenter Server, or directly to an ESXi host, giving it visibility into the VMs, disks, datastores, and configuration it needs to protect, without touching each guest OS by hand. Most of this runs through VMware’s vSphere Storage APIs for Data Protection, or VADP, which lets a central backup server or proxy protect VMs without an agent inside every guest. It also keeps heavy lifting off the production ESXi host, so workloads aren’t slowed during a backup.

When a backup job starts, the backup application asks vCenter or ESXi to take a VMware snapshot, freezing a clean, point-in-time view of the VM while the machine keeps running for users.

The VM’s original disks go read-only while new writes are redirected into temporary delta files, so the proxy reads a stable copy without shutting the VM down.

It is important to note that a snapshot is not a backup. It depends on the original VM disk and mostly records changes made after it was created, so if you lose the base disk or datastore, the snapshot files alone can’t bring the VM back. 

According to Broadcom’s guidance, don’t treat snapshots as backups, don’t hold one longer than 72 hours, and while vSphere supports up to 32 snapshots in a chain, two or three is the practical limit before performance suffers. Remove backup-created snapshots once the job finishes.

A VMware image-based backup protects the machine at the virtualization layer instead of copying files one at a time. That single image holds the virtual disk data, VM configuration, operating system, installed applications, and settings, which is everything needed to rebuild the machine from one recovery point.

A backup proxy moves that data out, traveling through direct storage or SAN access, a HotAdd virtual appliance, network transport like NBD or NBDSSL, or storage snapshot integrations. Along the way, the software usually compresses, deduplicates, encrypts, and filters out unneeded blocks.

However, a running image isn’t automatically a clean one. A crash-consistent backup captures the VM like a physical server after a power cut: fine for a basic file server, risky for a busy database. 

Application-consistent backups go further, coordinating with the application first through VSS on Windows or guest-level processing on Linux so transactions aren’t caught half-finished. Don’t assume every backup is application-consistent; that depends on your configuration, the guest OS, VMware Tools, and the application itself.

The first backup of a VM is almost always a full baseline. Rereading every block on every disk for every job after that would be wasteful, which is the problem Changed Block Tracking solves.

CBT records which disk blocks have changed since the last backup. The platform queries that record through VMware’s APIs and copies only the changed or newly written blocks, which means shorter backup windows, far less traffic, and the freedom to take restore points more often.

For example, a VM might hold 2 TB of provisioned data, but only 25 GB changes between jobs. The first backup protects the full used image; the next uses CBT to move only that 25 GB, before compression and deduplication shrink it further.

Once processed, the backup is written to a repository that sits apart from production storage, often object storage such as Amazon S3 or Azure Blob, and similar S3-compatible targets.

How you arrange it is a design choice. Some teams go direct-to-cloud; others keep a fast local repository for recent restore points and run a copy job offsite. Tiered setups age older backups into cheaper archive tiers, while a service-provider repository hands that capacity to you as a managed service.

Whatever the model, immutability and isolation matter most. An immutable repository stops backups from being altered or deleted during their retention window, and keeping the cloud copy separate from production storage means one ransomware hit or storage failure can’t take out both. 

This is where OTAVA Cloud Connect fits in, copying your Veeam backups into OTAVA’s cloud with immutable, air-gapped targets and end-to-end encryption.

Backup and replication often get lumped together, but they solve different problems: Backup creates retained recovery points you can reach back to, while replication keeps a standby VM ready to take over.

The catch is that replication doesn’t replace backup. If corrupted or encrypted data replicates to the secondary site, your replica is just as broken as the original. Retained, immutable backup points give you a separate path back that replication alone can’t

Recovery starts with a question: What needs to come back? That answer shapes everything, because restoring a whole server to recover one deleted file is wasted effort.

So you scope it first, whether that’s a file, an application item, a virtual disk, a whole VM, or several dependent VMs, then choose a restore point. The newest one isn’t always safest; after a ransomware event, you may need an earlier, clean point from before the attacker got in. Then you pick a destination, run the restore, and validate before going back to production.

The restore takes a few forms. File-level recovery mounts the backup so you can copy individual files back, while application-item recovery reaches into databases or mailboxes for specific objects. You can also restore a single virtual disk or rebuild the entire VM. Instant VM recovery boots the VM straight from its backup files, online in minutes, then migrates to production storage later. And if a standby replica exists, you simply fail over to it.

The last habit matters most: testing. A successful backup job proves data was written; only a restore test proves you can get it back.

Is a VMware snapshot the same as a backup? 

No. A snapshot records changes made after it’s taken and depends on the original base disk, so it can’t restore a VM on its own if that disk is lost. Broadcom also advises against keeping any single snapshot longer than 72 hours.

What is Changed Block Tracking in VMware backup? 

Changed Block Tracking, or CBT, records which disk blocks have changed since the last backup. Backup software queries it to copy only those blocks instead of the whole disk, making incremental backups faster and much lighter on your network and storage.

Does VMware Cloud Backup replace replication? 

No. Backup keeps retained recovery points for historical and ransomware recovery, while replication maintains a standby VM for fast failover. They cover different risks, so most resilient setups use both.

At OTAVA, we help you back up VMware workloads to our secure, compliant cloud with immutable, air-gapped copies and fast VM-level recovery, so a clean restore point is always within reach. Talk to an OTAVA expert about a Cloud Connect or DRaaS plan built around the workloads that matter most to you.