VM snapshots: mechanics, cost and limits

Snapshots are the most-used and least-understood VM feature in Proxmox. They take one click, they are instant, and the consequences of keeping one arrive weeks later as a storage incident that nobody connects to the click.

Two things make this lesson necessary rather than obvious. First, the cost of a snapshot is entirely a property of the storage backend underneath it, and those costs differ by more than an order of magnitude. Second, Proxmox VE 9 changed the capability matrix substantially, so advice written for PVE 8 is now wrong in a way that matters.

Which backends support snapshots, in PVE 9

Two footnotes from that table carry real operational weight.

On file-based storages, snapshots require the qcow2 format — using either the internal snapshot function or snapshots as volume chains. A VM disk stored as raw on a directory or NFS storage cannot be snapshotted at all. That is a decision made when the disk was created, and it is the single most common reason the snapshot button is greyed out.

Since Proxmox VE 9, snapshots as volume chains are available for VMs on LVM, iSCSI and FC/SAS. This is new. The mechanism uses separate volumes for the snapshot data and layers them, which is a different thing from traditional LVM snapshots — those caused significant I/O degradation and are the reason a generation of operators learned “never snapshot on shared SAN”.

Two kinds of snapshot: with and without vmstate

set -euo pipefail
VMID=118

# Disk-only. Instant on ZFS or RBD; the guest keeps running.
qm snapshot "$VMID" pre-upgrade \
--description 'before app 4.2 upgrade, CHG-20260812-004'

# Disk plus live memory state. The guest is paused while RAM is written out.
qm snapshot "$VMID" pre-upgrade-live \
--vmstate 1 \
--description 'includes RAM, rollback resumes mid-run'

qm listsnapshot "$VMID"

# qm listsnapshot 118

`-> pre-upgrade              2026-08-12 09:14:07     before app 4.2 upgrade, CHG-20260812-004
 `-> pre-upgrade-live       2026-08-12 09:21:55     includes RAM, rollback resumes mid-run
    `-> current             now                     You are here!

--vmstate is the right choice for “I am about to try something and I want to be exactly here again if it goes wrong” — an upgrade rehearsal, a configuration experiment, a support-directed change. It is the wrong choice for a routine safety net, because a 64 GiB guest writes 64 GiB every time.

Rollback, and what it destroys

set -euo pipefail
VMID=118

# Look before you leap: which snapshot, taken when, and what is under it.
qm listsnapshot "$VMID"

# The guest must be stopped unless the snapshot carries vmstate.
qm shutdown "$VMID" --timeout 300

# --start brings the VM up immediately after the rollback.
qm rollback "$VMID" pre-upgrade --start 1

Snapshot is not backup: the four failures

This slogan gets repeated without its content. Here is the content — the specific failures a snapshot does not survive.

The last row is the honest case for snapshots, and it is a good one. A snapshot taken two minutes before a risky change and rolled back three minutes later is the fastest recovery mechanism you have. That is what it is for.

What it is not is a copy. It shares fate with the storage, the VM and the cluster. Every reason a backup exists is a reason a snapshot is not one.

set -euo pipefail

for vmid in $(qm list | awk 'NR>1 {print $1}'); do
qm listsnapshot "$vmid" 2>/dev/null \
| grep -v 'You are here' \
| sed -n 's/^[[:space:]`|>-]*\([^[:space:]]*\)[[:space:]]*\([0-9-]* [0-9:]*\).*/\1 \2/p' \
| while read -r name when; do
    [ -n "$when" ] || continue
    age=$(( ( $(date +%s) - $(date -d "$when" +%s) ) / 86400 ))
    if [ "$age" -gt 7 ]; then
      printf 'VM %-6s snapshot %-24s %3d days old\n' "$vmid" "$name" "$age"
    fi
  done
done

Knowledge check