Proxmox Backup Server Setup for Homelabs: The Workflow I Actually Trust

Transparency note: This guide contains no affiliate links. If we ever add affiliate recommendations to this page later, we will disclose that clearly.

After cleaning up too many fake backup setups in Proxmox labs, I have one strong opinion: if you are still dumping vzdump files onto an NFS share and calling it done, you do not have a backup strategy. You have a pile of files and a lot of optimism.

Proxmox Backup Server fixes that.

It gives you incremental backups, deduplication, verification, retention controls, and tight Proxmox VE integration. More importantly, it pushes you toward the part people avoid - actually treating recovery as an operational workflow instead of a checkbox.

This guide is how I would set up PBS in a real homelab today. Not the fanciest possible build. Not the cheapest thing you can technically boot. The setup I actually trust if I want fast restores, sane retention, and an offsite path that still works when the main box has a bad day.

Key Takeaways

• If you run Proxmox seriously, PBS is the first backup tool I would reach for before generic file-copy workflows.
• I recommend a separate PBS box if you can afford one. A VM can work, but same-node backups are not real disaster isolation.
• The Proxmox docs list 2+ CPU cores and 2 GB RAM as evaluation minimums, but recommend at least 4 cores, 4 GiB plus roughly 1 GiB per TiB of backup storage, 32 GiB or more for OS storage, and redundant multi-gig NICs for real deployments.
• Prune and garbage collection are not the same thing. Prune removes old snapshot references. Garbage collection reclaims the unreferenced chunks later.
• Verify jobs and restore drills matter as much as backup jobs. A backup you never restore is just a theory.
• Offsite sync is what turns PBS from convenient into resilient.

Why PBS is worth the trouble

PBS exists for the moment when your restore expectations get higher than your tolerance for hand-wavy backups.

A plain vzdump workflow to NFS can still be useful. I am not pretending it is worthless. But it gets ugly fast once you keep multiple restore points, run a few similar VMs, or start backing up across several nodes.

What PBS does better:

• incremental transfers after the first backup
• deduplicated storage on the server side
• native Proxmox VE integration
• verification workflows
• retention policies that are easier to manage cleanly
• remote sync for offsite copies
• client-side encryption support for less-trusted remote targets

The official PBS FAQ is also clear about the model: backups are sent incrementally, deduplicated on the server, and each backup still behaves like a full restore point from the operator side. That is the right tradeoff for a homelab. Less wasted storage, less network churn, fewer excuses not to keep useful history.

If you want the broader backup strategy context first, read Proxmox Backup Strategies: How to Never Lose a VM Again and Homelab Storage Design: How I Split Boot, App, Media, and Backup Tiers Without Making a Mess. This guide assumes you already know backups matter and want the Proxmox-native version done properly.

When I would use PBS - and when I would not

I would use PBS if:

• you run more than a couple of important VMs or LXCs
• you want several restore points without wasting storage
• you want faster, more repeatable restores
• you want an offsite sync story that is cleaner than random shell scripts
• you care about verification and retention instead of just "copy the file somewhere"

I would not force PBS if:

• you have one throwaway test node and no important workloads
• you are still proving whether you even like Proxmox
• you cannot spare separate storage yet and are better served by a simple short-term vzdump job while you sort out hardware

PBS is not mandatory on day one. But once your homelab starts carrying DNS, media metadata, automation, family backups, or anything else annoying to rebuild, the argument gets very short.

My deployment recommendation: bare metal first, VM second, LXC only if you know why

This is the part where a lot of guides get overly diplomatic. I will not.

For a real homelab, I prefer a separate PBS machine. A low-power mini PC, small tower, or recycled business desktop is enough for a lot of labs. If the production node dies, your backup server should ideally still be standing.

If you cannot do that yet, a VM is the next-best compromise for learning and short-term operations. I would still keep its backup datastore separate from the main production pool if possible.

