Do I need Proxmox Backup Server if I already use vzdump?

Not strictly, but the space and time difference is large. vzdump writes a full compressed copy of each guest on every run, so ten dailies of a 200GB VM cost roughly ten times 200GB compressed. PBS stores deduplicated chunks, so the second and subsequent backups only add what changed. On a homelab with a handful of guests that usually turns weeks of retention into the space one or two vzdump runs used to take.

Can I run PBS as a VM on the same Proxmox host it backs up?

It will work and a lot of people do it, but understand what it costs you. If the datastore lives on the same disk or pool as the guests, a disk failure takes the backups with the originals and you have paid for backup software without buying protection. If the host dies you also lose the backup server needed to restore. Running it that way is only defensible when the datastore is on genuinely separate storage and a sync job copies snapshots off the machine.

Why did pruning not free any disk space?

Prune and garbage collection are two different operations. Prune removes snapshot references according to your retention rules. The underlying chunks stay on disk until garbage collection runs, marks unreferenced chunks, and deletes them after a grace period. If space never comes back, garbage collection is not scheduled.

What happens if I lose the client-side encryption key?

The backups are unrecoverable. There is no recovery path, no vendor reset, and no support escalation. If you enable encryption, export the key with proxmox-backup-client key paper-key and store the copy somewhere entirely outside the homelab, because the obvious place to keep it is in a password manager that is itself one of the things you are backing up.

Can PBS back up machines that are not Proxmox VE guests?

Yes. The proxmox-backup-client package runs on any Debian or Ubuntu host and backs up filesystem paths as pxar archives into the same datastore. It is a reasonable way to cover a bare-metal NAS or a laptop, though it is a file-level tool and not a bare-metal image.

How much disk space should the datastore have?

Start at roughly three times the total size of the data you are protecting and watch the actual deduplication ratio for a month. Guests built from the same OS template deduplicate heavily, so the real number is often lower. What breaks the estimate is long retention on databases and media libraries, where a large fraction of the data changes between runs.

Proxmox Backup Server: Setup and Restore

Proxmox’s built-in vzdump backups work. That is worth saying up front, because this guide is not about replacing something broken. If you have already set up scheduled backups following the Proxmox snapshots and backups guide, you have real protection and you should keep it running until the replacement is proven.

What vzdump does not do is scale. Every run writes a full compressed copy of every guest, so retention is bought in whole multiples of your data. Proxmox Backup Server changes the economics: it stores deduplicated, incremental chunks, verifies them on a schedule, and can restore a single file out of a VM image without unpacking the whole thing. This guide covers the install, the wiring into Proxmox VE, and the half that most coverage skips, which is proving a restore. It assumes you already have a working hypervisor, per the Proxmox beginner guide and the post-install checklist, and it sits inside the wider plan laid out in homelab backup strategy. Everything running here is on the stack page.

Quick Answer: Setting Up Proxmox Backup Server

Install PBS on separate hardware from the host it protects
Create a datastore with proxmox-backup-manager datastore create
Create a user and API token, grant it DatastoreBackup
Copy the fingerprint from proxmox-backup-manager cert info
Add PBS as storage in Proxmox VE with pvesm add pbs
Schedule a backup job in Datacenter > Backup
Schedule prune and garbage collection separately
Schedule a verify job
Restore a guest and boot it before you trust any of it

What PBS Actually Buys You Over vzdump

	vzdump	Proxmox Backup Server
Storage model	Full compressed archive per run	Deduplicated chunks, incremental after the first
Cost of 30 dailies	~30x compressed guest size	Roughly one full plus 30 days of change
Backup window	Grows with guest size, every run	First run is long, subsequent runs are short
Integrity checking	None beyond the archive completing	Scheduled verify jobs re-read and checksum chunks
Single-file restore	Unpack the whole archive	File-level browse straight out of the snapshot
Live restore	No	Yes, VM boots while data streams in
Off-site copies	Copy files yourself	Native pull-based sync jobs between servers
Setup effort	Already installed	A separate machine and about an hour

The deduplication line is the one that changes behaviour. Under vzdump, retention is a budget decision, and most homelabs settle at seven daily copies because that is what fits. Under PBS the marginal cost of another daily snapshot is the delta, so keeping a couple of months becomes reasonable on the same disk. That matters more than it sounds: the failures that actually hurt are the quiet ones, a database that corrupted three weeks ago or a config change nobody noticed, and seven days of retention does not reach them.

