Hypervisors, VM Snapshots & Tested Recovery

Hypervisors, Snapshots, and VM Recovery

Virtual machines make it easy to provision servers in minutes and to roll back mistakes in seconds with a snapshot. That convenience creates one of the most common and expensive misunderstandings in infrastructure: treating snapshots as backups. A snapshot lives on the same storage as the VM, depends on the original disk, degrades performance as it grows, and disappears with the datastore it sits on. A backup is an independent copy on separate storage, ideally immutable, and only trustworthy once a restore has been tested.

Running VMs well means using each tool for its job: templates for repeatable provisioning, snapshots for short-lived rollback points around changes, backups for recovery from loss, replication for fast disaster recovery, and high availability for host failures — with recovery objectives that say which combination each workload needs.

TL;DR

Type 1 hypervisors (KVM/Proxmox VE, Hyper-V, ESXi, Xen) run servers; Type 2 (VirtualBox, Workstation) suit desktops and labs.
Provision from templates and cloud-init or unattended installs, managed as code.
A snapshot is a copy-on-write rollback point on the same storage — keep it hours or days, not weeks.
Snapshots are crash-consistent unless the guest agent quiesces applications; databases need application-aware handling.
Backups are independent copies on other storage (and offsite/immutable); replication shortens RTO; HA restarts VMs after host failures but does not undo data loss.
Test restores regularly into isolated networks and measure them against RPO and RTO.

Quick Example

On Proxmox VE: a short-lived snapshot around an upgrade, then a real backup and a restore test into a new VM ID:

The restore test then boots VM 9101 on an isolated network and runs application checks — the step that turns "we have backups" into "we can recover."

Core Concepts

Hypervisors

See Virtual Machine Management.

Provisioning

Build templates (golden images) with patched OS and agents, clone them, and customize with cloud-init (Linux) or unattended setup (Windows). Manage VM definitions with infrastructure as code — for example Terraform providers for vSphere, Proxmox, or Hyper-V — so rebuilding is as reliable as restoring.

What a Snapshot Is

A snapshot freezes the VM's disk state and redirects new writes to a delta (copy-on-write or redirect-on-write), optionally capturing memory. Consequences:

Hyper-V distinguishes production checkpoints (using VSS inside the guest for application consistency) from standard checkpoints (including memory state). VMware's guidance is to keep few snapshots for short periods.

Consistency

Crash-consistent: disks captured at one instant; databases replay logs on start.
Application-consistent: the guest agent quiesces applications (VSS writers, fsfreeze hooks) before the snapshot.
Database-native: for critical databases, also use the database's own backups and point-in-time recovery.

Backups and Replication

Image-level backups use changed block tracking (VMware CBT, QEMU dirty bitmaps, Hyper-V RCT) for fast incrementals, store copies on separate systems, and follow 3-2-1 practices with an immutable or offline copy. Replication keeps a near-current copy of VMs at another site for fast failover (low RTO) but also replicates corruption and encryption — it complements, not replaces, versioned backups. See Backup Strategy and Immutable Backups and Restore Verification.

High Availability Is Not Recovery

Cluster HA restarts VMs on surviving hosts after a host failure; live migration moves running VMs for maintenance. Neither helps if data is deleted, corrupted, or encrypted. See High Availability.

Recovery Objectives and Testing

Test restores on a schedule: restore into an isolated network, boot, run application health checks, record the time taken, and compare against RTO. Protect backup infrastructure with separate credentials and MFA, since attackers increasingly target hypervisors and backup consoles. See Disaster Recovery Planning.

Best Practices

Time-Box Snapshots

Name snapshots with a reason and ticket, set an expiry, and alert on snapshots older than a few days.

Back Up Off the Hypervisor's Storage

Send backups to separate systems and keep at least one immutable or offline copy.

Use Application-Consistent Methods for Stateful Workloads

Enable guest agents and VSS or fsfreeze hooks, and combine them with database-native backups.

Prove Recovery Regularly

Automate periodic restore tests and track actual RTO and RPO against targets.

Common Mistakes

Snapshots as the Backup Strategy

Forgotten Snapshots

Untested Restores

FAQ

Is a VM snapshot a backup?

No. A snapshot depends on the original disks and lives on the same storage, so it does not protect against storage failure, deletion, or ransomware. Use it as a short-term rollback point.

How long should I keep VM snapshots?

As briefly as possible — typically hours to a few days around a change — because snapshot deltas grow, slow I/O, and complicate consolidation.

What is an application-consistent snapshot?

A snapshot taken after the guest's applications have flushed and paused writes, through mechanisms such as Windows VSS or Linux fsfreeze hooks, so data is in a clean state.

What is the difference between replication and backup?

Replication maintains a current copy for fast failover but copies corruption too; backups keep historical versions for recovery to a known-good point.

How should I test VM backups?

Restore them into an isolated network as new VMs, boot them, run application checks, and record the time taken against your recovery time objective.