Intermediate

Proxmox Backups

Proxmox Backup Server, why a snapshot is not a backup, and setting up schedules and retention you can actually trust.

Backups Updated August 29, 2026

  • proxmox-backup-server
  • backups
  • snapshots
Before this, read:

Backups 101 covered the underlying 3-2-1 principle - 3 copies, 2 media types, 1 off-site. Everything here is that same principle applied to VMs and LXC containers instead of Docker bind-mounted volumes.

Snapshots are not backups

This needs to be stated plainly because it's the most common false sense of security at this tier: a ZFS or Proxmox snapshot (see Storage and ZFS) is a point-in-time reference stored on the same disk, same pool, same machine as the live data. It protects you from a bad config change or update - roll back in seconds. It does not protect you from:

  • The disk or pool itself failing
  • The whole host being stolen, flooded, or catching fire
  • Ransomware or a mistake that corrupts the pool itself, not just one guest's data
  • Deleting the wrong pool/dataset entirely

A backup is a copy that exists independently of the system it's protecting - different disk, ideally different building. If your only copy of a VM's disk is a snapshot next to that same VM's disk, you have a rollback feature, not a backup.

Proxmox Backup Server (PBS)

Proxmox Backup Server is a separate, free, purpose-built backup application from the same project as Proxmox VE - it stores deduplicated, incremental, client-side-encrypted backups of your VMs and containers, and integrates directly into the Proxmox VE web UI once added as a storage target.

Run it as its own VM (ironically, not backed up by itself - see below) or on separate physical hardware entirely, which is the stronger option since it decouples the backup target from the thing being backed up.

Add it to Proxmox VE: Datacenter > Storage > Add > Proxmox Backup Server, pointing at the PBS instance's address and an API token or credentials. Once added, it appears as a backup target when configuring backup jobs.

Resource expectations: modest - 2-4GB RAM and a couple of cores is enough for homelab-scale backup volumes; the real resource that matters is disk space on the backup target, sized for your retention policy (below).

Backup schedules and retention

Datacenter > Backup > Add in the Proxmox VE web UI:

  • Select which guests to include (or all of them)
  • Set a schedule (a nightly window during low-usage hours is typical)
  • Choose the PBS storage target
  • Set a retention policy - PBS supports keeping, for example, the last 7 daily, 4 weekly, and 6 monthly backups automatically, pruning older ones on its own

A reasonable starting retention for a homelab: 7 daily + 4 weekly + 3 monthly. Adjust based on how much you're willing to lose (recovery point) versus how much disk space you're willing to spend.

Example retention:
  keep-last: 7
  keep-weekly: 4
  keep-monthly: 3

Getting a real off-site copy

PBS itself supports sync jobs to a second PBS instance, which is the cleanest way to get an off-site copy of your VM/container backups

  • a small PBS instance at a relative's house, or a cloud VM running PBS, syncing on a schedule over your VPN (see Remote Access) rather than an exposed port.

If a second PBS instance is more than you want to run, PBS backups (and, separately, your restic-based file backups from Backups 101) can also be pushed to any generic off-site/cloud target you're already using - the point is that something leaves the building, on whatever schedule you can sustain.

⚠️ Risk: don't rely solely on backing up your PBS datastore with its own snapshot mechanism if that datastore lives on the same pool as everything it's backing up. Keep at least one copy of your backup data physically or logically separate from your primary Proxmox host's storage.

What "done" looks like for Intermediate

If you've worked through this tier in order, you now have: Proxmox running VMs and LXC containers with sensible resource limits, ZFS storage with snapshotting, a segmented network keeping IoT and guests away from your infrastructure, services behind a reverse proxy with real TLS, VPN-based remote access instead of forwarded ports, centralized NAS storage, basic uptime and metrics monitoring with alerts that reach you, and automated, tested, off-site-capable backups of your VMs and containers.

That's a mature, resilient homelab - and, as noted back at the start of this tier, a completely legitimate place to stop. If you want multi-node resilience, infrastructure-as-code, and deeper operational discipline beyond this, that's what Advanced covers - and it's honest about the fact that most of it is optional complexity for a home network, not a strict upgrade.