Proxmox Backup Server Setup: 5 Steps to Bulletproof Backups

I lost a VM to a bad ZFS pool once. Not a huge deal on its own — except my “backup strategy” at the time was a manual `vzdump` I ran whenever I remembered to, which turned out to be about six weeks before the drive died. That gap cost me six weeks of config changes I had to rebuild from memory.

A proper Proxmox Backup Server setup fixes exactly that problem: scheduled, deduplicated, verified backups that run whether you remember to or not. If you’re running Proxmox VE already, adding PBS is the single highest-value thing you can do to your homelab this weekend.

What Proxmox Backup Server Actually Does

Proxmox Backup Server (PBS) is a dedicated, free backup solution built specifically for Proxmox VE. Unlike a simple file copy, it uses deduplicated, incremental backups — after the first full backup, subsequent runs only store the chunks that actually changed, which keeps storage use and backup time far lower than repeated full backups would.

It runs as its own minimal Debian-based OS with built-in ZFS support, installed separately from your Proxmox VE hypervisor — ideally on different hardware entirely, since a backup server sharing a disk with the thing it’s backing up defeats half the point.

1. Install Proxmox Backup Server

Download the official ISO from proxmox.com and install it on a separate physical machine, a spare mini PC, or a dedicated VM on different hardware than your main Proxmox VE host. It’s a bare-metal installer — existing data on the selected disk gets wiped, so point it at a clean drive.

Once installed, the web interface is reachable at https://YOUR_PBS_IP:8007. Log in with the root credentials you set during install.

2. Create a Datastore

A datastore is where PBS actually stores your backup chunks. In the web UI, go to Datastore → Add Datastore, point it at a mounted disk or ZFS pool, and give it a name. This is the step where drive choice matters most — a datastore living on the same drive as your VMs isn’t a real backup, it’s a false sense of security.

Dedicated NAS-rated drives are worth the extra cost here. A Seagate IronWolf 4TB is rated for 24/7 operation and RAID workloads, which matters for a drive that’s going to be written to on every scheduled backup for years.

If your VM count or retention window is larger, the WD Red Plus 8TB gives more headroom without a huge cost jump over the 4TB tier, and it carries the same NAS-grade reliability rating.

3. Connect PBS to Proxmox VE

Back in your Proxmox VE web UI, go to Datacenter → Storage → Add → Proxmox Backup Server. You’ll need an API token from PBS rather than the root password — generate one under Configuration → Access Control → API Token in the PBS interface, scoped to just what it needs for backups.

Enter the PBS server address, the datastore name from step 2, and the API token. Once saved, PBS shows up as a storage target any VM or container on that Proxmox VE node can back up to.

4. Schedule Backup Jobs with Real Retention

In Proxmox VE, go to Datacenter → Backup → Add and pick your PBS storage as the target. Set a schedule — nightly is a common baseline — and select which VMs or containers to include.

Retention is configured on the PBS side and matters more than people expect. A reasonable starting policy looks like this:

keep-last: 3
keep-daily: 13
keep-weekly: 8
keep-monthly: 11
keep-yearly: 3

That’s roughly two weeks of daily snapshots, two months of weekly ones, a year of monthly ones, and a few years of yearly checkpoints — enough depth to recover from both “I broke something an hour ago” and “I need a config from eight months back.”

5. Set Up Garbage Collection and Verification

Pruning only removes backup metadata, not the actual data chunks — those get cleaned up separately by a garbage collection (GC) job. Schedule GC weekly under your datastore’s maintenance settings; it scans for chunks no longer referenced by any kept backup and frees that space.

Verification jobs are the step people skip and regret. Hard drives degrade silently over years — bit rot is real, and a backup that looks present in the UI but fails to restore is worse than no backup at all, since it gives false confidence. Schedule a monthly verify job under Datastore → Verify so PBS actively checks that stored backups are still restorable, not just present.

FAQ: Proxmox Backup Server Setup

Can I run Proxmox Backup Server on the same host as Proxmox VE?
Technically yes, either as a separate VM or installed directly, but it defeats a lot of the safety purpose. If the physical hardware fails, both your VMs and your backups of them are gone together. A separate machine, even a cheap mini PC, is worth the investment.

How much storage do I actually need for a datastore?
It depends on VM count, disk sizes, and retention depth, but deduplication keeps it far lower than “total VM disk size times number of backups.” Start with roughly 2-3x your combined VM disk usage and monitor actual growth over the first month before deciding whether to expand.

Is Proxmox Backup Server really free, or is there a paid tier?
The software itself is free and open-source. Proxmox sells optional commercial support subscriptions, similar to Proxmox VE, but they’re not required for full functionality in a homelab context.

Should I back up containers (LXC) the same way as VMs?
Yes, PBS handles both through the same backup job workflow in Proxmox VE. Containers typically produce smaller backup chunks than full VMs, so they add relatively little to your total storage footprint even with the same retention policy applied.

What happens if my PBS datastore itself fails?
You lose your backup history, which is why a backup server isn’t a substitute for the 3-2-1 rule — three copies of your data, on two different media types, with one copy offsite. PBS covers the “regular, automated local copy” piece well, but pair it with an occasional offsite sync of critical backups for real disaster protection.

The Takeaway

A Proxmox Backup Server setup takes an afternoon and turns “I hope my last manual backup still works” into an actual, verified recovery plan. Install it on separate hardware, set real retention instead of defaults, and don’t skip the verification job — that’s the step that catches silent drive failure before it becomes a real problem.

Test a restore before you need one for real. A backup you’ve never restored from is still a theory, not a plan.

What’s your current retention policy look like? Drop it in the comments — I’m always tweaking mine after finding a gap I didn’t know existed.