Short answer
A Proxmox snapshot is a rollback point on the same storage as the guest: taken in seconds, rolled back in seconds, but gone if that disk or host fails. A backup (vzdump or Proxmox Backup Server) is a full, independent copy on other storage: slower to make and to restore, but it survives hardware loss. Use a snapshot right before a risky change; use scheduled backups for real protection. You need both.
Proxmox snapshot vs backup at a glance
| Aspect | Snapshot | Backup (vzdump / PBS) |
|---|---|---|
| What it is | Frozen state of the guest's disks (and optionally RAM) | Self-contained copy of disks and config |
| Where it lives | Same storage as the guest | Separate backup storage or Proxmox Backup Server |
| Time to create | Seconds | Minutes to hours (PBS: only changed data after the first run) |
| Time to recover | Rollback in seconds | Restore copies the data back |
| Survives disk or host failure | No | Yes, if stored elsewhere |
| RAM state | Optional for VMs (vmstate) | No |
| Storage requirement | Snapshot-capable storage (ZFS, LVM-thin, Ceph RBD, qcow2) | Any storage with the backup content type, or PBS |
| Retention | Manual; Proxmox never prunes snapshots | Keep-last, daily, weekly, monthly rules per job |
| Command | qm snapshot / pct snapshot | vzdump |
| Best for | Undo button before an upgrade or config change | Disaster recovery, history, off-site copies |
The rest of this guide explains both in more depth: how to take and roll back snapshots, the three vzdump backup modes (snapshot, suspend, stop), retention, Proxmox Backup Server, and how to manage all of it across several hosts.
Why a snapshot is not a backup
A snapshot works by recording only what changes after the moment you take it (copy-on-write). That is why it is so fast, and also why it depends completely on the original disk: the snapshot and the guest share the same storage volume. If the pool fails, the disk dies or someone deletes the VM, the snapshots go with it. A long chain of snapshots also costs performance and space, because every change is tracked against each of them.
A backup is the opposite: vzdump reads the whole guest and writes a standalone archive
(.vma.zst for VMs, .tar.zst for containers) or sends the data to a Proxmox
Backup Server. The guest does not need to exist to restore it; you can restore onto a completely
different node.
Taking, listing and rolling back a Proxmox snapshot
In the web UI, snapshots live on each guest's Snapshots tab. On the command line:
# VM 100: snapshot before an upgrade (add --vmstate 1 to include RAM)
qm snapshot 100 pre-upgrade --description "before apt full-upgrade"
qm listsnapshot 100
qm rollback 100 pre-upgrade
qm delsnapshot 100 pre-upgrade
# Container 200: same idea with pct
pct snapshot 200 pre-upgrade
pct rollback 200 pre-upgrade
pct delsnapshot 200 pre-upgradeWith the RAM state included, a rolled-back VM resumes exactly where it was, running processes and all. Without it, the VM comes back with the disk state and boots from there. Either way, everything written after the snapshot is discarded, so roll back only when you really want to undo.
A typical change routine:
- Take a snapshot with a descriptive name, for example
pre-upgrade-2026-10-13. - Apply the upgrade or change.
- Test the service.
- Broken? Roll back. Working? Delete the snapshot to free the space it holds.
Proxmox has no built-in scheduler for snapshots (it only schedules backups). If you want hourly
rolling snapshots, run qm snapshot from cron or a script against the API, and delete old
ones in the same script. More on that on the Proxmox snapshots page.
Backup modes: snapshot vs suspend vs stop
vzdump has three modes. The names cause confusion: "snapshot" mode is a backup, not a Proxmox snapshot. It only means the guest keeps running while it is copied.
| Mode | Downtime | How it works | Use it for |
|---|---|---|---|
| Snapshot | None to minimal | VMs: live backup through QEMU while the guest runs (the QEMU guest agent can freeze the filesystem for consistency). Containers: needs snapshot-capable storage; otherwise vzdump falls back to suspend mode. | The default for almost everything |
| Suspend | Short | Containers: copies while running, then pauses briefly to copy the rest. VMs: kept mainly for compatibility; the Proxmox docs recommend snapshot mode instead. | Containers on storage without snapshots |
| Stop | For the duration of the backup | Shuts the guest down cleanly, backs it up, starts it again. | The most consistent copy, for example a database you can take offline |
# one-off backup of VM 100 to the storage "backup-nfs", running guest, zstd compression
vzdump 100 --mode snapshot --storage backup-nfs --compress zstd
Compression: zstd is the default choice today, fast with good ratios. When the target is a
Proxmox Backup Server, compression and deduplication happen on the PBS side.
Scheduled backup jobs and retention
Real protection means unattended jobs. Under Datacenter → Backup you define which guests, which storage, when (for example daily at 02:00) and how long to keep the results. Spread the jobs across nodes if they share storage, so they do not all hit the disks at the same time.
Retention is set per job with rules like keep-last, keep-daily,
keep-weekly and keep-monthly. Proxmox prunes old archives after each run. Without
retention rules, backups pile up until the target storage is full, which usually gets noticed on the
night a backup fails.
Proxmox Backup Server: incremental and deduplicated
Proxmox Backup Server (PBS) is the backup target built for Proxmox VE. After the first full backup it only transfers changed data, and identical chunks are stored once across all guests, so many restore points cost far less space than the same number of vzdump archives. PBS can also verify stored backups (re-reading and checking the chunks), and for VMs Proxmox VE supports a live restore that starts the VM while the data is still streaming back.
You attach a PBS datastore under Datacenter → Storage (type pbs, with server address,
datastore name, fingerprint and credentials). From then on it appears as a backup target like any other
storage. For production, PBS on separate hardware (or a remote PBS) is the recommended setup.
Which one should you use?
- Before a risky change (kernel upgrade, major application update, config experiment): snapshot, then delete it once the change is proven.
- Against hardware failure, deletion and ransomware: scheduled backups to separate storage, ideally PBS, with retention rules.
- For anything that matters: both. Snapshots protect you from mistakes; backups protect you from data loss.
Snapshots and backups across several hosts in NexoVirt
With several Proxmox hosts or clusters, the per-host web UIs make this tedious: every snapshot and every restore means finding the right node first. NexoVirt puts it on each guest's page instead: take a snapshot before a change, roll back with a confirmation step, delete it when you are done, run a backup now, browse a guest's backups and restore one, from one panel for all hosts. Proxmox Backup Server connections, prune policies and backup jobs are managed in the same place, and the REST API covers snapshot create, rollback and delete for scripting. Hosting customers can even take and roll back their own snapshots in the customer portal.
The rest of the feature set (OS templates, IPAM, NAT, plans, customer portal, alerting, REST API) is on the features page.