Imagine your company has 10 computers all downloading the exact same 100MB internal onboarding document. If you back up the entire drive of all 10 machines to an external drive, you squander 1GB storing duplicate data. Traditional virtual machine backups burn through storage in the exact same wasteful way. Proxmox Backup Server (PBS) resolves this bottleneck. The system stores only a single copy of any chunk of data and simply creates reference pointers for the remaining 10 machines.
My lab infrastructure currently runs Proxmox VE hosting 12 VMs and containers. Previously, running a full cluster backup was a nightmare: internal network congestion, NAS capacity draining at record speed. Migrating to PBS eliminated that burden entirely.
Comparing Proxmox VM Backup Solutions
Proxmox infrastructure administrators typically consider three primary approaches:
- Traditional VZDump (Full Backup to NAS/NFS): Each backup run creates an archive file (.vma.zst) packaging the entire virtual disk. Today’s data may be identical to yesterday’s, yet the system rewrites everything from scratch. It wastes disk space and takes hours to complete.
- Snapshots with ZFS Send/Receive: Extremely fast because it transfers only changed blocks. The downside is that you must run ZFS on both the source and target nodes, and configuring retention policies can get cumbersome.
- Proxmox Backup Server (Chunk-based Deduplication): PBS splits disks into small chunks (averaging 4MB) and computes a SHA-256 hash for each. Any chunk that already exists on the server is skipped. Only brand-new chunks are transmitted over the wire.
Technical Comparison Table
Each solution involves distinct trade-offs between resource consumption and ease of use:
| Criteria | VZDump (Full Backup) | ZFS Send/Receive | Proxmox Backup Server (PBS) |
|---|---|---|---|
| Backup Speed | Slow; easily saturates local networks | Very fast | Blazing fast (transfers new chunks only) |
| Storage Efficiency | Worst; wastes terabytes of storage | Decent | Optimal (Deduplication factors of 4x to 15x) |
| Remote Storage Security | Manual archive password protection | Requires ZFS Native Encryption | Client-side Encryption (handled directly by PVE) |
| Single File Restore | Must unpack large backup archives | Requires manual snapshot mounting | Browse and download individual files directly via web UI |
The most compelling advantage of PBS is Client-side Encryption. The secret encryption key remains on the Proxmox VE (PVE) host. PVE chunks and encrypts data locally before sending it across the network to PBS. Even if your PBS instance resides in an untrusted third-party datacenter, their technicians cannot inspect the contents of your VMs. For scenarios where catastrophic hypervisor failures occur, knowing how to Rescue KVM/Proxmox VMs with libguestfs is an equally invaluable disaster recovery skill.
When Should You Switch to PBS?
If your setup only hosts 1 or 2 static VMs with minimal data changes, plugging in an external drive and scheduling a weekly VZDump is plenty. There is no need to overcomplicate things.
However, setting up PBS is a no-brainer if you manage 5 or more VMs, especially with multiple instances running the same OS like Ubuntu or Optimizing Windows on KVM/Proxmox. PBS is also a lifesaver when you need hourly backups during business hours. Backup times plummet from 30 minutes to just 15–30 seconds without choking your local network, pairing well with architectures using Configuring Proxmox VE Replication with ZFS for robust disaster recovery.
5 Practical Steps to Set Up Proxmox Backup Server
Step 1: Create a Datastore on PBS
After installing PBS, access the web UI (port 8007) or connect via SSH. Dedicated SSD storage is strongly recommended for the datastore to maximize chunk hashing throughput, though you should keep in mind strategies from our Proxmox VE Optimization Guide for Consumer SSDs to avoid excessive write amplification:
# Create datastore directory
mkdir -p /mnt/backup-pool/pbs-datastore
chown -R backup:backup /mnt/backup-pool/pbs-datastore
# Initialize a datastore named 'production-backup'
proxmox-backup-manager datastore create production-backup /mnt/backup-pool/pbs-datastoreStep 2: Retrieve the PBS Authentication Fingerprint
Extract the SHA-256 certificate fingerprint so PVE can verify the authenticity of the PBS host, mitigating man-in-the-middle risks:
proxmox-backup-manager cert info | grep "Fingerprint:"Step 3: Generate an Encryption Key on Proxmox VE
Log in to your PVE node to generate an encryption key. This key file remains local and encrypts chunks before network transmission:
# Generate a random encryption key in the PVE configuration directory
pvesm pbs-encryption-key create /etc/pve/pbs-enc.key
# Verify the fingerprint of the newly generated key
pvesm pbs-encryption-key show /etc/pve/pbs-enc.keyStep 4: Attach the PBS Storage Target to Proxmox VE
Declare the PBS instance as an active storage target directly via the Proxmox VE CLI:
pvesm add pbs PBS-Storage \
--server 192.168.1.50 \
--datastore production-backup \
--username root@pam \
--password 'YourPBSPassword' \
--fingerprint 'ab:cd:12:34:56:78:90:ef:ab:cd:12:34:56:78:90:ef:ab:cd:12:34:56:78' \
--encryption-key /etc/pve/pbs-enc.keyStep 5: Run a Backup and Monitor Deduplication Ratios
Execute a test backup on any virtual machine (e.g., VM ID 101):
vzdump 101 --storage PBS-Storage --mode snapshotDuring the initial run, the system uploads raw data in its entirety. Wait 10 minutes and execute the exact same command a second time. The task should complete within seconds.
Navigate to Datastore Summary in the PBS web console. The Deduplication Factor will be visible immediately. Across 5 Linux virtual machines sharing identical base images, this ratio frequently reaches 4.0x to 8.0x in short order, saving hundreds of gigabytes of disk space.
A Critical Warning About Encryption
Client-side encryption safeguards your infrastructure against prying eyes, but there is no “forgot password” feature. If you lose the pbs-enc.key file, the backups stored on your PBS server become irreversible gibberish. Nobody will be able to recover them.
Immediately after Step 3, back up this key file to at least two isolated locations: a trusted password manager such as Bitwarden or 1Password, and a printed paper copy secured in a safe.