An LXC install is possible, but I do not think it is the right default for most readers. It is the kind of optimization people reach for before they have even tested restores.

Deployment option	When I would use it	Why it works	What I dislike
Separate bare-metal PBS box	Best default for serious homelabs	Clear failure-domain separation, easier maintenance, no hypervisor dependency	Needs another box and another disk plan
PBS in a VM	Acceptable if hardware is tight	Easy snapshots, portable, simple to learn with	Same-node deployments create false confidence
PBS in an LXC	Only if you already understand the tradeoffs	Lower overhead	More edge cases, less beginner-friendly, easier to overcomplicate

The mistake I made: I once treated same-chassis backups as if they were true disaster recovery. They were not. They were convenient local recovery. Useful, yes. Sufficient, no.

Hardware and sizing: keep it boring

The official installation docs say the evaluation minimum is 2+ CPU cores, 2 GB RAM, and more than 8 GB of disk space, but those numbers are for evaluation only. For a real deployment, Proxmox recommends at least 4 CPU cores, 4 GiB minimum for the OS, filesystem cache, and PBS daemons, plus another GiB per TiB of backup storage, 32 GiB or more for OS storage, and ideally redundant multi-gig networking.

That lines up with real-world experience. PBS is not hard to run, but a backup box gets miserable fast if you starve RAM and then ask it to manage a growing datastore on slow disks.

My practical homelab sizing rule looks like this:

Lab size	Suggested PBS box	Backup storage idea	Notes
Small lab - 3 to 8 VMs/LXCs	4 cores, 8 GB RAM	mirrored HDDs or a modest ZFS pool	Good default starting point
Growing lab - 8 to 20 workloads	4 to 8 cores, 16 GB RAM	larger mirrored disks or RAIDZ / mirrored datasets	Better headroom for verify jobs and sync
Busy lab with long retention	8+ cores, 16 to 32 GB RAM	separate OS disk plus dedicated backup pool	Plan restore speed, not just capacity

I also strongly prefer separating:

• OS disk
• backup datastore disks
• offsite destination

That layout complements Proxmox Storage Architecture: The Layout I Actually Recommend and Proxmox ZFS Setup Guide: The Storage Layout I Recommend Before You Regret Your Pool Design.

Step 1: Install PBS the simple way

For most homelabbers, I recommend the official ISO installer. It is cleaner than trying to get clever on day one.

• Download the current ISO from the official Proxmox download page.
• Install it on a dedicated OS disk.
• Give the box a static IP.
• Sign in to the web UI at https://:8007.

If you specifically need a Debian-based install because you standardize on Debian, the docs support that too. But if your goal is "get a trustworthy backup server online without drama," the ISO is still the shortest path.

Step 2: Create a datastore you will not regret later

A PBS datastore is where the backups actually live. Treat it like a real storage design choice, not an afterthought.

A simple CLI example looks like this:

mkdir -p /mnt/datastore/pbs-main\nproxmox-backup-manager datastore create pbs-main /mnt/datastore/pbs-main

My advice:

• put the datastore on storage that is not also your production VM disk pool
• use redundancy if the data matters
• do not burn your nicest SSDs on a backup target unless restore speed is the actual bottleneck
• if you use large HDDs, be honest about verify and garbage-collection windows

The official docs also note that if you use HDDs, a metadata cache or better random I/O characteristics help a lot. That matters more as your datastore grows.

Step 3: Add PBS to Proxmox VE properly

This is where the integration starts paying off.

From the PBS side, get the certificate fingerprint:

proxmox-backup-manager cert info | grep Fingerprint

Then add PBS to Proxmox VE. The official documentation shows the basic shape with pvesm add pbs and then pvesm set for credentials. In practice, I think in one block:

pvesm add pbs pbs-main \\n  --server 10.10.10.25 \\n  --datastore pbs-main\n\npvesm set pbs-main \\n  --username pve-backup@pbs \\n  --password

