VMware vSphere runs a significant share of the world’s virtualized infrastructure. For most organizations using VMware, the virtual machines running on ESXi hosts hold the applications, databases and data that the business depends on daily. That dependency makes how you back up those VMs one of the more consequential technical decisions in your environment.
VMware backup is not a single method. It is a category that includes several distinct approaches, each with different tradeoffs in speed, storage efficiency, application consistency and administrative overhead. Choosing the right approach for each workload makes the difference between a backup program that recovers cleanly and one that creates more problems during a failure than it solves.
This guide covers how VMware backup works, the main methods available, what Changed Block Tracking and VADP mean in practice, best practices for vSphere environments and how to approach recovery when a VM fails. For MSPs, Datto SIRIS supports agentless VMware backup via VADP and agent-based backup for mixed environments, with instant virtualization and immutable cloud storage. For businesses managing their own VMware infrastructure, Unitrends (available as a physical backup appliance or enterprise backup software) delivers VMware vSphere protection from a single management interface.
What is VMware backup?
VMware backup is the process of creating a protected copy of a virtual machine running in a VMware vSphere environment, stored at a separate location, so that the VM can be restored to a working state after a failure, data loss, or ransomware incident.
A VMware virtual machine is made up of several files that together define the complete system: VMDK files (virtual disk images), a .vmx configuration file that defines CPU allocation, memory, network adapters and hardware version, plus associated snapshot and log files. A backup that captures only part of this set may not restore cleanly, or at all, depending on what is missing.
What makes VMware backup distinct from backing up physical servers is that VMware exposes a set of APIs, specifically VADP (vStorage APIs for Data Protection), that allow backup tools to interact directly with the ESXi hypervisor to take consistent, complete copies of running VMs without touching the guest operating system. This hypervisor-level integration is what enables the efficiency, application consistency and scale that modern VMware environments require. The rest of this guide is built around understanding and using that architecture correctly.
How VMware backup works
Most modern VMware backup solutions use two VMware-native capabilities that are worth understanding before evaluating any specific product or method.
VADP (vStorage APIs for Data Protection)
VADP is VMware’s framework for backup applications to take image-level backups of virtual machines directly through the ESXi host or vCenter Server, without requiring an agent inside each VM. VADP allows a backup system to request a snapshot of a VM’s virtual disk, read that disk data directly from the storage layer and transfer it to a backup target, all without touching the guest operating system. This approach is called agentless backup and it is the standard method for protecting VMware environments at scale.
Before VADP existed, backing up VMs meant installing backup agents inside each guest, treating VMs like physical machines. That method still works, but it introduces significant overhead: agents to install, update and maintain inside every VM, plus the network and CPU load of running backup jobs inside production guests. VADP removes that complexity by moving the backup process to the hypervisor level.
CBT (Changed Block Tracking)
CBT is VMware’s mechanism for tracking which storage blocks on a VM’s virtual disk have changed since the last backup. Without CBT, an incremental backup would need to compare the entire current disk against the last backup to find changed data, which is slow and resource-intensive. With CBT enabled, the hypervisor maintains a bitmap of changed blocks and hands that information directly to the backup tool, making incremental backups fast and efficient even for large VMs.
CBT is enabled at the VM level and is a prerequisite for efficient incremental backup with VADP. Most enterprise backup platforms enable it automatically when they pair with a VMware host. One important operational note: CBT can be silently reset in certain circumstances, including storage migrations, snapshot operations with power-off states and some vMotion scenarios. When CBT resets, the next backup job falls back to a full backup. Monitoring for unexpected full backups is the practical indicator that CBT may have reset on one or more VMs.
How to back up VMware virtual machines
There are three main approaches to backing up VMware virtual machines. They are not mutually exclusive; most production environments use a combination depending on the workload.
Agentless image-level backup (VADP)
This is the recommended method for most VMware VM backup at scale. The backup tool connects to the vCenter Server or directly to an ESXi host, uses VADP to request a snapshot of each VM’s virtual disk, reads the disk data via CBT and stores the result at a backup target. No software is installed inside the guest VMs. The backup system pairs once with the hypervisor host and then has visibility over all VMs running on it.
For application consistency on transactional workloads (SQL Server, Exchange, Active Directory), agentless backup coordinates with VMware Tools installed inside each guest to request a quiesced snapshot. Quiescing briefly pauses application write activity and puts the file system in a stable state before the snapshot is taken, ensuring the backup can be restored to a clean, immediately usable state without manual recovery procedures. VMware Tools must be installed and current in every guest VM for quiesced snapshots to work reliably.
Datto SIRIS uses this approach for VMware environments, connecting directly to vSphere via VADP and taking quiesced snapshots through VMware Tools. The backup data is transferred to the SIRIS appliance, the snapshot is removed immediately and the result is a fully independent recovery point stored outside the production environment.
Agent-based backup
Agent-based backup installs a backup client inside the guest OS of each VM and runs the backup job from within the guest. The agent handles quiescing, data transfer and application-aware processing directly. This approach provides the most direct, fine-grained application consistency, particularly for workloads where VADP-based quiescing may not capture the full application state reliably.
The tradeoff is scale. Each VM requires its own agent installation, version management and configuration. In environments with large VM fleets, agent-based backup is operationally heavier than agentless backup. It remains the right choice for specific workloads: fault-tolerant VMs (which VMware cannot snapshot, making agentless backup impossible), older guest OS versions where VMware Tools quiescing is unreliable and complex application environments where direct agent-to-application coordination produces more consistent results.
Both Datto SIRIS (via Datto Windows Agent and Datto Linux Agent) and Unitrends (via its own agent) support agent-based protection for VMware environments where agentless backup is not appropriate.
Native VMware backup tools
VMware includes some native backup capabilities in vSphere, primarily intended for the vCenter Server Appliance itself rather than for general VM backup. The vCenter Server Appliance (VCSA) includes a built-in file-based backup utility that can export vCenter configuration to a network location on a schedule. This is useful specifically for protecting the vCenter configuration and should be used alongside a third-party backup solution, not instead of one.
For individual VM protection, VMware’s native snapshot functionality and the now-deprecated vSphere Data Protection appliance are not suitable substitutes for a purpose-built backup tool. VMware’s own guidance explicitly recommends certified VADP-based backup solutions for production VM protection, particularly for database and transactional workloads.
VMware backup best practices
VMware environments have specific failure modes and operational characteristics that generic backup advice does not address. These practices are grounded in how vSphere actually behaves, not just backup principles in general.
Connect backup software at the vCenter level, not directly to ESXi hosts
Connecting a backup tool to individual ESXi hosts limits its visibility to only the VMs on those hosts and breaks backup continuity when vMotion moves a VM to a different host. Connecting at the vCenter level gives the backup system full inventory visibility and maintains backup jobs regardless of which host a VM is running on.
Keep VMware Tools current in all guest VMs
Quiesced snapshots, which are required for application-consistent backups of transactional workloads, depend on VMware Tools being installed and up to date inside each guest. An outdated or missing VMware Tools installation causes quiescing to fail silently, producing crash-consistent backups instead. For SQL Server, Exchange and Active Directory VMs, this is the difference between a clean restore and one that requires manual database recovery procedures.
Monitor for CBT resets
When CBT resets on a VM, the next backup job silently falls back to a full backup. This consumes significantly more time and bandwidth than an incremental and may indicate an underlying vSphere issue such as a storage migration, a snapshot consolidation, or a VM that was powered off while a snapshot was active. Monitor backup job logs for unexpected full backup events and investigate affected VMs promptly.
Understand that snapshots are not backups
A VMware snapshot creates a delta file on the same datastore as the production VM. Every write goes to that delta file while the original VMDK is frozen. The snapshot does not move data anywhere. As the delta grows, I/O performance degrades and consolidation risk increases. A storage array failure, datastore corruption, or ransomware event affects both the VMDK and any snapshots on the same datastore simultaneously. VMware explicitly recommends against using snapshots as a backup mechanism and calls for certified VADP-based tools that store copies outside the production environment. Audit manually created snapshots regularly and enforce a cleanup policy. Your backup tool’s automated snapshot lifecycle (create, read, delete within minutes) is separate and should never be confused with manually held snapshots.
Back up the vCenter configuration separately
The VCSA is both a critical component of the vSphere environment and one that most backup platforms do not protect in the same way they protect VMs. Use the VCSA’s native file-based backup utility to export the vCenter configuration to a network path on a schedule and register each ESXi host individually in your backup platform. If vCenter fails and only the VMs were registered, the host-level protection needed to recover ESXi is missing.
Use immutable storage in a separate failure domain
Ransomware attacks targeting VMware environments increasingly attempt to enumerate backup targets over the network. Backup copies stored on the same network segment or NFS datastore visible to the VMware environment are at risk. The backup storage target must be logically isolated and write-protected from the VMware environment. Immutable object storage or an air-gapped backup appliance are appropriate; a backup folder mounted to the ESXi host is not.
Test vSphere-specific recovery scenarios, not just backup completion
Beyond confirming backup jobs complete, VMware environments warrant testing vMotion compatibility of restored VMs (confirming they can be migrated between hosts after restore), verifying that VMware Tools is functional in the restored VM and testing restoration to a different ESXi host to validate DR readiness. Automated screenshot verification provides ongoing bootability confirmation between manual test cycles.
How to restore a VMware virtual machine
Recovery from a VMware backup involves several distinct paths depending on what failed, how much needs to be restored and how quickly operations need to be back online.
- File-level recovery: Uses the VADP backup image to mount the VM’s VMDK as a virtual disk, allowing individual files and folders to be extracted without restoring the entire VM. Most VADP-based backup platforms present the mounted disk either through the backup appliance interface or by temporarily attaching it to a running VM as an additional disk. One VMware-specific consideration: if the backup was crash-consistent rather than application-consistent (because VMware Tools quiescing failed), individual files may be recoverable but SQL Server databases or Exchange mailboxes may need additional recovery steps before they are usable.
- Full VM restore: Writes the VMDK files and .vmx configuration back to a target datastore and re-registers the VM with vCenter. The restored VM can be registered on the original ESXi host or on any compatible host in the vSphere environment. After restore, if the VM has moved to a different datastore or cluster, verify that the storage policy assignments are correct and that any distributed virtual switch configurations are intact. For vCenter-registered VMs, the restore process should also verify that the VM’s UUID and MAC address are preserved to avoid application licensing or network identity issues.
- Instant VM recovery via ESXi upload or iSCSI/NFS mount: Rather than waiting for a full VMDK write to a production datastore, instant recovery mounts the backup image directly to the vSphere environment. Platforms like Datto SIRIS offer an ESXi upload option that uses VMware Converter to register the backup as a VM directly on a connected ESXi host, using the host itself for compute and the SIRIS as the storage backend via iSCSI or NFS. The VM runs from the backup appliance while the production restore completes in the background. Once the underlying restore is finished, Fast Failback (in the case of SIRIS) resyncs any data changes accumulated during the recovery period back to the production VM before final cutover.
- ESXi host recovery: When an ESXi host fails entirely rather than an individual VM, recovery requires restoring the host configuration before the VMs can be brought back up. This is why registering individual ESXi hosts in your backup platform (in addition to the VMs they run) is critical. Without the host-level backup, a complete host loss requires manual ESXi reinstallation, vCenter re-registration and storage remounting before any VM restores can begin. With the host configuration backed up, the process is significantly faster.
- Restore to a different ESXi host or vSphere environment: VADP-based backups are portable across compatible ESXi versions. A VM backup can be restored to any ESXi host running a supported vSphere version, making cross-host and cross-site restores practical for DR scenarios. If restoring to a host in a different vCenter instance, the VM will need to be re-registered with the new vCenter and any vSphere-specific configurations (distributed switches, storage policies, resource pools) will need to be reapplied.
For situations where a VMware VM backup needs to be restored to physical hardware (V2P migration or bare metal recovery), see our guide to bare metal recovery.
VMware backup and recovery with Kaseya solutions
Kaseya offers VMware backup through two platforms, each suited to a different deployment model.
For MSPs managing client VMware environments, Datto SIRIS provides agentless VMware backup via VADP, connecting to VMware vSphere to take quiesced, application-consistent snapshots through VMware Tools. Inverse Chain Technology makes every incremental snapshot a fully independent recovery point, eliminating the chain-dependency failures that affect traditional incremental methods. Backup intervals run as frequently as every five minutes and AI-powered screenshot verification confirms backup bootability at over 99% accuracy after every job. When a VMware VM fails, SIRIS supports instant local virtualization (booting the VM directly from the appliance), 1-Click Disaster Recovery in the Datto Cloud, file-level restore and bare metal recovery, with average RTOs under six minutes. Centralized management through the Datto Partner Portal gives MSPs visibility across all protected client environments from a single interface.
For businesses managing their own VMware infrastructure, Unitrends delivers agentless VMware vSphere backup alongside agent-based protection for mixed environments. Instant recovery, bare metal restore and WAN-optimized cloud replication provide flexible recovery options. Available as a physical backup appliance or enterprise backup software running as a virtual appliance on existing hardware, both options use the same management interface and recovery capabilities.
For a broader look at how VMware backup fits into a complete VM and server protection strategy, see our guides to virtual machine backup and server backup.