The verify jobs matter for a less obvious reason. A backup archive that silently rotted on disk looks exactly like a good one until the day you need it. Scheduled verification is the difference between finding out on a Tuesday afternoon and finding out during an outage.

Where to Run It

This is the decision that determines whether any of the rest is worth doing.

PBS needs to survive the failure it is protecting you from. A PBS VM running on the same Proxmox host, writing its datastore to the same pool as the guests it backs up, protects you against exactly one thing: deleting a file inside a VM. Disk failure, pool corruption, or the host dying takes the originals and the backups in one move, and it also takes the backup server you would need to run the restore.

Reasonable options, roughly in order of how well they hold up:

A separate physical machine. A retired mini PC or a low-power N-series box with a large disk attached. This is the standard homelab answer and it is the one that behaves correctly in every failure mode.
A VM or LXC on a different Proxmox node. Fine if you have more than one host. The datastore must be on that node’s storage, not on shared storage that the protected node also writes to.
A VM on the same host, datastore on a genuinely separate physical disk, plus a sync job pushing snapshots off the box. Defensible, and better than nothing, but the host is still a single point of failure for the restore path.
A VM on the same host, datastore on the same pool. Not a backup. Do not confuse this with having one.

Hardware requirements are modest. PBS is not CPU-hungry, but it likes RAM for its chunk index and it strongly prefers the datastore on something other than a USB drive. 4GB of RAM and any SATA SSD or spinning disk with room to grow will run a homelab-sized datastore comfortably. If you are choosing disks, homelab storage options covers the trade-offs.

Step 1: Install Proxmox Backup Server

Two paths. The ISO is the clean one for dedicated hardware:

Download the PBS ISO from the Proxmox site, write it to a USB stick, and install it the same way you would install Proxmox VE. It is a Debian-based installer with the same disk and network prompts.

If you already have a Debian machine you would rather use, add the repository instead:

# Add the Proxmox release key
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
  -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

# Add the no-subscription repository
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs-install-repo.list

apt update && apt install proxmox-backup-server

The pbs-no-subscription repository is the free one. It is the same software as the enterprise repository with a slightly less conservative release cadence, and it is what the vast majority of homelabs run.

Once installed, the web interface is on port 8007 over HTTPS:

https://192.168.1.50:8007

Log in as root@pam with the system root password. The certificate is self-signed, so your browser will complain. That is expected and the fingerprint step below is how Proxmox VE deals with it properly.

Step 2: Create a Datastore

A datastore is a directory where PBS writes chunks. Mount your backup disk first, then:

proxmox-backup-manager datastore create backups /mnt/backup-disk

Where backups is the datastore name and /mnt/backup-disk is a mounted filesystem with real capacity. Confirm it registered:

proxmox-backup-manager datastore list

Two things to get right here:

Put the datastore on its own mount, not on the root filesystem. A datastore that fills the root partition takes the backup server down with it, and a full backup server fails silently in the direction you least want.

Make sure the mount happens at boot. If the disk is mounted by hand and the machine reboots, PBS will happily recreate the datastore directory on the root filesystem and start writing there. Put it in /etc/fstab with the UUID, and check it survives a reboot before you trust the schedule.

Step 3: Create a User and API Token

Do not point Proxmox VE at PBS using the root account. Create a dedicated user, generate a token for it, and grant that token only what it needs:

# Create the user
proxmox-backup-manager user create backup@pbs --password 'choose-something-long'

# Generate an API token for that user
proxmox-backup-manager user generate-token backup@pbs pve

The token generation command prints a token ID and a secret once. Copy the secret now. There is no way to display it again and the only remedy is to delete the token and generate a new one.

Grant the token permission on the datastore:

proxmox-backup-manager acl update /datastore/backups DatastoreBackup \
  --auth-id 'backup@pbs!pve'

DatastoreBackup lets the token create and read its own backups. It deliberately does not include DatastoreAdmin, so a compromised hypervisor cannot use this token to delete your backup history. That distinction is the entire reason for using a token instead of root, and it is the same reasoning as the least-privilege approach in the homelab security guide.

Step 4: Record the Fingerprint

Proxmox VE needs to trust the PBS certificate. On the PBS machine:

proxmox-backup-manager cert info | grep -i fingerprint

Copy the whole colon-separated hex string. You will paste it into Proxmox VE in the next step.

Step 5: Add PBS as Storage in Proxmox VE

On the Proxmox VE host, either use the UI at Datacenter > Storage > Add > Proxmox Backup Server, or the command line:

