Proxmox VE already has vzdump for backups, so why add a second product? Because vzdump writes a full copy every run. Proxmox Backup Server (PBS) stores backups in a deduplicated datastore and, after the first run, only sends the blocks that changed. The result is faster backups, far less storage used, and the ability to verify that what you stored can actually be restored.
This guide connects a working PBS to an existing Proxmox VE host. You’ll create a datastore on PBS, add it to PVE as a storage target, run an incremental backup, restore a VM, then set up verification, pruning, and encryption so the system runs itself.
The steps target Proxmox Backup Server 3.x and Proxmox VE 8.x. The two are versioned separately but track each other closely, and the workflow below has been stable across the recent releases.
What Proxmox Backup Server actually is
PBS is a standalone Debian-based appliance, much like PVE, but its job is storing backups rather than running VMs. It has its own web interface (on port 8007, not 8006), its own installer ISO, and its own update repositories.
The core idea is the chunk store. Every backup is split into variable-sized chunks, each identified by a hash. PBS stores each unique chunk once. Two consequences fall out of that design:
- Deduplication — if twenty VMs run the same Ubuntu base, the shared blocks are stored a single time across all of them.
- Incremental forever — after the first full backup of a VM, later runs only upload chunks that aren’t already in the store. A daily backup of a quiet VM can be tiny even when the disk is large.
Step 1: Install Proxmox Backup Server
If you don’t have PBS yet, the install mirrors a bare-metal Proxmox VE install: download the PBS ISO from the Proxmox site, write it to a USB stick, boot it, set a static IP, and reboot. After it comes up, reach the web interface at:
https://your-pbs-ip:8007Log in as root with the password you set, and switch the repository to no-subscription the same way you would on PVE, so updates work without a key:
# disable the enterprise repo and add no-subscription (PBS is on Debian "bookworm")
sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pbs-enterprise.list
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" \
> /etc/apt/sources.list.d/pbs-no-subscription.list
apt update && apt full-upgrade -yStep 2: Create a datastore
A datastore is the directory tree where PBS keeps its chunk store and backup metadata. You need at least one before you can back anything up.
In the PBS web interface, go to Datastore → Add Datastore. Give it a name and a path on a disk with room to grow:
Datastore fields in PBS
| Name | A short identifier like main or backups. You'll reference this name from PVE. |
|---|---|
| Backing Path | An absolute path on the PBS host, for example /mnt/datastore/main. Point it at your large/redundant disk, not the OS disk. |
| GC Schedule | When garbage collection runs to reclaim space from unreferenced chunks. A daily off-hours run is sensible. |
| Prune Schedule | When old backups are removed according to retention rules (set these in Step 6). |
Put the datastore on dedicated storage. A ZFS pool or a mounted RAID volume is ideal; if you’re weighing the options, the LVM vs LVM-Thin vs ZFS comparison covers the trade-offs. Don’t carve the datastore out of the small OS disk and expect it to last.
Step 3: Add PBS as storage in Proxmox VE
Now tell PVE where to send backups. In the PVE web interface, go to Datacenter → Storage → Add → Proxmox Backup Server.
PBS storage fields in Proxmox VE
| ID | A name for this storage as it appears in PVE, such as pbs-main. |
|---|---|
| Server | The IP or hostname of your PBS box. |
| Username | Either root@pam or, better, the token user like backup@pbs!pve-token. |
| Password / API token | The token secret or the user's password. |
| Datastore | The datastore name you created in Step 2. |
| Fingerprint | The PBS server's TLS fingerprint, so PVE trusts the self-signed certificate. |
The fingerprint is the part people miss. PBS uses a self-signed certificate, and PVE refuses the connection unless you supply the expected fingerprint. Find it in the PBS interface on the Dashboard (Show Fingerprint), or from the PBS shell:
proxmox-backup-manager cert info | grep -i fingerprintPaste that value into the Fingerprint field. Once the storage is added, it shows up in the left tree on every node and is selectable as a backup target.
Step 4: Run your first backup
Backing up to PBS works exactly like any other backup target, because PBS now appears as storage. You can run it ad hoc or on a schedule.
For a one-off, select a VM or container, open Backup, click Backup now, choose your pbs-main storage and a mode, and start it. The three backup modes (snapshot, suspend, stop) behave the same as they do with vzdump — there’s a full rundown in back up and restore Proxmox VMs.
For a schedule, go to Datacenter → Backup → Add and point the job at the PBS storage with a cron-style time and the VMs to include.
The first backup of each VM transfers the whole disk, so it takes a while. Watch the difference on the second run:
INFO: first run — VM 101: 50.00 GiB read, 50.00 GiB uploaded
INFO: second run — VM 101: 50.00 GiB read, 0.42 GiB uploaded (dirty-bitmap)That second line is the payoff. PBS read the whole disk but only uploaded the changed chunks. With the QEMU guest agent and dirty-bitmap tracking, even the read can be skipped for unchanged regions while the VM stays online.
Step 5: Restore a VM
A backup you’ve never restored is a guess. Restoring from PBS is straightforward, and you can restore to a new VMID to test without touching the original.
In the PVE interface, click the pbs-main storage, open the Backups tab, and you’ll see every snapshot grouped by VM with timestamps. Select one and click Restore. Choose:
- Target VMID — use a fresh, unused ID to test the backup alongside the live VM.
- Target storage — where the restored disks land.
- Override options — optionally start the VM after restore or remap the network.
From the command line, restore a VM with qmrestore, pulling from the PBS storage:
# list available snapshots for the storage
pvesm list pbs-main
# restore VM 101 from a PBS snapshot into a new VMID 999
qmrestore pbs-main:backup/vm/101/2026-08-07T02:00:00Z 999 --storage local-lvmFor containers, the equivalent is pct restore with the same storage path. Restoring to a spare VMID is the safest habit you can build — you confirm the backup is good without risking the running machine.
Step 6: Verify and prune
Two background jobs keep a PBS datastore healthy: verification checks that stored data is still readable, and pruning removes old backups so the disk doesn’t fill.
Verification re-reads chunks and compares them to their recorded checksums, catching bit rot or a failing disk before a restore does. In PBS, go to your datastore’s Verify Jobs tab and add a job. A common pattern is to verify new backups after they land and re-verify everything weekly.
Pruning applies retention rules and marks old snapshots for removal. Set it under the datastore’s Prune & GC or per backup job. The keep-* options work the same as elsewhere in Proxmox:
Retention (prune) options
| keep-last | Keep the N most recent backups regardless of age. |
|---|---|
| keep-daily | Keep one backup per day for the last N days. |
| keep-weekly | Keep one per week for N weeks. |
| keep-monthly | Keep one per month for N months. |
There’s a catch worth understanding: pruning only removes the references to a backup. The disk space isn’t reclaimed until garbage collection runs and deletes chunks no longer referenced by any backup. That’s why the datastore has a separate GC schedule — pruning marks, GC sweeps.
# run garbage collection manually on a datastore
proxmox-backup-manager garbage-collection start mainStep 7: Turn on encryption
PBS encrypts on the client, meaning the data is encrypted on the PVE host before it’s sent. PBS only ever stores ciphertext, so even someone with full access to the backup server can’t read your VMs.
Enable it on the PVE side when adding or editing the PBS storage — there’s an Encryption Key option. PVE can generate a key for you, or you can supply one. From the CLI you can generate and inspect keys with the backup client:
# generate an encryption key on the PVE host
proxmox-backup-client key create /etc/pve/priv/pbs-enc.key
# print the key as a recovery paper-key you can store offline
proxmox-backup-client key paperkey /etc/pve/priv/pbs-enc.keyWhere PBS fits
Stand up PBS on its own hardware, create a datastore on real storage, wire it into PVE with a token and the right fingerprint, and you have deduplicated incremental backups that you can verify and restore on demand. The encryption and pruning steps turn it from a working setup into one you can leave running.
If you’re still deciding how much backup machinery you need, start with the vzdump backup and restore guide for the built-in approach, and reach for PBS once you have enough VMs that storage and verification start to matter. Teams coming from other platforms may also want the Proxmox VE vs VMware ESXi comparison for context on how the backup story differs. For more walkthroughs, browse the Proxmox guides.
