Your Proxmox backup job is probably skipping your new VMs

Open your Proxmox web UI, click your backup storage and sort by date. Is there a backup of every guest you care about from the last 48 hours? For a lot of homelabs the honest answer is "most of them", and "most" is how data gets lost.

A backup job in the Datacenter view looks reassuring. It has a schedule, a storage target and a little green check. That check proves one thing: the job wrote some bytes somewhere. It does not prove that every guest you care about is in there.

The trap: a job built for "selected VMs"

The most common way this goes wrong is the selection mode. Somebody (often past you) created the job for "selected VMs" when the homelab had five guests. Every guest built after that day is unprotected, and the job keeps reporting success every night, because the guests it knows about are fine.

Nothing errors. Nothing emails you. The list of protected guests and the list of running guests just drift apart, one new container at a time.

The fix: one job that covers everything

Make your main job cover all guests, and exclude the few you truly do not want. New guests are protected the day they are created. If you only make one change after reading this, make this one.

In the UI: Datacenter → Backup → Add, then:

• Selection mode: All, with scratch and test guests under Exclude.
• Mode: Snapshot for running guests. The guest keeps running. Stopped guests are backed up too; Proxmox just reads their disks, and the forgotten stopped VM is often the one you will want back.
• Compression: ZSTD. Fast and small.
• Schedule: nightly, at a time nobody is using anything, for example 02:30.
• Retention: "use storage defaults", so the numbers live in one place.
• Notes template: {{guestname}} on {{node}}, so the backup list is readable when a VM ID means nothing to you at 2 AM.

The same job from the command line, if you like to keep config in version control:

pvesh create /cluster/backup \
  --schedule "02:30" \
  --all 1 \
  --storage nas-backup \
  --mode snapshot \
  --compress zstd \
  --notes-template "{{guestname}} on {{node}}"

Need to leave out a scratch VM? Use --exclude 9001,9002 instead of switching back to selected guests. An exclude list fails safe; an include list fails dangerous. If you forget to update an exclude list, you back up one guest too many. If you forget to update an include list, you lose a guest.

Three other things hiding behind the green check

The selection mode is the big one, but it is not the only way a "working" job quietly stops protecting you.

1. The storage silently isn't there

If your NAS is added as a plain Directory storage on a path you mounted yourself, and that mount fails at boot, Proxmox will happily write backups into the empty folder on your root disk. A night or two later the host's root filesystem is full and things break in confusing ways.

Either use the native NFS storage type, which lets Proxmox manage the mount and mark the storage offline if it fails, or tell Proxmox the path must be a mountpoint:

pvesm set nas-backup --is_mountpoint yes

And check before you trust it:

pvesm status                 # every storage should say "active"
df -h /mnt/pve/nas-backup    # should show the NAS size, not the root disk

2. Nobody gets told

By default, failures go to the root mailbox on the host, which nobody reads. Proxmox VE 8.1 and later has a proper notification system under Datacenter → Notifications. Add a target you actually read, point backup events at it, and set the job's notification mode to use it. Then test it on purpose:

vzdump 101 --storage does-not-exist

If no alert arrives, fix that before anything else. A weekly "all good" message is worth having too: silence is ambiguous, and a success message that suddenly stops arriving is a signal.

3. Nothing gets pruned

Without retention, the backup share fills up and every job after that fails. Set retention on the storage itself so every job that writes there inherits it:

pvesm set nas-backup \
  --prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3

Those numbers do not mean what most people think they mean. That is a post of its own.

Prove it: a backup you haven't restored is a rumor

A green check says the job finished writing. A quick integrity check says the archive is readable end to end:

zstd -t /mnt/pve/nas-backup/dump/vzdump-qemu-101-*.vma.zst

Only a restore proves the guest actually comes back. Restore to a spare ID, with the network disconnected so it does not fight the original for an IP, boot it, look around, then destroy the test copy:

qmrestore /mnt/pve/nas-backup/dump/vzdump-qemu-101-<date>.vma.zst 9101 \
  --storage local-zfs --unique 1

--unique gives the restored VM fresh MAC addresses so it can sit next to the original.

Checklist

• One backup job set to All guests (with excludes), not a hand-picked list
• Backup storage is native NFS or PBS, or has is_mountpoint set
• Retention set on the storage
• Failure notifications reach somewhere you actually read, and you have tested them
• The newest backup of every guest is less than 48 hours old
• One test restore done, to a new ID, and written down with the date

Five minutes in the Datacenter view now is a lot cheaper than finding out during a restore that the VM you need was never in the job.

Found this useful? Subscribe on YouTube for the daily video, or follow the RSS feed.