Then add the fingerprint:

pvesm set pbs-main \\n  --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:aa:bb:cc:dd:ee:ff:11:22:33

If you prefer the web UI, use Datacenter -> Storage -> Add -> Proxmox Backup Server.

What I recommend operationally:

• use a dedicated backup user or token, not your daily admin habit account
• keep permissions narrow
• do not hand clients delete powers they do not need

The PBS storage docs are very explicit here: least-privilege backup access is part of the ransomware story. Let clients write backups. Let the server own pruning and retention.

Step 4: Build backup jobs around recovery, not calendar aesthetics

A nice schedule on a whiteboard means nothing if the jobs collide, saturate storage, or produce restore points nobody can reason about.

A sane starting point for a small homelab is:

• daily snapshot backups for important VMs
• daily or alternate-day backups for lower-value guests
• longer retention for identity, DNS, router-controller, automation, and storage-controller workloads
• shorter retention for throwaway test boxes

A practical Proxmox VE example:

pvesh create /cluster/backup \\n  --storage pbs-main \\n  --schedule "0 2 * * *" \\n  --all 1 \\n  --mode snapshot \\n  --compress zstd \\n  --prune-backups keep-daily=7,keep-weekly=4,keep-monthly=3

I like separate thinking for three classes of workloads:

Workload type	Suggested retention starting point	Why
Core infrastructure - DNS, auth, storage, controllers	14 daily, 8 weekly, 6 monthly	These are painful to rebuild under stress
Normal application VMs	7 daily, 4 weekly, 3 monthly	Good balance for most homelabs
Test or disposable workloads	3 daily, 2 weekly	Do not waste prime backup space on experiments

Step 5: Understand prune vs garbage collection before it bites you

This confusion causes a lot of bad assumptions.

Prune decides which snapshots should still exist.

Garbage collection reclaims the unreferenced chunks later.

Those are not interchangeable.

The official maintenance docs spell it out clearly: pruning removes snapshot metadata and references, but the underlying chunks stay around until garbage collection runs. That is why your storage graph does not instantly shrink the moment a prune policy removes old snapshots.

If you remember one thing from this section, remember this:

• prune shapes retention
• garbage collection reclaims space

That is also why I schedule them deliberately instead of assuming "PBS will sort it out somehow."

Step 6: Verify jobs are not optional

This is where most backup guides get too casual.

Proxmox recommends regular reverification, and the maintenance docs explicitly say you should reverify all backups at least monthly because physical media degrades over time. The storage docs also tie verification directly to ransomware detection and restore confidence.

Run a verify job. Then keep running it.

The docs show a manual verification pattern like this:

proxmox-backup-manager verify pbs-main \\n  --read-threads 1 \\n  --verify-threads 4 \\n  --ignore-verified false

My practical rule:

• verify new backups frequently
• reverify everything on a slower monthly cadence
• do not schedule heavy verification on top of your busiest backup window

If your lab has enough churn that verify jobs hurt, that is not a reason to skip them. It is a reason to tune schedule, storage, or hardware.

Step 7: Restore-test like a skeptic

A verify job tells you that chunks and metadata still match. That is good. It does not replace an actual restore drill.

The official docs recommend restoring to a new guest instead of overwriting the current one, and I agree completely. That is the safest way to prove the workflow end to end.

My quarterly restore drill looks like this:

1. Pick one critical VM and one ordinary VM.

2. Restore each to a new VMID.

3. Boot them on an isolated network if needed.

4. Confirm services start, IP configuration looks sane, and core apps are actually usable.

5. Delete the test restore only after documenting the result.

This is also a good companion discipline to Homelab Maintenance Checklist: The Weekly, Monthly, and Quarterly Tasks That Keep My Stack Boring.

Step 8: Add offsite sync before you congratulate yourself

Local PBS is already better than raw backup dumps. It is still not the full story.

