Proxmox Backup Strategy: vzdump, Snapshots, and Offsite

The short version for a Proxmox VE host:

• Snapshots are a rollback button, not a backup. They live on the same storage as the disk they protect and die with it.
• vzdump is the actual backup tool. Snapshot mode for anything running, stop mode for anything you cannot afford to restore inconsistent.
• Install the QEMU Guest Agent. Without it a live backup is crash-consistent; with it, Proxmox can freeze the guest filesystem first.
• Back up /etc/pve, not just the guests. vzdump does not save the hypervisor that runs them.
• A backup you have never restored is a hypothesis. Restore to a spare VMID on a schedule.

Everything else — compression, retention tiers, dedup, tape — is tuning on top of those five.

Snapshots are not backups

Proxmox makes snapshots so cheap that people quietly promote them to disaster recovery, and it works right up until it doesn’t. A snapshot taken with qm snapshot or pct snapshot is a point-in-time reference held by the storage layer — ZFS, LVM-thin, Ceph RBD, btrfs, or a qcow2 image — sharing physical blocks with the live disk. That is what makes it instant, and what makes it worthless in the failure modes you are insuring against:

• Storage loss. If the pool, the thin LV, or the RBD image is gone, every snapshot of it is gone at the same instant.
• Guest deletion. Destroying a VM destroys its snapshots. One wrong VMID in a cleanup script and the safety net leaves with the trapeze.
• Node loss. Snapshots on local storage exist nowhere else in the cluster.
• Anything ransomware-shaped with root on the host. Same credentials, same storage, same blast radius.

Snapshots are still worth taking. They are the right tool for a ten-minute window around a kernel upgrade or a config change you expect to undo. Take one, do the risky thing, delete it the same day.

The underestimated cost is keeping them. On qcow2 and LVM-thin, a long-lived snapshot means the live image accumulates divergence and write performance degrades; deleting a deep chain later is I/O-heavy and can stall the guest at the worst moment. ZFS and Ceph handle retention more gracefully, but a snapshot sitting there since March still holds space you thought you had.

Be pedantic about one more thing: a snapshot taken without the memory state (vmstate) only captures disk. Rolling back looks to the guest like a power cut — fine for Linux on a journaling filesystem, not fine for a database mid-transaction.

The three vzdump modes

vzdump produces a portable, restorable archive — a .vma for QEMU guests, a .tar for LXC containers, or deduplicated chunks if you target Proxmox Backup Server. Every scheduled backup job in the web UI is vzdump underneath, and every job picks one of three modes.

stop takes the guest offline so nothing is writing, which makes the archive exactly the on-disk state. The downtime is not the same for both guest types, and this trips people up. For a VM, Proxmox performs an orderly shutdown, starts the backup process, and returns the VM to full operation as soon as that process is running — a short outage, not one that scales with how much data is copied. A container in stop mode stays down for the entire run, which on a large rootfs is a genuinely long outage. Use it where consistency beats uptime.

snapshot is the live mode and the one you will use for almost everything. QEMU guests are backed up while running, with the hypervisor tracking writes so the archive is a single point in time rather than a smeared copy. Containers in snapshot mode require storage that supports snapshots — ZFS, LVM-thin, Ceph, or btrfs. Put an LXC container on plain directory storage and snapshot mode has nothing to work with, but the job does not simply stop: vzdump logs a mode failure and falls back to suspend for that guest. The backup still lands, so nothing looks broken in the notification, while that container quietly takes the slow rsync path every night. Worth checking the task log for, rather than assuming the mode you configured is the mode you got. LXC vs VM on Proxmox covers the rest of that placement decision.

suspend exists mostly for compatibility, and it does different things to the two guest types. On a VM it suspends the guest and then hands off to the snapshot path, so you pay longer downtime for no consistency gain over snapshot alone. On a container it is an rsync copy to a temporary directory, then a suspend, then a second rsync of what changed, then a resume. Found in an old job definition it is almost always a leftover; move it to snapshot, or to stop if you genuinely need the guest quiet.

Making a live backup consistent

Snapshot mode gives you a crash-consistent image. The guest filesystem sees the equivalent of a power loss at the moment of the backup. Modern filesystems replay their journal on the next boot and carry on, so this is survivable — a lower bar than you want for the one restore that matters. Two things close the gap:

Install and enable the QEMU Guest Agent in every VM. With it running, Proxmox can ask the guest to freeze and thaw its filesystems around the backup, so the archive lands on a quiesced filesystem instead of a live one. Ticking the agent option in the VM’s Options tab without installing the package inside the guest is a classic own-goal: shutdown commands start timing out and nobody connects it to the checkbox.

Dump databases in-guest. Filesystem freeze does not make PostgreSQL or MySQL transactionally consistent — it makes the files consistent. For anything with a write-ahead log, run a native dump inside the guest, write it where the VM backup picks it up, and treat the VM archive as the container for that dump.

