Virtual machines now host most business-critical workloads. Domain controllers, SQL Server instances, application servers and file servers run as VMs in environments of all sizes and that shift has changed what backup actually means in practice.
A VM is not a physical machine. It is a collection of files: virtual disk images, configuration files and memory state that together represent a complete running system. Backing up those files correctly requires a different approach than traditional file-level backup and the consequences of getting it wrong are the same as any other failed backup: data loss, extended downtime and recovery that does not work when it needs to.
This guide covers what VM backup is, how to back up a virtual machine, the main methods and their tradeoffs, what application consistency means and why it matters and best practices for protecting VMware and Hyper-V environments. For MSPs, Datto SIRIS is a purpose-built BCDR platform that protects VMware and Hyper-V environments with agentless and agent-based backup, instant virtualization and immutable cloud storage. For businesses managing their own infrastructure, Unitrends (available as a physical backup appliance or enterprise backup software) delivers VM backup for both hypervisors from a single management interface.
What is VM backup?
VM backup is the process of creating a protected copy of a virtual machine, including its virtual disk files, configuration and application state, that can be used to restore the VM to a known-good condition after a failure, data loss or corruption event.
A virtual machine is defined by more than its data. To restore a VM to a fully functional state, a backup needs to capture the virtual disk image or images (VMDK files in VMware, VHD or VHDX files in Hyper-V), the VM configuration file (which defines CPU count, memory allocation, network adapter settings and hardware version) and, for application workloads, the in-memory and transaction log state of running applications at the point the backup was taken.
VM backup can work at the guest OS level through an installed agent, or at the hypervisor level without touching the guest OS at all. Both approaches have legitimate uses and most production environments end up using both.
How to back up a virtual machine
The core backup sequence follows the same pattern across platforms regardless of method. Here’s how it works:
- Trigger a snapshot: The backup tool initiates a point-in-time snapshot of the VM’s disks. In VMware environments, this uses VMware’s vStorage APIs for Data Protection (VADP), which hands off a consistent copy of the VM’s disk data to the backup system without requiring the VM to pause or shut down. In Hyper-V, a similar process uses the Volume Shadow Copy Service (VSS) in combination with Hyper-V checkpoints.
- Transfer changed data to the backup target: The backup tool reads the disk data and transfers it to the backup target: a local appliance, NAS device, or cloud repository. Most modern tools track which blocks have changed since the last backup and transfer only those, rather than the full disk. VMware calls this Changed Block Tracking (CBT); Hyper-V uses Resilient Change Tracking (RCT). These capabilities make incremental backups fast and storage-efficient without sacrificing recovery completeness.
- Delete the snapshot: After the data transfer completes, the snapshot is removed from the production VM. Leaving hypervisor snapshots in place for extended periods degrades VM performance and increases the risk of snapshot consolidation failures. Purpose-built backup tools clean up snapshots immediately after each job.
- Store and verify the backup copy: The result is a complete copy of the VM on the backup target, representing its state at the time of the snapshot. That copy can be used to restore individual files, restore the entire VM, or boot the VM directly as a virtual recovery environment. Automated verification after each job, such as screenshot-based bootability testing, confirms the backup is actually restorable rather than just present.
VM backup options: Agent-based vs. agentless
The method used to take a VM backup determines where the backup process runs, what it can capture and what the administrative overhead looks like at scale.
Agent-based backup
Agent-based backup installs a backup client inside the guest operating system of each VM. The agent coordinates with VSS on Windows to create application-consistent snapshots and handles the data transfer directly from inside the VM. This provides the highest level of granularity and application consistency, making it the right choice for VMs running SQL Server, Exchange Server, Active Directory, or other transactional applications.
The administrative tradeoff is scale. Each VM requires its own agent installation, version management and communication configuration. In environments with dozens or hundreds of VMs, this overhead is significant. Datto SIRIS supports agent-based backup through the Datto Windows Agent and Datto Linux Agent. Unitrends uses its own agent for Windows and Linux VMs, including Hyper-V environments.
Agentless backup
Agentless backup works at the hypervisor level without installing software inside guest VMs. The backup system connects directly to the hypervisor and uses its APIs to snapshot and read the VM’s virtual disk data. There are no agents to install, update, or troubleshoot inside guest machines. The backup system pairs once with the hypervisor host and has visibility over all VMs on that host.
For VMware environments, Datto SIRIS supports fully agentless backup via VADP, using quiesced snapshots through VMware Tools for application-consistent captures. Changed Block Tracking keeps incremental backup windows short. Agentless backup on SIRIS is currently available for VMware vSphere; VMs on other hypervisors use agent-based protection.
The key consideration with agentless backup is application awareness. Without a guest OS agent to coordinate with VSS, full application consistency for transactional applications requires VMware Tools to be installed and properly configured inside each VM. For environments with older guest OS versions or non-standard application stacks, agent-based backup is the more reliable path.
VM snapshot vs. backup
Snapshots and backups are frequently confused and the distinction matters for recovery confidence.
A VM snapshot is a point-in-time record of a virtual machine’s disk state, maintained within the hypervisor as a delta file alongside the VM’s primary disk. Snapshots are fast to create and fast to revert from, making them useful for short-term windows such as rolling back a failed software update.
They are not a substitute for backup. Snapshots live on the same datastore as the production VM, meaning a storage failure, ransomware attack, or datastore corruption event affects both simultaneously. Multiple snapshots degrade VM performance over time. VMware’s own guidance recommends keeping no more than two or three snapshots per VM and retaining them for no longer than 24 to 72 hours. Consolidating long-lived snapshots is slow, resource-intensive and can cause VM downtime.
A VM backup stores a complete copy at a separate location, independent of production infrastructure, designed for long-term retention. Purpose-built backup platforms use short-lived hypervisor snapshots only as a mechanism to read consistent disk data during a backup job. The snapshot is created, the data transfers to the backup appliance and the snapshot is deleted within minutes. What persists is the backup copy, not the hypervisor snapshot.
Application-consistent vs. crash-consistent VM backup
Two terms represent a meaningful quality difference in what VM backups actually capture.
Application-consistent backup
An application-consistent backup coordinates with the applications running inside the VM to flush in-memory data and quiesce write operations before the snapshot is taken. On Windows VMs, this is done through VSS, which notifies registered VSS writers (SQL Server, Exchange, Active Directory and others) to flush their transaction logs and bring data to a recoverable state. On Linux VMs, file system quiescing is used instead. The result is a backup that can be restored to a fully consistent, immediately usable state, with no manual recovery steps required.
Achieving application consistency reliably requires either an agent inside the guest that coordinates VSS, or agentless backup with VMware Tools properly configured for quiesced snapshots. Either approach works; what matters is that application consistency is confirmed, not assumed.
Crash-consistent backup
A crash-consistent backup captures the state of a VM’s disks exactly as they are at the moment the snapshot is taken, including any data that was in memory or mid-write at that instant. It represents the same state as a sudden power loss: disk data is consistent at the block level, but in-flight transactions are not committed.
For VMs running stateless workloads or workloads that tolerate dirty shutdowns, crash-consistent backups are acceptable. For VMs running databases, email servers, or Active Directory, they are not. Restoring a SQL Server database from a crash-consistent backup may require running recovery procedures and, in some cases, data may be lost or corrupted.
Virtual machine backup best practices
A VM backup schedule that runs without issues is only half the picture. What actually determines whether a virtualized environment is protected is the combination of how backups are taken, where they are stored and whether recovery has been tested. These practices apply across VMware, Hyper-V and mixed environments.
Use image-level backup, not file-level backup
File-level backup inside a VM captures files and folders but cannot capture the VM’s hardware configuration, OS state, or the ability to restore a complete bootable system. Image-level backup captures everything needed to restore the VM as a functioning machine, including to different hardware or a different hypervisor host.
Verify application consistency for transactional workloads
Do not assume agentless backup automatically produces application-consistent copies. Confirm VMware Tools is installed and current in every guest VM and that VSS writers for running applications are functioning correctly. For Hyper-V environments, verify that integration services are installed and enabled.
Do not rely on hypervisor snapshots as backups
Snapshots on the production datastore are not offsite, not immutable and degrade performance over time. Your backup tool should be creating and deleting its own snapshots automatically during each job. Long-lived manually created snapshots are a separate problem that should be cleaned up regularly.
Back up frequently enough to meet your RPO
RPO is the maximum acceptable data loss in a failure scenario, not a target for ideal conditions. If your RPO for a production SQL Server VM is 15 minutes, backups need to run at least every 15 minutes. Datto SIRIS supports backup intervals as frequent as every five minutes.
Store backup copies outside the production environment
Apply the 3-2-1 rule: three copies, on two different storage media, with one copy offsite or in an immutable cloud. For ransomware scenarios, immutability is non-negotiable. Ransomware increasingly targets backup infrastructure directly.
Test recovery, not just backup completion
A completed backup job means data was written somewhere. It does not mean the VM is bootable or that applications will start cleanly. Test restores regularly, including both file-level and full VM recovery and use automated screenshot verification where available to confirm bootability after every job.
How to restore a VM from backup
How you restore a virtual machine depends on what failed, how much needs to be recovered and how quickly operations need to be back online. Consider these recovery paths:
- File-level restore recovers individual files or folders without restoring the entire VM. It is the fastest path for accidental deletions or isolated file corruption and it does not require taking the production VM offline.
- Full VM restore recovers the entire virtual machine, including its configuration, OS, applications and data, to a defined restore point. The restored VM can be brought up on the original host or an alternate host. Full restores take longer because the entire disk image is written to the target datastore, but they are appropriate when the VM is corrupted or the guest OS cannot boot.
- Instant VM recovery boots the VM directly from the backup image, typically on the backup appliance or in a cloud environment, within minutes. The VM runs from backup storage while the underlying restore or hardware replacement happens in the background. This compresses the time between a failure and restored operations significantly.
- Bare metal recovery (BMR) restores a VM backup image to a physical machine or a new VM on a different hypervisor, without requiring a pre-installed OS on the target. It is the right path when hardware replacement is involved, when the hypervisor host has failed, or when a physical-to-virtual (P2V) or virtual-to-physical (V2P) migration is part of the recovery. For more detail, see our guide to bare metal recovery.
- Granular application-item recovery restores individual objects such as a single mailbox, a specific SQL database, or individual Active Directory objects, without a full VM restore. It requires application-aware backup software and is significantly faster than a full restore when only specific data items need to be recovered.
The right recovery path is not always the most comprehensive one. Mapping recovery scenarios to the appropriate method in advance and testing each path before it is needed, is what separates a backup program that works from one that only appears to.
VM backup for VMware and Hyper-V environments
The two hypervisors that dominate SMB and mid-market environments each have their own backup mechanisms, APIs and operational considerations. Understanding the specifics for each helps avoid common configuration mistakes and ensures backups are set up to actually deliver application-consistent, recoverable copies.
VMware vSphere backup
VMware’s VADP is the standard API used by all major backup platforms for agentless image-level backups of VMs on ESXi hosts. Combined with Changed Block Tracking, it makes efficient incremental backups possible at scale without stopping the VM.
Key considerations include ensuring VMware Tools is installed and current in all guest VMs (required for quiesced, application-consistent snapshots), monitoring for CBT reset events that can trigger unexpected full backups and connecting backup software at the vCenter level rather than directly to individual ESXi hosts. vCenter-level connectivity maintains backup continuity during vMotion and storage migrations and provides visibility across the full VM inventory.
Hyper-V backup
Hyper-V uses VSS and its own Hyper-V VSS writer to coordinate backups at the host level. Hyper-V checkpoints function like VMware snapshots but carry the same limitations: they should not be used as a backup substitute and extended checkpoint chains degrade VM performance.
Agent-based protection is the standard approach for Hyper-V environments, with a host-level agent coordinating VSS and Resilient Change Tracking for efficient, application-consistent incremental backups. One architectural point worth noting: backing up the Hyper-V host itself (the parent partition) is separate from backing up the VMs running on it. Both should be in scope for a complete protection strategy.
Protect virtual machines with Kaseya
Kaseya offers VM backup for both MSP and direct business environments, with purpose-built platforms for each.
For MSPs, Datto SIRIS protects VMware ESXi environments with agentless backup via VADP, using quiesced snapshots through VMware Tools for application-consistent captures. Datto Windows Agent and Datto Linux Agent provide agent-based coverage for Hyper-V VMs and non-VMware environments. 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 VM needs to be restored, SIRIS supports instant local virtualization, 1-Click Disaster Recovery in the Datto Cloud, file-level restore and bare metal recovery, with average RTOs under six minutes.
For businesses managing their own infrastructure, Unitrends delivers VM backup for both VMware vSphere and Microsoft Hyper-V, with automated backup verification, instant recovery and WAN-optimized cloud replication. Available as a physical backup appliance or enterprise backup software on existing hardware, both options share the same management interface and recovery capabilities.
For a broader look at how VM backup fits into a server protection and recovery strategy, see our guide to server backup.
