What PBS actually is

Proxmox VE has backup built in already, through vzdump. It works, and if you’ve got a single node and modest storage it might be all you need. But vzdump backups are full copies by default (or full-plus-incremental with some tuning), stored as flat archive files. Every backup run costs you close to the full size of the VM or container again, and restoring means unpacking a whole archive.

Proxmox Backup Server is a separate product, built specifically to fix that. It runs as its own lightweight install, either on a dedicated machine, a VM, or (with some caveats) inside an LXC container on the same node it’s backing up. PBS backups are:

• Incremental at the block level. After the first full backup, every run after that only sends the changed blocks, not the whole disk again.
• Deduplicated. Identical blocks across backups, and even across different VMs and containers, get stored once. Ten LXCs all running the same base Debian image will not cost you ten times the storage for that shared base layer.
• Compressed using zstd, on top of the deduplication.
• Verified. PBS can run scheduled verification jobs that checksum stored chunks and flag corruption before you find out about it during a restore.

The practical result: your backup storage grows much slower than your VM/container footprint does, and your backup windows shrink from “however long it takes to copy everything” to “however long it takes to copy what changed today.”

Where to run it

You want PBS on separate storage from the VMs and containers it’s protecting, full stop. A backup that lives on the same disk as the thing it’s backing up isn’t a backup, it’s a second copy that dies at the same time as the first one. Three common patterns, roughly in order of how good the isolation is:

1. Dedicated hardware. A small separate box (even something like an old NUC or a cheap mini PC) running PBS bare-metal or as its own Proxmox VE host, with its own disks. Best isolation, most hardware to manage.
2. A VM on a different node. If you’re already running a cluster, put PBS on a node that doesn’t share physical disks with your primary workloads.
3. A VM on the same node, different disks. Acceptable if that’s genuinely all you’ve got, as long as the PBS datastore lives on a physically separate drive from your VM/container storage, not just a different partition on the same disk. This protects you from filesystem-level corruption and accidental deletion, though not from the whole box failing.

Whatever you pick, PBS wants its own storage pool, called a “datastore” in its terminology, formatted as a ZFS pool or plain directory on the disk you’re dedicating to it. Give it real headroom. As a starting point, plan for at least double your total protected VM/container disk usage before dedup kicks in and shrinks that footprint over time, more if you’re keeping longer retention windows.

Setup, at a high level

1. Install PBS. Grab the ISO from Proxmox’s site and install it like you would Proxmox VE itself, on whatever hardware or VM you’ve chosen. It gets its own web UI, separate from the Proxmox VE UI you’re used to, on port 8007.
2. Create a datastore. In the PBS web UI, point it at the disk or ZFS pool you’re dedicating to backups. This is where chunks get stored.
3. Add a PBS storage target in Proxmox VE. Back in your Proxmox VE web UI, go to Datacenter > Storage > Add > Proxmox Backup Server, and give it the PBS host’s address and an API token (create this in the PBS UI under Access Control, don’t reuse the root password here).
4. Create a backup job. Datacenter > Backup > Add. Pick which VMs/containers to include, which storage target (your new PBS datastore), a schedule, and a retention policy.

That last piece, retention, is where PBS earns its keep over vzdump’s simpler “keep N backups” model. PBS lets you set retention by time bucket: keep the last 7 daily backups, the last 4 weekly, the last 6 monthly, and so on, pruning everything else automatically. This gives you real point-in-time recovery options (last Tuesday, three weeks ago, two months ago) without manually managing a pile of full-size archive files.

A sane starting retention policy

There’s no universal right answer here, it depends on how often your data actually changes and how much storage you’re willing to dedicate. A reasonable default for a home setup:

• Keep last: 3-4 (recent daily backups, for “oops I broke a config an hour ago”)
• Keep daily: 7 (a week of daily granularity)
• Keep weekly: 4 (a month of weekly granularity)
• Keep monthly: 6 (half a year of monthly granularity)

Tune this against your actual datastore size once you’ve got a few weeks of real backups to look at. PBS’s UI shows you dedup and compression ratios per datastore, so you’re not guessing, you can watch actual growth and adjust retention before you run out of room.

Encryption, if you’re backing up off-site

If your PBS datastore, or a sync target for it, ever leaves your own network (cloud storage, a friend’s homelab, a colo box), turn on client-side encryption. PBS supports it natively, generating a key on the client side (your Proxmox VE host) before data ever leaves for the PBS server. This matters more than it sounds like it should: without it, whoever controls the storage your backups land on can read the contents of every VM and container you’ve backed up, including anything with credentials baked into disk images or config files. Keep the encryption key backed up somewhere separate from both the source data and the backup target. A lost key means every encrypted backup made with it is permanently unreadable, which is its own kind of data loss.

The step everyone skips: actually restore something

A backup you’ve never restored from is a theory, not a backup. This is the single most common gap in homelab backup setups, and it’s the one that turns “I had backups” into “I thought I had backups” at the worst possible moment.

Pick a low-stakes VM or container, ideally something you could afford to lose without real consequences, and actually run a full restore from PBS into a new VMID on your Proxmox VE host. Confirm it boots, confirm the data inside matches what you expect, and time how long the process takes so you have a real number for your recovery time expectations instead of a guess. Do this once when you first set PBS up, and again periodically, maybe quarterly, especially after any change to your storage layout or PBS version.

While you’re at it, test a single-file restore too, not just a full VM restore. PBS supports mounting a specific backup snapshot and pulling individual files back out, which is often what you actually need day to day (someone deleted a config file, not “the whole VM is gone”). This is faster to verify than a full VM restore and worth confirming works on its own.

Off-site copies, briefly

PBS supports sync jobs between datastores, which is how you get a second copy of your backups onto a different piece of hardware, a different location, or both, following the same 3-2-1 principle (three copies, two different media, one off-site) that applies to backups generally, not just Proxmox specifically. A single PBS datastore protects you from VM-level mistakes and disk failure on the primary storage. It does not protect you from the building it’s sitting in, whether that’s a fire, a flood, or a theft. If your data actually matters to you, budget for a second target eventually, even if it starts as an external drive you rotate off-site by hand rather than an automated sync.

Bottom line

If you’re running Proxmox and still relying on ad-hoc vzdump snapshots or, worse, nothing at all, Proxmox Backup Server is a free, genuinely well-built piece of software that closes that gap without much complexity. Dedicate separate storage to it, set a retention policy that matches how your data actually changes, encrypt anything that leaves your network, and then prove to yourself it works with a real restore before you need it for real. That last part is the whole point. A backup system nobody has tested is just a very elaborate way of hoping.