Featured image of post Automated Proxmox VE backups with Proxmox Backup Server and sane retention

Automated Proxmox VE backups with Proxmox Backup Server and sane retention

Backups are the one part of a homelab that everybody configures once and never tests again. Proxmox VE ships with vzdump and a scheduler, which is enough for a single node, but once you have a handful of guests you want deduplication, encryption and — most importantly — a restore path you have actually executed.

This is the setup I run: a dedicated Proxmox Backup Server (PBS) with one datastore per site, nightly prune/verify jobs, and a quarterly restore drill.

What you need

  • Proxmox VE 8.x with at least one node
  • A separate host (physical or a VM with its own disk) for Proxmox Backup Server 3.x
  • A second disk or a NAS share for the datastore — never the same physical disk as the hypervisor
  • Roughly 1.5x the size of your used guest storage for the first month of retention

1. Prepare the PBS datastore

On the PBS host, add the backup disk and create a datastore with a garbage-collection schedule:

# /etc/proxmox-backup/datastore.cfg
cat > /etc/proxmox-backup/datastore.cfg <<'EOF'
datastore: homelab
	path /mnt/datastore/homelab
	gc-schedule daily
	keep-daily 14
	keep-weekly 8
	keep-monthly 6
EOF

The keep-* values are a policy, not a promise: PBS applies them when a prune job runs. Keep them aligned with the retention you intend to honour, and remember that a datastore with keep-daily 14 holds *at most* fourteen daily snapshots before garbage collection reclaims space.

2. Add the storage on Proxmox VE

PBS speaks its own protocol over port 8007. Create an API token and register the storage:

proxmox-backup-manager user create backup@pve
proxmox-backup-manager acl update /datastore/homelab BackupRole --auth-id backup@pve
proxmox-backup-manager user generate-token backup@pve pve01

# on the PVE node
pvesm add pbs pbs-homelab \
  --server pbs.lan \
  --datastore homelab \
  --username backup@pve \
  --password '<token-secret>' \
  --fingerprint 'AA:BB:CC:...' \
  --content backup

Always pass the certificate fingerprint. Without it the storage falls back to a trust-on-first-use check and a reinstall of PBS silently breaks every job.

3. Schedule the backup job

Do it from the datacenter scheduler so it is visible in the UI:

pvesh create /cluster/backup \
  --schedule '02:30' \
  --storage pbs-homelab \
  --mode snapshot \
  --compress zstd \
  --all 1 \
  --exclude 900 \
  --mailnotification failure \
  --notes-template '{{guestname}}/{{node}}'

--mode snapshot requires either QEMU with a snapshot-capable storage (LVM-thin, ZFS, Ceph) or LXC on ZFS/btrfs. On plain LVM or directory storage you get suspend, which briefly pauses the guest — acceptable, but know which one you are getting.

A nightly full backup of everything sounds expensive and, with PBS, mostly is not: unchanged chunks are not re-uploaded. What does grow is metadata, so leave headroom.

4. Verify, then verify again

A backup you have not verified is a rumour. PBS verification reads back every chunk and checks its checksum:

proxmox-backup-manager verify homelab --backup-type vm
# schedule it
pvesh create /admin/datastore/homelab/verify-job \
  --schedule 'sat 04:00' --ignore-verified true --outdated-after 30

The important knob is --outdated-after: it re-verifies a snapshot when the last verification is older than 30 days, instead of every week.

5. The restore drill

Once a quarter, restore one guest to a scratch VMID and boot it:

# list snapshots
proxmox-backup-client snapshot list --repository backup@pve@pbs.lan:homelab

# restore the newest one to a new VMID
qmrestore pbs-homelab:backup/vm/105/2026-10-27T02:30:11Z 905 --storage local-lvm
qm start 905

If the restored guest boots and answers on the network, your backups work. If it does not, you just found out in a controlled way instead of at 3 a.m.

Pitfalls I have hit

  • Same disk for datastore and hypervisor. Deduplication does not save you from a dead controller. Keep the datastore off-box.
  • **keep-* set on the datastore but a prune job with different values.** The prune job wins. Pick one place.
  • Encryption enabled after the fact. Turning on encryption only affects new snapshots; old ones stay unencrypted. Decide on day one.
  • Snapshot mode on non-snapshot storage. The job succeeds with a suspend, which is not what you wanted for a busy database VM.

With the scheduler, prune and verify jobs in place this is a set-and-forget system — as long as the restore drill stays on your calendar.

Built with Hugo
Theme Stack designed by Jimmy