VM Snapshots Are Not Backups: How They Quietly Break Proxmox and VMware - SysRoot

The mistake that looks responsible

A team takes a snapshot before a risky upgrade. The upgrade goes fine. Nobody deletes the snapshot. A month later there are seven snapshots on that VM, the datastore is mysteriously 90% full, write latency has tripled, and a routine reboot turns into a four-hour outage because consolidating the snapshot chain takes longer than anyone expected.

This is one of the most common self-inflicted incidents we see on both VMware and Proxmox. It feels safe in the moment. It is the opposite of safe. Snapshots are not backups, and treating them as one is a slow-motion failure that detonates at the worst time.

This article is about what a VM snapshot actually is, why long-lived snapshots degrade and eventually break your hypervisor, and how to use them correctly across VMware, Proxmox, and hybrid estates.

What a snapshot actually is

A snapshot is not a copy of your VM. It is a point-in-time freeze of the disk plus a redirect of all new writes into a separate delta file. The original disk becomes read-only at the moment of the snapshot, and every subsequent write goes into a growing chain of deltas.

That distinction matters because it explains every snapshot-related failure mode.

VMware

On VMware, taking a snapshot freezes the base VMDK and creates a -delta.vmdk (sometimes called a redo log). If you take more snapshots, you get more deltas, forming a chain. Reads have to walk the chain to find the most recent version of each block. Optionally, snapshots can include memory state and can quiesce the guest filesystem via VMware Tools.

Deleting a snapshot triggers consolidation: VMware merges the delta back into the parent. During consolidation the VM keeps running, but the host has to commit potentially huge amounts of changed data, and on busy storage this can stall I/O noticeably.

Proxmox

Proxmox behaves differently depending on storage backend, which is exactly why it trips people up.

• ZFS / LVM-thin: snapshots are cheap, native, copy-on-write at the storage layer. They are fast to take and fast to roll back.
• qcow2 on a file-based store: snapshots are stored inside the qcow2 file as internal snapshots, and the file grows. Performance degrades as the snapshot chain and file size grow.
• Ceph (RBD): native RBD snapshots, generally efficient, but rollback and clone semantics differ.

The same Proxmox command can produce a fast, safe snapshot on ZFS and a slow, fragile one on qcow2. If your team learned snapshots on one backend and assumes they behave the same everywhere, you will eventually be wrong.

Why long-lived snapshots break things

The core problem is the same on every platform: a snapshot you keep is a delta that never stops growing.

1. Storage exhaustion

Every write since the snapshot is retained. A database VM under load can generate tens of gigabytes of delta per day. Three forgotten snapshots on three busy VMs can fill a datastore. When a thin-provisioned datastore fills, VMs pause or crash, sometimes all of them at once. The blast radius is the whole datastore, not just the VM with the snapshot.

2. Performance degradation

Each read may traverse the snapshot chain. The longer the chain and the larger the deltas, the worse random read performance gets. Latency creeps up slowly enough that nobody connects it to the snapshot taken weeks ago.

3. The consolidation bomb

This is the one that causes real outages. When you finally delete a large snapshot, or when a backup job tries to remove its temporary snapshot, the hypervisor must merge gigabytes of delta into the base disk. On VMware this can produce long I/O stalls; in bad cases the VM becomes unresponsive during consolidation. On Proxmox qcow2, committing a giant internal snapshot can take a long time and pin I/O.

You took the snapshot to make things safer. It turned a planned reboot into an unplanned outage.

4. Backups silently failing

Most backup tools (Veeam, Proxmox Backup Server, native vSphere backups) use a snapshot under the hood to read a consistent disk image. If a stale manual snapshot already exists, or the datastore is too full to create the backup snapshot, the backup job fails or, worse, succeeds but leaves an orphaned snapshot behind. Now you have a backup problem and a snapshot problem feeding each other.

5. They do not protect against the thing you fear

A snapshot lives on the same storage as the VM. If that datastore, array, or host dies, your snapshot dies with it. It protects against "the upgrade broke the app." It does nothing against "the array failed," "ransomware encrypted everything," or "someone deleted the VM." That is what backups are for.

A realistic scenario

A 40-person SaaS company runs a Proxmox cluster with qcow2 VMs on local NVMe. Before a major application release, an engineer snapshots the two app VMs and the Postgres VM "just in case." The release ships. It is fine. The snapshots stay.

Proxmox Backup Server runs nightly. It needs to create its own snapshot to read a consistent image. On the Postgres VM, the qcow2 file has already grown by 60 GB of delta from the manual snapshot. The backup snapshot creation succeeds but the chain is now deep, and nightly backup duration on that VM doubles.