Backups also compete with production for I/O. vzdump accepts a bandwidth limit (bwlimit, in KiB/s, per job or as a default in /etc/vzdump.conf) — the first knob to reach for when a nightly job makes guests feel sticky. Recent Proxmox VE releases also offer backup fleecing, which caches the original blocks in a fleecing image instead of sending them straight to the backup target, so a slow target stalls the guest less; it costs extra space on whichever storage holds that image. For compression, zstd is the sensible default.

Where backups go, and where they must not

The rule is simple and routinely violated: the backup must not share a failure domain with the thing it protects. A dump/ directory on the same ZFS pool as the VM disks is not a backup, it is a copy. It survives you deleting a VM. It does not survive the pool. In rough order of robustness:

1. A separate local disk or pool on the same node. Covers guest deletion and pool corruption. Not fire, theft, or a host that will not boot.
2. A NAS or second node over the network, mounted as NFS/CIFS/directory storage with content type backup. Covers losing the node.
3. Proxmox Backup Server. The answer beyond a single toy host. PBS does incremental, deduplicated backups, so daily runs transfer far less than a full .vma each night; it verifies stored chunks on a schedule, prunes and garbage-collects itself, supports client-side encryption so an untrusted target never sees plaintext, and can restore individual files rather than a whole guest. See the Proxmox Backup Server setup guide.
4. A second PBS instance elsewhere. Sync jobs replicate a datastore between PBS instances, which is how an offsite copy stays current without anyone hand-carrying a disk.

Without PBS, the low-effort offsite still counts: a scripted rclone of dump/ to object storage after the nightly job, or external disks rotated to another building. Encrypt before it leaves the premises.

And ZFS replication between nodes (pvesr) is not a backup either. It is a fast-failover mechanism that faithfully replicates deletions and corruption to the other node. It pairs well with high availability and badly with the idea that you are now covered.

Scheduling and retention

Keeping only last night’s run protects you against hardware, not mistakes, because most mistakes are found days later. Proxmox’s prune settings keep a tiered set — dailies, then weeklies, then monthlies — and that shape is what gives you a restore point from before the thing you did not notice.

• Stagger jobs. Every guest starting at 02:00 means every guest fighting for the same disk. Split by node or group.
• Group by importance, not convenience. The VMs you would rebuild by hand do not need the retention of the one holding ten years of records.
• Mark keepers as protected. Protected backups are exempt from pruning, which is how you hold a known-good pre-upgrade archive without disabling retention. Fill in the notes template while you are there; archives named only by VMID and timestamp are miserable to search at 2 a.m.
• Watch the failure notifications. A job that has been failing quietly for weeks is a classic way to find out you had no backups on the day you needed one. Configure notifications, then break a job on purpose once to confirm the alert arrives.

In a cluster, backup jobs are defined cluster-wide, so the target storage has to be reachable from every node that might run the guest — usually learned the first time a guest migrates and its job stops working. Cluster setup has the storage-visibility details.

Back up the hypervisor, not just the guests

vzdump backs up guests. It does not back up Proxmox. If the boot drive dies you can reinstall PVE and restore every VM — but only after rebuilding, from memory, the storage definitions, bridges and VLANs, users and API tokens, firewall rules, and cluster config.

Almost all of that lives in /etc/pve, the cluster filesystem. It is a synchronized, database-backed mount rather than an ordinary directory, so back it up by archiving its contents to a normal path and shipping that off the host alongside the guest backups. Grab /etc/network/interfaces too, since host networking lives outside /etc/pve.

Rebuilding a cluster node from those files is not a straight copy — rejoining has its own procedure — but having the config in hand turns a rebuild from archaeology into typing. Keep a plain-text runbook beside the archive.

Restores are the only test that counts

PBS verification jobs confirm that stored chunks still match their checksums. Necessary, and not the same as proving the archive boots. Schedule a real drill:

• Restore to an unused VMID with qmrestore <archive> 999 (or pct restore 999 <archive> for a container), or from the GUI’s Restore button.
• Start it on a bridge with no uplink, or with the NIC disconnected, so it cannot reach production.
• Log in. Check the application, not just the login prompt, and check the data is as current as you expected.
• Destroy the test guest.

Do this quarterly, and immediately after any change to the backup chain. Rehearse the partial restore too — pulling one file out of an archive — because that is the restore you will perform most often. For VMs backed by PBS — VMs only, not containers — the live-restore option boots the guest immediately and streams the data in behind it, which is the difference between a long outage and a short one. Read speeds are poor until a block has been pulled across, and if a live restore fails partway the VM is left in an undefined state, so it is a production recovery tool rather than the way to run your drills.

Snapshots stay in the toolbox, used as intended: taken before something risky, deleted after it works. Everything you would actually restore from lives somewhere else.

Next steps

• Proxmox Backup Server setup covers the deduplicating backend this strategy assumes.
• Proxmox ZFS storage guide explains the snapshot layer underneath it.
• Common Proxmox problems and fixes covers backup jobs that fail for storage reasons.