I like Proxmox snapshots. Before a risky upgrade, a config change I'm not fully sure about, or a dist-upgrade on a VM I'd rather not rebuild from scratch, taking a snapshot is a ten-second insurance policy. If something goes wrong, qm rollback puts the VM back exactly where it was. That's genuinely useful, and I use it often.
The problem is when that same snapshot gets treated as the backup strategy, because the two solve different problems, and the gap between them only shows up at the worst possible time.
What a snapshot actually is
A Proxmox snapshot doesn't copy the VM's disk. It freezes the current state and starts tracking changes as a delta, the original data stays exactly where it was, on the same storage, on the same host. This is why snapshots are fast to create and don't immediately use extra space, and it's also exactly why they don't help if that storage or that host has a problem.
# Take a snapshot before a risky change
qm snapshot 101 pre-upgrade
# If it goes wrong, roll back
qm rollback 101 pre-upgrade
If the upgrade breaks something inside the VM, this is perfect, thirty seconds and you're back to a known-good state. If the host's disk fails, or the host itself doesn't come back up, the snapshot is gone along with everything else, because it was never anywhere else.
What an actual backup needs
A backup needs to exist somewhere that a problem with the VM, or the host, or the storage, doesn't also take out the backup. Proxmox's built-in vzdump does this by writing a full copy of the VM to a separate target:
vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
The --mode snapshot here is doing something different from a Proxmox snapshot you'd roll back to, it briefly uses snapshot mechanics so the VM doesn't need to be stopped, but the output is a complete standalone archive written to backup-nfs. That archive doesn't depend on the original disk still existing.
For anything beyond a single host, Proxmox Backup Server is worth running, it adds deduplication and incremental backups on top of this, so daily backups of a large VM don't mean daily full copies, while still producing restorable archives that live independently of the source.
The test that actually matters
Just like with database backups, the only way to know a Proxmox backup is good is to restore it, ideally onto different storage or a different host than the original:
qmrestore /mnt/backup-nfs/dump/vzdump-qemu-101-*.vma.zst 201 --storage local-lvm
If that restore produces a VM that boots and looks right, the backup is real. If it doesn't, that's something worth knowing now rather than during an actual recovery.
The split I use
Snapshots, for the "I'm about to do something I might need to undo in the next ten minutes" case: upgrades, risky config changes, testing something destructive. They're cheap, fast, and exactly right for that job. vzdump to separate storage, or Proxmox Backup Server, for the "this VM needs to still exist if this host doesn't" case: scheduled, off the host, and tested with an actual restore now and then.
Both have a place. The mistake is letting the convenience of the first one quietly take over the job of the second, right up until the day a host-level problem makes the difference very obvious, and very expensive.