Proxmox Backup Server: deduplicated backups that just work

May 2, 2026

Backups are the part of homelabbing that nobody brags about until something goes wrong. Then they’re the only thing anyone cares about. This post is about the piece of infrastructure that sits quietly in the background making sure there’s something to restore to: Proxmox Backup Server.

The problem with “just do backups”

If you run a Proxmox cluster, you already know that the built-in backup tooling can write nightly snapshots to any storage the cluster can see. Pick a directory, schedule a job, done — right?

Sort of. The default Proxmox backup format (vma) works, but it has a few friction points:

• Full backups every time. Without deduplication, every nightly run copies the entire VM even if only a few files changed. A handful of VMs with large disks can eat storage quickly.
• No purpose-built retention or pruning UI. You can script it, but it’s not first-class.
• Restores require the Proxmox host itself. There’s no standalone restore path if the host is the thing that’s broken.
• No built-in offsite story. Getting backups off-site is left as an exercise to the reader.

None of these are dealbreakers if you’re running one or two VMs. But as a cluster grows, they add up.

What Proxmox Backup Server is

PBS is a standalone backup solution built by the same team behind Proxmox VE. It runs as its own application — typically on a dedicated VM or bare-metal machine — and speaks a purpose-built protocol to Proxmox hosts. From the cluster’s perspective, PBS is just another backup storage target. From the backup system’s perspective, it’s running the show.

The headline feature is client-side deduplication with chunking. Before data leaves the VM being backed up, the PBS client breaks it into variable-length chunks and only transmits chunks the server has never seen before. On subsequent runs, only changed chunks travel over the wire. This means:

• Nightly incremental backups for a busy VM can be a fraction of the full size.
• Storage efficiency compounds over time as the chunk pool grows.
• Network load is proportional to change rate, not VM size.

It’s worth understanding why this matters at the storage level. Traditional incremental backups still require a periodic full backup to “reset” the chain, because each incremental depends on the previous one. If you lose a link, the chain breaks. PBS works differently: every backup is logically a full snapshot, but physically only stores the chunks that don’t already exist in the datastore. You get the restore simplicity of a full backup and the space efficiency of an incremental. There’s no “oh no, the full from three weeks ago is corrupted” problem because the chunk store is the full, assembled on demand.

Alongside deduplication, PBS gives you:

• Authenticated and encrypted backups — data is verified with a HMAC signature so corruption is caught before it matters.
• Garbage collection and pruning — configurable retention schedules (keep N dailies, M weeklies, etc.) with a GC pass to reclaim space from expired chunks.
• A clean web UI that shows task history, datastore usage, and per-VM backup chains without digging through command-line logs.
• A standalone restore client — you don’t need the original Proxmox host running to browse and extract files from a backup.
• Sync jobs — pull or push backup data to a remote PBS instance or an S3-compatible target for offsite copies.

It is not a general-purpose backup tool. It doesn’t back up arbitrary files or non-Proxmox machines. If you want to back up a Windows workstation or a NAS share, PBS is not the right tool for that job. It knows about Proxmox VMs, containers, and their disk images, and that’s its world.

The commercial reference point: Veeam Backup & Replication

If you’ve worked in enterprise IT, you’ve probably touched Veeam. Veeam Backup & Replication is the de facto standard for VM backup in Windows and VMware environments, and increasingly for Hyper-V and physical workloads. It does deduplication, change-block tracking, instant recovery, replication, and integrates with major cloud providers for offsite storage.

It also costs real money. Licensing is per-socket or per-VM depending on the edition, and enterprise deployments are five-figure commitments. There’s a free Community Edition with meaningful limitations (10 workloads max, no enterprise features), which is genuinely useful for small homelab use — but you’ll hit its ceiling once you start running more than a handful of VMs.

The self-hosted world has several alternatives worth naming honestly:

• Veeam Community Edition — Free up to 10 workloads, Windows-only server component. Good if you’re already in a Windows ecosystem and stay within limits.
• Bacula / Bareos — Mature, powerful, genuinely enterprise-capable open-source options. The learning curve is steep; the config is verbose. Excellent if you need to back up heterogeneous systems (Linux, Windows, databases). Not a natural fit for a VM-first Proxmox environment.
• restic — A fantastic command-line backup tool for files and directories. Deduplication, encryption, multiple backends (S3, local, SFTP, B2). Not VM-aware; best used alongside something else for full VM snapshots, or directly inside VMs for file-level backups.
• Proxmox Backup Server — The obvious native choice for a Proxmox shop. VM-aware, deduplicated, first-class integration, actively maintained, free and open source.

