Proxmox Snapshots: How They Work and When to Use

The short version:

• A snapshot is a storage-layer bookmark, not a copy. It shares blocks with the live disk and lives or dies with it.
• Whether you can take one at all depends on the storage, not on the guest. ZFS, LVM-thin, Ceph RBD and qcow2 support snapshots; a raw disk on plain directory storage does not.
• --vmstate is the difference between a paused machine and a rebooted one. It writes guest RAM to disk, which is why it is slow and large.
• Rollback is one-way. Everything written since the snapshot is discarded, and Proxmox will not ask twice.
• Snapshots are the cheapest thing to take and the easiest thing to forget. Old ones quietly hold space and, on some storage, quietly cost performance.

If you are here because you want to know whether snapshots can replace backups, the answer is no, and the Proxmox backup strategy guide covers what to do instead. The rest of this page is about using snapshots well for what they are actually good at: a five-second undo button before you change something.

What Proxmox is actually doing

When you run qm snapshot 101 before-upgrade, Proxmox does two things. It writes a new [before-upgrade] section into /etc/pve/qemu-server/101.conf holding a frozen copy of the guest’s configuration, and it asks the storage layer to mark a point in time on every disk that guest owns.

That second part is the whole story. Proxmox does not implement snapshots; it delegates them. On ZFS it is a zfs snapshot. On Ceph it is an RBD snapshot. On LVM-thin it is a thin snapshot volume. On file-based storage it is a qcow2 internal snapshot. Proxmox VE 9 adds a second file-based mechanism, snapshots as a volume chain, where each snapshot becomes its own backing volume rather than growing one image; it is a technology preview, VM-only, and off unless you set snapshot-as-volume-chain on the storage. Each of those has different costs, and the differences show up later, under load, rather than at the moment you click the button.

The configuration is snapshotted too, which surprises people. Roll back to a snapshot taken before you added a second NIC and the second NIC is gone from the config, not just from the guest’s view of the world.

Which storage types support snapshots

This is the table people actually need, drawn from the storage type matrix in the Proxmox VE documentation:

Storage	Snapshots	How it works
ZFS (local)	Yes	Native zfs snapshot, copy-on-write, effectively instant
LVM-thin	Yes	Thin snapshot volume from the same pool
Ceph/RBD	Yes	Native RBD snapshot, cluster-wide
CephFS	Yes	Filesystem-level
BTRFS	Yes	Native, but Proxmox labels the plugin a technology preview
Directory, NFS, CIFS	Yes, with qcow2	qcow2 internal snapshots. A raw disk cannot be snapshotted at all
LVM (thick), iSCSI	Proxmox VE 9, preview	Volume-chain snapshots, VMs only, enabled per storage with snapshot-as-volume-chain. Proxmox labels it a technology preview
ZFS over iSCSI	Yes	Delegated to the remote ZFS host
Proxmox Backup Server	Not applicable	It is a backup target, not guest storage

Two practical consequences. First, if the Snapshot button is greyed out, look at the storage before you look at the guest: the usual cause is a raw disk sitting on directory or NFS storage. Second, “supported” is not “free”. A qcow2 internal snapshot grows the image file every time the guest writes, and a long qcow2 snapshot chain measurably slows the guest down. ZFS and Ceph handle the same workload far better, which is one more reason the Proxmox ZFS storage guide argues for ZFS-backed zvols on a host you intend to keep.

The commands

For virtual machines:

qm listsnapshot 101
qm snapshot 101 before-upgrade --description "pre 24.04 dist-upgrade"
qm rollback 101 before-upgrade
qm rollback 101 before-upgrade --start
qm delsnapshot 101 before-upgrade

For containers, the same verbs with pct:

pct listsnapshot 200
pct snapshot 200 before-upgrade --description "pre dist-upgrade"
pct rollback 200 before-upgrade --start
pct delsnapshot 200 before-upgrade

Three options are worth knowing by heart.

--vmstate exists only on qm snapshot. It tells Proxmox to write the guest’s RAM into the snapshot as well as its disks, so a rollback returns a running machine mid-thought rather than a machine that has to boot. It is the GUI’s “Include RAM” checkbox. The cost is proportional to the guest’s memory: a 32 GB VM writes roughly 32 GB, takes as long as that write takes, and pauses the guest for part of it. Proxmox documents that a rollback to a snapshot that includes RAM starts the VM automatically, regardless of --start.

--start on rollback is the one people forget. Rolling back stops the guest. Without --start, it stays stopped, which is a fine default for a maintenance window and a bad surprise at 2 a.m.