pvesm add pbs pbs-backups \
  --server 192.168.1.50 \
  --datastore backups \
  --username 'backup@pbs!pve' \
  --password 'the-token-secret-from-step-3' \
  --fingerprint 'AA:BB:CC:...' \
  --content backup

Here pbs-backups is the storage ID as it will appear in Proxmox VE, and 192.168.1.50 is the PBS address on your network. Note the username format: it is the auth ID, user and token name joined with !, not just the username.

Verify the connection:

pvesm status

The new storage should appear as active. If it does not, the fingerprint or the token secret is wrong, and the PVE task log will say which.

Optional: client-side encryption

If the datastore lives anywhere you do not fully control, or you plan to sync it off-site, enable encryption when you add the storage. Proxmox VE encrypts chunks before they leave the hypervisor, so PBS stores data it cannot read.

The warning is not boilerplate. If you lose the encryption key, the backups are gone. There is no recovery mechanism. Export a copy the moment you create it:

proxmox-backup-client key paper-key --output-format text

Then store that copy somewhere that is not the homelab. The natural instinct is to put it in your self-hosted password manager, which is also one of the things you are backing up, and that circular dependency is exactly how people discover they cannot restore.

Step 6: Schedule the Backup Job

In the Proxmox VE UI, Datacenter > Backup > Add:

Storage: pbs-backups
Schedule: something outside your usage window, 02:30 is a reasonable default
Selection mode: All if you want everything, or pick guests individually
Mode: Snapshot
Notification: send on failure only, unless you enjoy daily success email

Snapshot mode backs up a running guest without stopping it. For databases, that means the backup captures the on-disk state at that instant, which most modern databases recover from cleanly on next start, but a proper dump alongside the image is still the safer answer for anything you actually care about.

Run it once by hand with Run now and watch the task log. The first run is a full transfer and will take a while. Subsequent runs are incremental and typically finish in a small fraction of the time.

To get failures in front of you rather than buried in a task log, wire the notification target up properly, covered in homelab email notifications.

Step 7: Prune and Garbage Collection

This is the step people configure halfway and then wonder why the disk keeps filling.

Prune decides which snapshots to keep. Garbage collection reclaims the disk space. They are separate jobs on separate schedules and configuring only the first accomplishes nothing on disk.

Set retention on the datastore:

proxmox-backup-manager prune-job create prune-backups \
  --store backups \
  --schedule 'daily' \
  --keep-daily 14 \
  --keep-weekly 6 \
  --keep-monthly 6

That keeps two weeks of dailies, six weeks of weeklies, and six months of monthlies. Because of deduplication this costs far less than the equivalent under vzdump.

Then schedule garbage collection, which walks the chunk store, marks anything no longer referenced by a surviving snapshot, and deletes it after a 24-hour grace period:

proxmox-backup-manager garbage-collection start backups

For the recurring schedule, set it in the UI under Datastore > backups > Prune & GC, or in /etc/proxmox-backup/datastore.cfg. Weekly is fine for most homelabs. It is I/O heavy, so put it somewhere it will not collide with the backup window.

The 24-hour grace period is deliberate: it prevents GC from deleting a chunk that a backup job running right now is about to reference. Do not try to work around it.

Step 8: Verification

A verify job re-reads chunks and checks them against their stored checksums. Without one, the first full read of your backup data happens during a restore, which is the worst possible time to discover bit rot.

Create one in the UI under Datastore > backups > Verify Jobs, or:

proxmox-backup-manager verify-job create verify-backups \
  --store backups \
  --schedule 'sat 03:00' \
  --ignore-verified true \
  --outdated-after 30

--ignore-verified skips snapshots already verified, and --outdated-after 30 re-verifies them anyway once the previous check is 30 days old. That combination keeps the job from re-reading the entire datastore every week while still ensuring nothing goes unchecked indefinitely.

Restoring: The Half That Matters

Four restore paths, in ascending order of how much has gone wrong.

Single file out of a guest

Someone deleted a config file. You do not need the whole VM.

In Proxmox VE, go to the PBS storage, open the Backups list, select a snapshot, and click File Restore. PBS mounts the image and gives you a browsable tree; download the file you need and close it. For LXC containers this works directly. For VMs, PBS spins up a small temporary helper VM to read the filesystem, which takes a few extra seconds and is otherwise invisible.

This capability alone justifies the setup for most people. Under vzdump the same request means unpacking a 200GB archive to retrieve 4KB.

Full guest restore

Select the snapshot, click Restore, and choose a target VM ID and storage.