For a homelab built around Proxmox, PBS wins the comparison cleanly on the “least friction for the most benefit” axis. The integration story alone — one-click in the Proxmox UI to add a PBS datastore, backup jobs that understand VM IDs and retention, restores that happen inside the same UI — removes most of the operational surface where things go wrong.

How it fits in a real lab

In this lab, PBS runs as a dedicated VM on the Proxmox cluster. That might sound circular — running the backup service on the thing being backed up — but it works well in practice for a few reasons.

First, PBS is lightweight. It’s not doing heavy compute; it’s receiving, chunking, storing, and syncing data. A modest VM allocation is sufficient, and the actual storage lives elsewhere.

Second, the datastore doesn’t have to be local. In this setup, the PBS datastore is an NFS export from a separate storage host — which means the storage pool survives even if the backup VM itself needs to be rebuilt. When the original local datastore hit its capacity ceiling, migrating to NFS-backed storage was straightforward: add the new datastore in the PBS UI, retarget the backup jobs, verify, and remove the old one. The transition was non-disruptive.

Throughput via an SSD-cached NFS share lands around 400 MB/s in practice — faster than spinning disk would manage and more than enough to complete full cluster backups well within a nightly window.

Third, the offsite piece completes the picture. PBS supports sync jobs that push backup data to remote targets. In this lab, nightly sync to Backblaze B2 means there’s always an offsite copy, independent of what happens to on-site storage. The sync job handles the deduplication format natively — it doesn’t re-upload chunks the remote already has.

To catch failures early, a lightweight health-check script runs on a regular interval and sends an alert if the NFS mount stops responding. A backup job silently failing because the destination disappeared is one of the more annoying failure modes — catching it at the mount level, before jobs run, means the alert fires with enough lead time to investigate.

Lessons from getting it wrong first

The original deployment used a local disk for the PBS datastore. It seemed like the simpler choice — no NFS dependency, no additional moving parts. In practice, the local disk filled up faster than expected. VM backup sizes compound as the cluster grows, and a local datastore has a hard ceiling without a disruptive disk migration.

Moving to NFS-backed storage from the start would have been the cleaner path. The tradeoff is one more dependency (the storage host must be reachable for backup jobs to run), but in a homelab with a dedicated NAS or storage VM, that dependency is usually reliable enough to be worth it.

The other lesson: test restores. This sounds obvious, and it is, and most people still don’t do it regularly. PBS makes it easy — you can browse backup snapshots in the UI and restore individual files or entire VMs in a few clicks. Scheduling a quarterly restore test (even just to a throwaway VM) turns “I think the backups are working” into “I know the backups are working.”

Who should bother with PBS

You should run PBS if:

• You’re running more than a handful of Proxmox VMs and storage efficiency matters to you.
• You want a proper retention and pruning story without scripting it yourself.
• You care about verifiable backups (chunk-level HMAC signatures mean corruption is detected, not just hoped away).
• You want an offsite copy without gluing together a custom rsync job.
• You’ve had a backup job silently fail before and want alerting built in, not bolted on.

You might not need PBS if:

• You’re running one or two VMs and the built-in Proxmox backup to a local directory is meeting your needs.
• You need to back up non-Proxmox systems — PBS won’t help there; reach for restic, Bacula/Bareos, or Veeam CE depending on your environment.
• You want something that “just works” with zero ops — PBS is low-maintenance, but it’s still a service you own and operate.

A note on the VM-running-your-backup-server question: It’s reasonable to wonder whether trusting a VM on the same cluster to be your backup system is circular. The answer is nuanced. If the entire host fails simultaneously and takes PBS with it, restoring requires rebuilding PBS from scratch before you can restore anything else. The mitigations are: keep your PBS installation minimal (it’s fast to rebuild from the documentation), make sure your datastores survive independently of the PBS VM (NFS-backed, or separate physical storage), and always have an offsite copy that doesn’t depend on the on-site PBS instance. Done right, the VM-on-cluster approach is practical and has real operational benefits. Done carelessly, it’s a single point of failure. The difference is mostly in the storage design.

The bottom line

Proxmox Backup Server is one of those infrastructure pieces that, once you have it running, fades into the background. The UI tells you every morning whether last night’s backups completed, how much storage they consumed, and whether deduplication is doing its job. Restores take minutes and happen inside the same interface you already know.

It’s free, actively maintained, and built for exactly the environment most homelab operators are running. If you’re on Proxmox and not using PBS, the main thing you’re missing is confidence — and that’s the whole point of backups in the first place.

Want to go deeper? The official Proxmox Backup Server documentation is thorough and well-organized. The PBS documentation covers chunk stores, sync jobs, retention policies, and tape support if you want the full picture.

← all posts