Proxmox & home lab7 min read

Proxmox Backup Strategy: Complete Guide

A Proxmox backup plan that survives a dead disk: vzdump jobs and retention, Proxmox Backup Server, host config, off-site copies and tested restores.

In this article 15
  1. Key Takeaways
  2. The goal: the 3-2-1 rule, scaled to a home lab
  3. What I run, and what is still missing
  4. Snapshots are not backups
  5. Built-in backups with vzdump
  6. Schedule it and set a retention policy
  7. Keep big data out of guest backups
  8. Back up the host configuration
  9. Proxmox Backup Server: when it is worth it
  10. Getting a copy out of the house
  11. Test your restores
  12. Common problems
  13. FAQ
  14. Recommended Gear
  15. Related Articles

Key Takeaways

  • Snapshots are not backups: they live on the same storage as the guest and die with it. A backup is a copy on different hardware.
  • Built-in vzdump jobs with a retention policy cover most home labs; Proxmox Backup Server adds deduplication, incremental backups, verification and encryption.
  • Back up the host configuration too (/etc/pve, network config), and keep large data such as media or photo libraries out of the guest backups with their own copy.
  • A backup you have never restored is a hope, not a backup. Restore to a new ID on a schedule.

The goal: the 3-2-1 rule, scaled to a home lab

The classic rule says three copies of your data, on two different media, one of them off-site. For a home lab that usually means:

  1. The live guests on the Proxmox host.
  2. A nightly backup on a different disk or machine in the house.
  3. A copy somewhere else: a second server at a relative’s place, a remote Proxmox Backup Server, or encrypted cloud storage.

Every step below serves one of those three copies.

What I run, and what is still missing

On my own host, one backup job runs every night at 03:00. It covers every guest except one, uses snapshot mode with zstd compression, keeps the last two backups and writes them to a USB disk attached to the host. The photo library is too big for that disk, so it is excluded from the guest backup and gets its own nightly export to the NAS.

It covers the failure it was built for, a broken guest or a dead system disk. But it is honest to say what it does not do: every copy lives in the same house, and two versions are a short history. The off-site copy and a longer retention are the next steps, and they are exactly the parts of this guide most home labs skip.

Snapshots are not backups

A snapshot freezes a guest’s disk at a point in time on the same storage pool. It is perfect before an upgrade: take it, upgrade, roll back in seconds if something breaks. It does nothing if the SSD dies, the pool gets corrupted or you delete the guest. Keep snapshots short-lived and treat them as an undo button.

Built-in backups with vzdump

vzdump is the tool behind every backup in the Proxmox web UI. It writes one archive per guest to any storage marked for backup content (a local directory, a USB disk, an NFS or SMB share).

Backup modes:

  • snapshot: the guest keeps running. VMs are backed up live through QEMU; containers use a storage snapshot when available. This is the right default.
  • suspend: the guest is paused briefly. Rarely needed today.
  • stop: the guest shuts down for the backup. The most consistent result for databases that cannot handle a live copy, at the cost of downtime.

A one-off backup from the shell:

vzdump 105 --mode snapshot --compress zstd --storage usb-backup

zstd is fast and compresses well; it is the sensible choice on any recent CPU.

Schedule it and set a retention policy

Create the job under Datacenter → Backup → Add: pick the guests (or all), the storage, the time and the mode. Then set retention on the Retention tab instead of keeping everything forever. A policy that suits most labs:

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

That gives you a week of daily restore points, a month of weekly ones and half a year of monthly ones, while the oldest archives are pruned automatically. The same job saved in /etc/pve/jobs.cfg looks like this:

vzdump: nightly
	schedule 03:00
	all 1
	mode snapshot
	compress zstd
	storage usb-backup
	prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6
	notes-template {{guestname}}

Turn on notifications for failed jobs. A backup that silently stopped working three weeks ago is the most common way people discover they have nothing to restore.

Keep big data out of guest backups

Photo libraries, media collections and camera recordings bloat every nightly archive. Keep them on a separate volume or share and back them up with a tool built for files, such as rsync, restic or the NAS’s own replication.

For container mount points you can exclude a volume from vzdump:

mp0: local-lvm:vm-114-disk-1,mp=/data,backup=0

Bind mounts from the host (mp0: /mnt/photos,mp=/photos) are never included in container backups, which is convenient, but it also means you must back up that data yourself.

Back up the host configuration