Three weeks later the local datastore hits 94% capacity. An engineer notices, opens the storage view, sees three large snapshots, and deletes them to reclaim space — during business hours. The qcow2 commit on the Postgres VM saturates the NVMe with merge writes. Postgres I/O latency spikes, connection pools back up, and the application starts timing out. What was supposed to free space caused a 90-minute customer-facing degradation.

Everything here was avoidable. The snapshot was used as long-term storage instead of a short-lived rollback tool, and the cleanup was done blind during peak load.

How to use snapshots correctly

The rule is simple: a snapshot is a short-lived rollback point for a specific operation, then it gets deleted. Hours, not weeks.

The operating rules

1. Take a snapshot immediately before a change, delete it immediately after. A snapshot's lifespan should match the operation it protects: an upgrade, a config change, a migration test.
2. Set a hard maximum age. We recommend 24 hours. Anything older is treated as an incident, not a feature.
3. Never use snapshots as a backup. If you want a copy you can keep, take a real backup to separate storage.
4. Quiesce databases properly. A crash-consistent snapshot of a running database may not be cleanly recoverable. Use application-aware quiescing or back up via the database's own tooling.
5. Avoid snapshots on high-write VMs (databases, busy queues) unless the snapshot will live for minutes. The delta grows fastest exactly where it hurts most.
6. Watch datastore free space before, during, and after. Never let snapshot-heavy VMs share a near-full datastore.
7. Schedule consolidation/deletion during low-traffic windows. Deleting a large snapshot is itself a load event.

Snapshot age and count checklist

Run this audit weekly across the estate:

• Any snapshot older than 24 hours? Investigate and resolve.
• Any VM with more than one manual snapshot? Collapse the chain.
• Any datastore above 80% used? Find the snapshots eating the space.
• Any orphaned snapshots left behind by backup jobs? On VMware, check for "consolidation needed" warnings; on Proxmox, reconcile snapshot lists with what backups expect.
• Any snapshots on database or high-write VMs at all? Justify or remove.

How to find stale snapshots

On VMware, the vSphere UI flags "Virtual machine disks consolidation is needed," but it does not loudly warn about old snapshots until they cause trouble. Use PowerCLI for a real inventory:

Get-VM | Get-Snapshot |
  Select VM, Name, Created, SizeGB |
  Sort Created

Flag anything older than a day or larger than a few GB.

On Proxmox, snapshots are visible per-VM in the GUI, but there is no estate-wide dashboard by default. List them per VM:

qm listsnapshot <vmid>

For a fleet, script a loop over all VM IDs and alert on snapshots with old timestamps. The goal is the same on both platforms: no snapshot should surprise you.

What to do instead for the cases people misuse snapshots for

Most snapshot abuse comes from trying to solve a real problem with the wrong tool. Match the need to the right mechanism:

• "I want to roll back a risky change." This is the legitimate snapshot use case — just delete it within hours.
• "I want to keep a recovery point for weeks." Use real backups to separate storage: Veeam, Proxmox Backup Server, or array-based backups. These deduplicate, live off-host, and survive a storage failure.
• "I want to test against a copy of production data." Use a clone or restore a backup into an isolated environment, not a snapshot of the live VM.
• "I want disaster recovery." Use replication to a second site plus backups. A snapshot on the same array is not DR.
• "I want point-in-time recovery for a database." Use the database's native backup and WAL/log archiving, not a hypervisor snapshot.

Hybrid estates: the extra trap

If you run VMware in one place and Proxmox in another, the danger is assuming consistent behavior. A 30-day-old snapshot on a ZFS-backed Proxmox VM might consolidate in seconds. The same age on a VMware VM on a busy SAN, or a qcow2 Proxmox VM, can mean a painful merge.

Standardize the policy (max age, no backups-as-snapshots, monitored free space) even though the mechanics differ. Document, per backend, how snapshots behave and how long deletion is likely to take. The policy should be portable; the assumptions about performance should not be.

The bottom line

Snapshots are a precision tool with a short, well-defined job: give you a fast rollback for a specific operation, then disappear. The moment they become a place you store recovery points, they stop protecting you and start working against you — filling datastores, dragging down I/O, and turning routine maintenance into outages.

The fix is not technical sophistication. It is discipline: take the snapshot, do the work, delete the snapshot, and use real backups for everything that needs to last longer than a coffee break. Audit weekly, alert on age, and never let a snapshot outlive the reason you took it.

---

Struggling with Bare Metal & VM Management?

You don't have to solve it alone. SysRoot provides senior DevOps and infrastructure expertise without the cost of building a full in-house team. If your team is wrestling with Bare Metal & VM Management, talk to the SysRoot team and we'll help you get it under control.