The PBS storage docs lean into the 3-2-1 model for a reason: three copies, two storage media, one offsite. PBS gives you remote sync jobs for exactly that problem.

Why I like the model:

• local restores stay fast
• offsite copies protect you from fire, theft, and some ransomware blast-radius problems
• you can keep deletion rights away from the client side and let the backup servers handle lifecycle properly

If you already use Restic Backup for Homelabs: The Setup I Use for Linux Servers, Docker Volumes, and Offsite Copies, think of PBS remote sync as the Proxmox-native version of that mindset.

My preferred order is:

1. get local PBS stable

2. verify restores locally

3. add a remote PBS target or other offsite design

4. test the offsite recovery path before calling the project finished

The mistake I made: trusting backup success logs too much

I used to look at green backup jobs and feel smart.

Then I started checking what those jobs actually meant operationally.

• Did the restore boot?
• Was the retention policy still sane after six weeks?
• Did the datastore have enough headroom after prune plus garbage collection?
• Would the backup box still exist if the main node died?
• Did the offsite copy lag silently for days?

That is when you stop treating PBS as software and start treating it like infrastructure.

My recommended homelab PBS workflow

If you want the short version, this is the workflow I would build today:

1. Install PBS on a separate box if possible.

2. Use dedicated backup storage, not the same production pool.

3. Add the PBS datastore to Proxmox VE with a narrow-permission user or token.

4. Run daily snapshot jobs with retention that matches workload importance.

5. Schedule prune and garbage collection intentionally.

6. Run verify jobs on a recurring schedule.

7. Restore-test into new guests regularly.

8. Add offsite sync.

9. Monitor free space and failed jobs like they matter - because they do.

If your homelab also depends on clean shutdown behavior, pair this design with Proxmox UPS Shutdown with NUT: The Safe Power-Failure Setup I Actually Trust. Backup corruption and ugly power loss make a miserable combination.

Who should skip this article and just use something simpler?

If you have one tiny node, one disposable VM, and no real data, a temporary vzdump schedule to basic storage may be enough while you learn the platform.

But once the lab has family services, infrastructure dependencies, or anything you would hate to rebuild on a Sunday night, PBS stops being overkill. It becomes the boring answer. And boring is exactly what you want from backups.

Frequently Asked Questions

Is Proxmox Backup Server better than vzdump to NFS?

For most real homelabs, yes. PBS gives you incremental transfers, deduplication, verification, retention controls, and cleaner Proxmox VE integration. A plain vzdump target can still work for a tiny lab, but it gets clumsy once you want multiple restore points and predictable storage use.

Can I run Proxmox Backup Server in a VM?

Yes. It is a valid learning and short-term deployment option. I still prefer a separate machine because same-node backups help with convenience and local recovery, but they do not buy you much if the host, chassis, or primary storage stack fails together.

What is the difference between pruning and garbage collection in PBS?

Pruning decides which snapshots stay in retention. Garbage collection reclaims the underlying chunks once nothing references them anymore. That is why space is not always returned immediately after a prune policy removes old restore points.

Do I still need restore tests if verify jobs pass?

Absolutely. Verify jobs confirm backup integrity. Restore tests confirm recovery reality. Both matter. I recommend restoring into a new VMID on a recurring schedule so you can prove the process without risking the production guest.

Final verdict

If you run Proxmox often enough to care about recovery time, retention, and offsite copies, PBS is not the fancy option. It is the sensible option.

Set it up once. Scope permissions tightly. Verify aggressively. Test restores like you expect hardware to betray you eventually.

Because it will.

And when it does, the boring backup system wins.

Sources

• Proxmox Backup installation guide
• Proxmox Backup Proxmox VE integration guide
• Proxmox Backup storage and ransomware guidance
• Proxmox Backup maintenance and verification docs
• Proxmox Backup remotes and sync docs
• Proxmox Backup FAQ
• Proxmox Backup Server downloads