Our Proxmox backup setup, and why we restore something every month

When we inherit a Proxmox cluster, backups are one of the first things I look at. Proxmox makes them easy to turn on, which also makes it easy to assume you're covered when you aren't. This is what we run for our own cluster and for clients: which vzdump mode we pick, how we schedule and prune, why I think Proxmox Backup Server is worth the extra box, and the restore testing that tells you whether any of it works.

A snapshot isn't a backup

A Proxmox snapshot is a point-in-time state stored on the same storage as the VM. It's perfect for "I'm about to upgrade this and want to roll back in five minutes if it goes badly." It does nothing for you if the storage fails, the pool fills, someone deletes the VM, or ransomware reaches the host. Long-lived snapshots also slow down some storage types and eat space as the disk changes. Take them before a change and delete them after. Backups are separate copies on separate storage.

Picking a vzdump mode

• Snapshot mode keeps the guest running while it's backed up. For VMs, Proxmox uses QEMU's live backup mechanism, and with the QEMU guest agent installed and enabled it briefly freezes the guest filesystems for consistency. For containers it needs storage that supports snapshots, or it falls back to suspend mode. This is our default.
• Suspend mode, for containers, copies data while running and then suspends the container briefly for a final sync. For VMs it offers little over snapshot mode and causes a pause.
• Stop mode shuts the guest down, backs it up and starts it again. It's the most consistent, at the cost of downtime. We use it for a few legacy systems whose databases don't tolerate live backup well.

Install and enable the QEMU guest agent on every VM: qemu-guest-agent on Linux, the VirtIO guest tools on Windows, and the Guest Agent option in the VM settings. Without it, snapshot-mode backups are crash-consistent, not filesystem-consistent.

A one-off manual backup looks like this:

vzdump 101 --mode snapshot --storage backup-nfs --compress zstd --notes-template '{{guestname}} manual'

Scheduling, and why hand-picked lists go wrong

Create jobs under Datacenter, Backup in the GUI. They're stored cluster-wide in /etc/pve/jobs.cfg and run on whichever node holds each guest. We usually run one nightly job for everything, outside business hours, selecting by pool or by "all" with exclusions instead of a hand-picked list of VM IDs. Hand-picked lists are how a new VM ends up never backed up.

Point the job's failure notifications at someone who actually reads that inbox. A backup job that's been failing silently for three weeks is the most common problem we find on inherited clusters.

How long to keep things

Retention is set with prune options on the job or on the storage. For most small environments we start here:

keep-last=3, keep-daily=7, keep-weekly=4, keep-monthly=6

On the command line the same thing is:

vzdump 101 --storage backup-nfs --prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6

That gives you a week of dailies, a month of weeklies and half a year of monthlies. The monthlies are what save you when someone notices that data went missing back in the spring.

Proxmox Backup Server is worth the extra box

Backing up to a plain NFS share works, but every backup is a full compressed archive. PBS changes that in a few ways:

• Data is stored in chunks and identical chunks are stored once, so nightly backups of mostly unchanged VMs take a small fraction of the space.
• With dirty bitmaps, a running VM only sends changed blocks after the first backup, so jobs finish much faster.
• Verify jobs re-read chunks and check their checksums on a schedule, which catches silent corruption before you need the backup.
• Sync jobs to a second PBS offsite give you the offsite copy in a 3-2-1 setup.
• You also get file-level restore from the GUI, encryption, and per-user permissions.

On PBS, schedule prune, garbage collection and verify jobs per datastore. Prune only marks old snapshots for removal. Garbage collection is what actually frees the space.

Restore to a new ID and actually boot it

A backup you've never restored is a hope, not a backup. Restore to a new VM ID so the production guest is left alone:

# VM from a vzdump archive on file storage
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-101-2026_10_01-02_00_03.vma.zst 9101 --storage local-lvm --unique

# VM from PBS (volume ID as shown by pvesm list)
pvesm list pbs01 --vmid 101
qmrestore pbs01:backup/vm/101/2026-10-01T09:00:03Z 9101 --storage local-lvm --unique

# Container
pct restore 9201 /mnt/pve/backup-nfs/dump/vzdump-lxc-201-2026_10_01-02_10_44.tar.zst --storage local-lvm

Before you boot the copy, take it off the network. Otherwise it can fight the production guest for its IP or start sending email.

qm set 9101 --net0 virtio,bridge=vmbr0,link_down=1
qm start 9101

When you rewrite net0, keep the NIC model and bridge that qm config 9101 shows. Then open the console and confirm the OS boots, services start and the data is current. Delete the test guest when you're done.

We restore something every month. If the dated note for an important system is more than a month old, that restore is the next thing on my list.