What a snapshot actually is

A Proxmox snapshot is a point-in-time marker inside the same storage the VM or container is already living on. It doesn’t copy your data anywhere. Instead, it freezes the current state of the disk and starts tracking changes from that point forward, so it can show you “the disk as it looked at 2:14 PM” without having duplicated the whole thing.

How that tracking actually works depends on the storage backend:

• ZFS (the most common case on Proxmox) uses copy-on-write natively. Taking a snapshot is close to instant because ZFS just marks the current set of blocks as “don’t overwrite these, allocate new blocks for changes instead.” Rolling back means pointing the dataset back at that marked set.
• qcow2 images build a chain: the base snapshot becomes a read-only layer, and a new writable layer sits on top capturing everything that changes afterward. Take another snapshot and you get another layer stacked on that one.
• LVM-thin works similarly to qcow2’s chaining model, using thin-provisioned volumes to track the delta between snapshot points.
• Plain LVM (thick) and directory storage without qcow2 either don’t support live snapshots at all or fall back to a much slower, less efficient mechanism. Check what your storage type actually supports before assuming the snapshot button will work the way you expect.

If you take a “snapshot with RAM,” Proxmox also captures the VM’s memory state at that instant, so a rollback restores you to a running system exactly where you left it, not just a bootable disk. That’s convenient for testing, but it makes the snapshot bigger and the host briefly pauses the VM while it captures memory, which matters if you’re doing this on something latency-sensitive.

Why this isn’t a backup

The failure mode that makes snapshots a bad primary defense is simple: a snapshot lives on the same physical storage as the thing it’s a snapshot of. If that disk fails, if the pool gets corrupted, if the whole node dies, or if you fat-finger a zpool destroy or delete the wrong VM, the snapshot dies with it. You haven’t protected yourself from any of the failure modes that actually cause real data loss. You’ve protected yourself from your own mistakes within a single running system, which is a real and useful thing, just a much narrower one than “backup” implies.

There’s a second problem that’s less obvious until it bites you: snapshot chains have an ongoing cost, and it isn’t free to ignore. Every snapshot you leave sitting around means every write to the live disk has to preserve the old blocks that snapshot references, instead of just overwriting them in place. On ZFS this shows up as gradually increasing pool usage even though nothing “new” is happening from your point of view; on qcow2 it shows up as write amplification and slower I/O the deeper the snapshot chain gets, because a read may have to walk back through several layers to find the actual current data. Long-lived snapshot chains, especially ones nested three or four deep because nobody cleaned up after testing something six months ago, are a real, measurable performance drag, not just a storage-space annoyance.

None of that shows up as a backup. A backup, in the actual sense of the word, means the data exists in a second, independent location that survives the primary storage, the primary node, and ideally the primary site failing outright.

What snapshots are actually good for

Used for what they’re actually designed for, snapshots are excellent:

• Before an in-place upgrade or a risky config change. Snapshot, make the change, and if it breaks something you didn’t expect, roll back in seconds instead of restoring from a full backup that takes minutes and requires you to have run one recently.
• Testing something destructive. Trying a database migration script, an in-place OS upgrade, or a config change you’re not 100% sure about. Snapshot, try it, roll back regardless of outcome if you were just testing.
• Short-lived safety nets during active work, not long-term protection. The right mental model is “this exists for the next hour while I do something risky,” not “this exists so I don’t need a real backup.”

The practical rule: take a snapshot immediately before a risky operation, confirm the operation worked the way you wanted, and then remove the snapshot once you’re past the point where you’d want to roll back. Don’t let them accumulate as a substitute for cleanup.

How they work together

The two aren’t competing tools, they’re complementary ones that solve different halves of the same problem:

• Snapshots give you fast, low-friction, in-place undo for mistakes you catch quickly, on the system you’re actively working on.
• Backups (see Proxmox Backup Server if you haven’t set one up) give you an independent, off-the-primary-storage copy that survives disk failure, node failure, ransomware, or “I deleted the wrong VMID at 11 PM.”

A sane homelab workflow uses both: PBS running scheduled, retained backups in the background as your actual disaster-recovery layer, and snapshots as a manual, situational tool you reach for right before doing something that might go wrong. If you only have one of the two, it should be the backup, not the snapshot. A snapshot with no backup behind it means a single storage failure takes out your data and every “recovery point” you thought you had, simultaneously.

Cleaning up snapshot sprawl

If you’ve never gone looking, there’s a decent chance you’ve got old snapshots sitting around on VMs or containers you forgot about. From the Proxmox VE web UI, each guest’s Snapshots tab shows what exists and lets you remove them individually. From the CLI, qm listsnapshot <vmid> (VMs) or pct listsnapshot <vmid> (containers) shows you the same thing across everything if you script a loop over your VMIDs, which is worth doing periodically rather than only when something feels slow.

When you delete a snapshot, Proxmox has to merge that layer’s changes back into the chain, which takes I/O and time proportional to how much changed since the snapshot was taken and how many other snapshots sit on top of it. Deleting the oldest snapshot in a long chain is usually more expensive than deleting the most recent one, so if you’re clearing out a real backlog, work from newest to oldest where you can, and expect a live merge to briefly compete with your guest’s normal disk I/O.

Bottom line

A snapshot is a fast, cheap, same-storage undo button. A backup is an independent copy that survives the thing the snapshot lives on failing. They fail differently, they cost differently, and they’re not interchangeable no matter how similar the buttons look in the web UI. Use snapshots liberally around risky changes and clean them up when you’re done. Use PBS, or something equivalent, as the thing you’d actually reach for if the whole node died tonight. If your only recovery point right now is a snapshot, that’s worth fixing before you need it, not after.