Guest backups restore guests, not the host. If the Proxmox system disk dies, you also want:

  • /etc/pve (guest configs, storage definitions, users, firewall rules). It is a view of the cluster database in /var/lib/pve-cluster/config.db; copying either works.
  • /etc/network/interfaces, /etc/hosts and any custom files you added (cron jobs, scripts, UPS or monitoring configs).

A simple nightly copy is enough:

tar czf /mnt/usb-backup/host/pve-host-$(date +%F).tar.gz \
  /etc/pve /var/lib/pve-cluster/config.db /etc/network/interfaces /etc/hosts

Proxmox Backup Server: when it is worth it

Proxmox Backup Server (PBS) is a separate product that Proxmox VE backs up to. Compared with plain vzdump archives it gives you:

  • Deduplication: identical chunks are stored once, so daily backups of slowly changing guests take little space.
  • Incremental backups: after the first run, VMs send only changed blocks, so jobs finish in minutes.
  • Verification: scheduled jobs check that stored chunks are still readable.
  • Encryption on the client side, and sync jobs to a second PBS for the off-site copy.
  • File-level restore: browse a backup and pull out a single file without restoring the whole guest.

Run PBS on separate hardware if you can (a small mini PC with a large disk is enough); running it as a VM on the same host protects against mistakes but not against losing the host. Add it to Proxmox VE under Datacenter → Storage → Add → Proxmox Backup Server, or from the shell:

pvesm add pbs pbs-home --server 192.168.1.50 --datastore homelab \
  --username backup@pbs --fingerprint <sha256 fingerprint from PBS dashboard>

Then point your backup job at pbs-home.

Getting a copy out of the house

Pick whichever fits your situation:

  • A second PBS elsewhere with a pull sync job: the cleanest option, and the remote copy is deduplicated too.
  • Encrypted cloud storage for the vzdump directory, using rclone with a crypt remote or restic. Upload the archives after the nightly job.
  • A rotated USB disk you swap every week and keep at work or with family. Low tech, and it works.

Whatever you choose, encrypt it and write down the key somewhere that is not the server you are protecting.

Test your restores

Restore to a new guest ID so the original keeps running:

# container from a vzdump archive
pct restore 205 /mnt/usb-backup/dump/vzdump-lxc-105-2026_10_01-03_00_02.tar.zst --storage local-lvm
# VM from a vzdump archive
qmrestore /mnt/usb-backup/dump/vzdump-qemu-120-2026_10_01-03_10_44.vma.zst 220 --storage local-lvm

Start the restored guest with its network disconnected, check that the service and its data are there, then delete it. Doing this once a quarter for your most important guests turns a backup plan into something you can rely on.

Common problems

  • Backups fill the disk: there is no retention policy, or it is too generous. Add prune-backups to the job and check the storage usage graph.
  • Container backups are slow or fall back to suspend mode: the storage under the container does not support snapshots. LVM-thin, ZFS and Ceph do; plain directories do not.
  • A database comes back inconsistent: use stop mode for that guest, or dump the database to a file before the job runs and back up the dump.
  • Jobs run while you work and slow everything down: move them to the night and set a bandwidth limit (bwlimit) on the job if the target is a network share.

FAQ

What is the difference between a snapshot and a backup in Proxmox?

A snapshot is a point-in-time state of a guest stored on the same storage, useful for quick rollbacks. A backup is a full copy written to separate storage, which is what protects you from hardware failure, corruption or deletion.

Do I need Proxmox Backup Server for a home lab?

Not to start. vzdump jobs to a separate disk with a retention policy are a solid base. PBS becomes worth it when backups get large, when you want daily backups without the space cost, or when you want an encrypted off-site copy with sync jobs.

Which backup mode should I use?

Snapshot mode for almost everything, because guests keep running. Use stop mode for guests whose data cannot be copied live safely, typically databases without their own dump step.

How many backups should I keep?

Enough to go back before a problem you notice late. Seven daily, four weekly and six monthly is a good default; keeping only the last one or two covers a dead disk but not a mistake you discover a week later.

How do I back up the Proxmox host itself?

Copy /etc/pve (or /var/lib/pve-cluster/config.db), the network configuration and any custom files. With those and your guest backups, a fresh Proxmox install can be brought back to the same state.

If you want to build this setup, this is where I would start:

Affiliate links: if you buy through them I earn a small commission, at no extra cost to you.

The end. Thanks for reading.

Keep reading.