Restore to a new VM ID rather than overwriting the broken original. Restoring over the top destroys the evidence of what went wrong, and if the backup turns out to be older than you thought, you have now lost both copies. Restore alongside, confirm it boots, then delete the broken one.

From the command line:

qmrestore pbs-backups:backup/vm/101/2026-09-15T02:30:00Z 999

For containers, pct restore takes the same shape.

Live restore

VM restores in PBS offer a Live restore checkbox. The VM boots almost immediately and data streams in from the backup in the background, so a service comes back in seconds instead of after a multi-hundred-gigabyte copy.

Performance is degraded until the transfer finishes and the restore must not be interrupted, so it is a tool for getting a service back now, not a replacement for a normal restore. It is VM-only; LXC containers do not support it.

The host itself is gone

This is where separate hardware pays for itself. Reinstall Proxmox VE, re-add the PBS storage with the same server address, datastore, token and fingerprint from Steps 3 to 5, and every snapshot is there to restore from.

Which means the credentials from Step 3 are part of your disaster recovery plan and need to live somewhere reachable when the homelab is down. The full drill, including the order to bring things back in, is in homelab disaster recovery.

Actually do this

Pick a real guest. Restore it to a spare VM ID. Boot it on an isolated bridge with no network access so it cannot fight with the original over an IP address, log in, and confirm the data is genuinely there and recent.

Until that happens you do not have backups, you have an assumption with a green checkmark next to it. Do it once now, and once more after any significant change to the storage layout.

Off-Site Copies

Backups on a second machine in the same house survive disk failure. They do not survive theft, fire, or flood, which is the “1” in 3-2-1.

PBS handles this natively with sync jobs, which are pull-based: the remote server reaches out and pulls snapshots from the source. That direction matters, because a compromised primary cannot reach out and delete the off-site copy.

Add the source under Configuration > Remotes on the destination PBS (address, auth ID, fingerprint), then create a sync job targeting a local datastore. If you already have a second PBS somewhere, this is the cleanest option available.

If a second PBS is not realistic, the alternative is to back up the datastore itself to object storage with a file-level tool. That works because PBS chunks are ordinary files, but the restore path is longer: you pull the datastore back down before you can restore anything out of it. If that is the route you take, the Duplicati setup guide covers one way to get files off-site, and the trade-offs between approaches are in homelab backup strategy.

Troubleshooting

Symptom	Likely cause	Fix
Storage shows inactive in `pvesm status`	Fingerprint mismatch or wrong token secret	Re-run `proxmox-backup-manager cert info`, regenerate the token if unsure
`permission denied` on backup	Token lacks `DatastoreBackup` on the datastore	Re-run the `acl update` from Step 3, check the `user!token` format
Datastore filling despite prune running	Garbage collection not scheduled	Schedule GC; prune alone never frees space
First backup extremely slow	Expected, it is a full transfer	Let it finish; check incremental runs before worrying
Datastore vanished after reboot	Backup disk not mounted at boot	Add the UUID to `/etc/fstab`, verify across a reboot
Verify job reporting failed chunks	Genuine corruption on the datastore disk	Check SMART, restore from the off-site copy, replace the disk
GC never reclaims recently pruned data	24-hour grace period has not elapsed	Wait and re-run; this is by design

What PBS Does Not Solve

Application-consistent database backups. A snapshot of a running database is crash-consistent, not clean. Take a real dump alongside it for anything whose loss would matter.
Configuration drift. PBS backs up guests. Your host config, firewall rules, and the network setup are not guests. /etc/pve is worth backing up separately.
A tested restore. Scheduling backups is not the same as knowing they restore, and no amount of green in the task log substitutes for having done it.
The single point of failure you built. If PBS is a VM on the host it protects, none of the above applies to the failure modes that actually take homelabs down.

The Budget Case

PBS is free, including the no-subscription repository and every feature described here. The only real cost is a machine to run it on and a disk to fill.

The honest comparison is against a paid cloud backup service. For the amount of data a typical homelab holds, cloud backup runs somewhere in the range of a few dollars a month indefinitely, and restores are bounded by your download speed. A second-hand mini PC and a large disk is a one-time cost, restores run at LAN speed, and the deduplication means retention stops being a budget line at all.

The version that actually holds up is both: PBS on separate local hardware for fast, deep-retention restores, plus one off-site copy for the failure that takes out the building. That is a working 3-2-1 for the cost of hardware you may already have sitting unused, which is the same argument this site makes about most of the stack. If PBS is your first serious backup target, the wider plan it fits into is in homelab backup strategy, and the guest-level basics it builds on are in Proxmox snapshots and backups.