--force on delsnapshot removes the snapshot from the configuration file even if the storage layer refuses to remove the underlying disk snapshot. It is a recovery tool for a config and storage that have drifted apart, not a routine flag. Using it leaves the storage-side snapshot behind, still consuming space with nothing in Proxmox referencing it.

Containers have no --vmstate equivalent, because there is no separate guest kernel or QEMU process holding memory to save. That asymmetry is part of the wider set of tradeoffs covered in Proxmox LXC vs VM.

Snapshot or backup: what each one actually protects

The queries that bring people here are usually some phrasing of “backup vs snapshot”, so here is the distinction stated plainly.

	Snapshot	Backup (vzdump / PBS)
Lives on	The same storage as the guest disk	A separate datastore, ideally a separate machine
Survives pool loss	No	Yes
Survives guest deletion	No	Yes
Time to create	Seconds	Minutes to hours
Retention	Manual, until you delete it	Scheduled, pruned automatically
Restore target	The same guest, in place	Any node, any VMID, any time
Good for	Undoing a change you are about to make	Everything else

Snapshots protect you from yourself over a horizon measured in minutes or hours. Backups protect you from hardware, from the storage layer, and from the version of you that runs qm destroy against the wrong VMID. A guest with forty snapshots and no backup is one command away from having nothing.

One point of genuine confusion: vzdump has a mode called snapshot, and it is not the same thing. For VMs, that mode uses QEMU’s live-backup mechanism to stream a consistent image out while the guest runs; it does not leave a storage snapshot behind. For containers, it does take a temporary storage snapshot and removes it when the archive is written. Both are covered in the backup strategy guide, and the deduplicating target side is in Proxmox Backup Server setup.

Where snapshots quietly cost you

Space you cannot see. A ZFS snapshot holds every block the live dataset has since overwritten. zfs list -t snapshot shows what each one is pinning. A guest that rewrites its whole disk during an upgrade can double its footprint while a snapshot from before the upgrade still exists.

A full thin pool. LVM-thin snapshots draw from the same thin pool as the live volume, and a thin pool at 100 percent is not a warning, it is an outage: writes fail and guests go read-only. This is a recurring entry in common Proxmox problems and how to fix them for a reason.

Performance drift on qcow2. Every write to a snapshotted qcow2 image has to be resolved through the snapshot chain. One snapshot is unnoticeable. Six, kept for weeks, are not.

Operations that refuse to run. Moving a disk to different storage, resizing it, or converting the guest to a template will fail or be disallowed while snapshots exist. On the new volume-chain storages the restriction is broader still: a VM holding snapshots on local volume-chain storage cannot be migrated at all while the feature is in preview. The fix is always the same: delete the snapshots first.

Memory-related exclusions. Anything that saves and restores guest memory is a special case. Proxmox documents that with AMD SEV memory encryption enabled, operations that save or restore memory — snapshots including RAM, and live migration — do not work yet or are attackable. Where the hardware profile matters more broadly, Proxmox GPU passthrough covers the other side of the same constraint.

A working discipline

• Take one before every change worth naming. A dist-upgrade, a kernel change, a database migration, a config experiment. Name it after the change, not snap1.
• Set an expiry in your head when you take it. “Delete after the upgrade sticks” is a plan. “I’ll clean up later” is how thin pools fill.
• Skip --vmstate unless you need the running state back. Most rollbacks are followed by a boot anyway, and the disk-only snapshot is faster and smaller.
• Never let a snapshot substitute for a backup. Run both. A snapshot before the change, a verified restore behind it.
• Audit them. for id in $(qm list | awk 'NR>1{print $1}'); do qm listsnapshot $id; done on each node takes seconds and finds the six-month-old snapshot nobody remembers.
• Watch them in a cluster. On shared storage, snapshots interact with migration and with Proxmox high availability; a guest that cannot migrate because of a stale snapshot is a guest HA cannot save.

Next steps

• The full protection picture, including offsite: Proxmox backup strategy: vzdump, snapshots and offsite.
• Why the storage choice under your guests decides what snapshots cost: Proxmox ZFS storage setup.
• When replication across nodes replaces per-node snapshots: Proxmox Ceph vs ZFS replication.
• If you are still deciding the order to build things in: the Proxmox VE homelab roadmap.
• Sizing the RAM that ARC and your guests will fight over: the Proxmox cluster and ZFS ARC sizer.

Related across the network

• iSCSI vs NFS vs SMB: Choosing a Storage Protocol — iscsihub.com
• iSCSI Fundamentals: Targets, LUNs and Multipathing — iscsihub.com