Proxmox Backup Server: Automated VM Backups Made Easy

There is one rule in IT that never changes: backups are not optional. And yet, for many homelab users and small IT teams running Proxmox VE, the backup story often comes down to an occasional manual snapshot, a scheduled vzdump dump to an NFS share, or — worst of all — nothing at all. That works until it doesn’t.

Proxmox Backup Server (PBS) changes the conversation entirely. It is Proxmox’s dedicated, enterprise-grade backup solution that brings incremental backups, global deduplication, client-side AES-256 encryption, automated scheduling, and integrity verification into a single, completely free, open-source platform. The latest release — PBS 4.2, announced on April 29, 2026 — introduces native S3-compatible object storage, improved sync performance, parallel multi-group sync jobs, and on-the-fly encryption for push sync operations.

This guide covers everything from installation to daily-driver usage: what PBS is, how it works under the hood, how to install it, connect it to Proxmox VE, configure automated backup schedules with proper retention policies, enable encryption, and verify that your backups actually restore correctly.

By the end of this article, your VMs will be protected automatically — every night, every week, or on whatever schedule fits your environment.

What Is Proxmox Backup Server and Why Should You Use It?

Proxmox Backup Server is an open-source, client-server backup solution built specifically for backing up virtual machines, LXC containers, and physical hosts. It runs as a standalone Debian-based server and is licensed under the GNU AGPLv3 — meaning the core product is completely free, with optional paid subscriptions available for enterprise support and the enterprise package repository.

It is written primarily in Rust, which delivers high performance, low resource consumption, and strong memory safety guarantees without the overhead of a Java-based or Python-based backup stack.

How PBS Differs from vzdump

Proxmox VE ships with a built-in backup tool called vzdump that can dump VM disk images to a local directory, NFS share, or CIFS share. For many people, that is the first backup method they encounter. Here is why PBS is a fundamentally different (and better) approach for regular, automated backups:

Feature	vzdump to NFS/CIFS	Proxmox Backup Server
Backup type	Full dump every time	Incremental (delta only)
Deduplication	None	Global, chunk-based
Compression	gzip/lzo	Zstandard (multi-GB/s)
Encryption	None	AES-256 GCM client-side
Integrity verification	None	SHA-256 checksums + verify jobs
Ransomware resistance	Low (same credentials)	High (separate admin boundary)
File-level restore	Limited	Yes, single-file restore
Live restore	No	Yes (start VM while restoring)
Remote sync	Manual	Built-in sync jobs
S3 backend	No	Yes (PBS 4.x)
Web UI management	None	Full web dashboard

The headline advantage is storage efficiency. Because PBS performs incremental, deduplicated backups, subsequent backups after the first full backup only transfer and store the blocks that have actually changed. For environments with many similar VMs (for example, multiple CentOS Stream 10 VMs sharing the same base OS), global cross-VM deduplication can reduce storage consumption dramatically. Real-world deduplication ratios in mixed Windows/Linux VM fleets typically land between 4:1 and 10:1.

PBS 4.2: What’s New in the Latest Release

PBS 4.2 (April 29, 2026) builds on Debian 13.4 “Trixie” and ships with Linux kernel 7.0 as the default, alongside ZFS 2.4 for reliable local storage. The major improvements in this release include:

Push sync encryption on the fly — Sync jobs can now encrypt snapshots during transmission to remote datastores, making it safe to push backups to less-trusted remote PBS instances or colocation facilities without pre-encrypting at the source.

Parallel sync workers — Sync jobs now process multiple backup groups simultaneously using the new worker-threads property. This significantly improves throughput on high-latency networks and overcomes HTTP/2 connection limitations.

Native S3-compatible object storage — S3-compatible backends are now officially supported as a backup storage target, opening the door to offsite backups on AWS S3, Cloudflare R2, MinIO, or any S3-compatible provider.

Backup group and namespace reorganization — Administrators can now move backup groups and namespaces to different locations within the same datastore, with per-group locking ensuring data consistency throughout the move.

Improved sync logging — Contextual log prefixes and better visibility for push sync jobs make troubleshooting much easier in large multi-node environments.

System Requirements for Proxmox Backup Server

PBS is lightweight by design and can run on modest hardware. However, for production use, the following specifications provide a solid foundation:

Component	Minimum (Evaluation)	Recommended (Production)
CPU	64-bit AMD or Intel	4+ cores, modern gen
RAM	4 GB	8–16 GB
Boot Disk	8 GB	32+ GB SSD
Backup Storage	Depends on VM count	ZFS pool (SSD preferred)
Network	1 GbE	10 GbE (dedicated VLAN)
USB Drive	2 GB (installer)	—

Important notes:

• PBS should run on a dedicated physical machine, separate from the Proxmox VE hosts it backs up. Running PBS as a VM on the same host it backs up creates a dangerous circular dependency.
• The backup datastore should reside on a dedicated disk or ZFS pool, not on the same disk as the PBS OS.
• For the network, keep backup traffic on a dedicated VLAN or physical interface isolated from production traffic. A PBS verify job can saturate a 10 GbE link.
• Add roughly 1 GB of RAM per TB of backup storage on top of the base OS requirement for filesystem cache.

Part 1: Install Proxmox Backup Server

Step 1.1 — Download the PBS ISO

Download the latest Proxmox Backup Server ISO from the official downloads page at proxmox.com/en/downloads. The current stable release is PBS 4.2. The ISO is approximately 1.3 GB.

Verify the download using the SHA256 checksum listed on the downloads page:

sha256sum proxmox-backup-server_4.2-1.iso

Step 1.2 — Flash to USB and Boot

Flash the ISO to a USB drive using Rufus (Windows) or dd (Linux/macOS). Use DD Image mode in Rufus when prompted.

Boot your dedicated PBS machine from the USB drive. Select Install Proxmox Backup Server from the boot menu.

Step 1.3 — Follow the Installer

The installation wizard guides you through:

1. License Agreement — Accept the GNU AGPLv3
2. Target Disk — Select the disk for the PBS operating system. For ZFS redundancy, select multiple disks and configure RAID-Z or mirror
3. Location and Timezone — Select your country and time zone
4. Root Password and Email — Use a strong password (12+ characters); PBS uses the email for system alerts
5. Network Configuration:

• Select your wired NIC
• Assign a static IP (e.g., 192.168.1.60)
• Set subnet mask, gateway, DNS, and a fully qualified hostname (e.g., pbs.home.lan)

1. Click Install and wait approximately 5–10 minutes
2. Remove the USB drive and reboot

Step 1.4 — Access the PBS Web Interface

After reboot, open a browser and navigate to:

https://192.168.1.60:8443

Accept the self-signed certificate warning and log in with:

• Username: root@pam
• Password: (your root password)

You are now inside the PBS dashboard.

Part 2: Add a Backup Datastore

The datastore is the directory on your PBS server where backup data is physically stored. It is the most important configuration step.

Step 2.1 — Add a Dedicated Disk (Recommended)

If you have a secondary disk in your PBS server dedicated to backup storage, initialize it from the PBS web UI:

1. Go to Administration → Disks
2. Select the disk you want to use for backup storage
3. Click Initialize Disk with GPT
4. Then go to Administration → Disks → ZFS
5. Click Create ZFS Pool, give it a name (e.g., backup-pool), select your disk(s), choose the RAID level (single disk = Single, two disks = Mirror), and click Create

Pro tip: Even for a single disk, ZFS is worth using because it gives you checksumming, easy snapshot management, and a foundation to add a second disk as a mirror later.

Step 2.2 — Create the Datastore

1. In the PBS web UI, click Datastore in the left panel
2. Click Add Datastore
3. Fill in:

• Name: local-backups
• Backing Path: /backup-pool (or whatever mount point your ZFS pool or disk uses)
• Comment: Optional description

1. Click Add

The datastore will now appear in the left panel. Click on it to see its usage statistics, backup groups, and management options.

Part 3: Connect Proxmox VE to Proxmox Backup Server

Now we need to tell Proxmox VE where the PBS instance lives so it can send backups to it.

Step 3.1 — Create a Backup User in PBS (Recommended)

Rather than using root for backups, create a dedicated backup user with minimal permissions:

1. In the PBS web UI, go to Configuration → User Management
2. Click Add and create a user like backup-user@pbs
3. Set a password and save

Then assign permissions:

1. Go to Configuration → Access Control
2. Click Add
3. Set Path to /datastore/local-backups, User to backup-user@pbs, and Role to DatastoreBackup

Step 3.2 — Create an API Token (Optional but Recommended)

For programmatic access and improved auditability, create an API token instead of using the user’s password directly:

1. Go to Configuration → User Management
2. Select backup-user@pbs and click API Token
3. Create a token (e.g., pve-token) and copy the secret immediately — it will not be shown again

Step 3.3 — Add PBS as Storage in Proxmox VE

Log into your Proxmox VE web interface at https://192.168.1.50:8006.

1. Go to Datacenter → Storage
2. Click Add → Proxmox Backup Server
3. Fill in the fields:

• ID: pbs (or any unique name)
• Server: 192.168.1.60 (the PBS IP address)
• Username: backup-user@pbs or the API token reference
• Password / Token Secret: paste the credentials
• Datastore: local-backups
• Fingerprint: Copy this from the PBS web UI under Dashboard → Server Certificate (or run proxmox-backup-manager cert info on the PBS server and copy the SHA-256 fingerprint)

1. Click Add

Proxmox VE will now show pbs as an available storage target. You can immediately see it in the storage list on any node.

Part 4: Configure Automated Backup Schedules

This is where the magic happens. Proxmox VE can automatically back up all (or selected) VMs to PBS on a defined schedule.

Step 4.1 — Create a Backup Job

1. In the Proxmox VE web UI, go to Datacenter → Backup
2. Click Add
3. Configure the job:

• Node: Select your PVE node (or All for multi-node clusters)
• Storage: pbs
• Schedule: Choose a preset (Daily, Weekly) or enter a custom cron expression
  • Daily at 2:00 AM: 0 2 * * *
  • Daily at 2:00 AM Mon–Fri: 0 2 * * 1-5
  • Every 6 hours: 0 */6 * * *
• Selection: All to back up every VM, or select specific VM IDs
• Compression: ZSTD (recommended — much faster than gzip with comparable ratios)
• Mode:
  • Snapshot — creates a live snapshot and backs it up without stopping the VM (recommended for running VMs)
  • Suspend — briefly suspends the VM for a consistent state backup
  • Stop — stops the VM completely before backup (guarantees consistency, but causes downtime)
• Send email to: Enter an address for backup job reports

1. Click Create

The backup job is now active and will run according to the schedule. You can also trigger it manually at any time by selecting the job and clicking Run Now.

Step 4.2 — Set Retention Policies in PBS

Retention policies control how many backup snapshots are kept and for how long. Configure them in the PBS datastore to prevent unlimited storage growth.

1. In the PBS web UI, click on your datastore (local-backups)
2. Go to the Options tab
3. Click Edit on Prune Settings and configure:

Keep Last:    3      (keep the 3 most recent backups)
Keep Hourly:  24     (keep one per hour for the last 24 hours)
Keep Daily:   7      (keep one per day for the last 7 days)
Keep Weekly:  4      (keep one per week for the last 4 weeks)
Keep Monthly: 3      (keep one per month for the last 3 months)
Keep Yearly:  1      (keep one per year for the last year)

You can also set retention policies per VM in the Proxmox VE backup job configuration, which override the datastore-level defaults for that specific job.

The 3-2-1 rule: The minimum sensible strategy is three copies (one primary, two backups), on two different media types, with one copy offsite. A single PBS box in the same rack as your PVE host satisfies none of these requirements on its own. Use PBS sync jobs (covered below) to push backups offsite.

Step 4.3 — Configure Garbage Collection

Because PBS stores backup data as deduplicated chunks, deleted snapshots do not immediately free disk space — the chunks they referenced may still be needed by other snapshots. A Garbage Collection (GC) job cleans up orphaned chunks.

Schedule garbage collection to run during off-hours:

1. In the PBS web UI, click your datastore
2. Go to the Options tab
3. Set a GC Schedule (e.g., daily at 04:00 — after backups complete and before the workday begins)

PBS 3.4 introduced optimized GC performance, and PBS 4.2 further improves it. For datastores with tens of thousands of backup snapshots, GC is more efficient than ever.

Part 5: Enable Client-Side Encryption

One of PBS’s most powerful features is client-side AES-256 GCM encryption. Because encryption happens on the Proxmox VE client before data is sent to PBS, the backup server itself never sees unencrypted data. This makes it completely safe to push backups to untrusted remote locations — colocation facilities, cloud storage, third-party PBS instances — without worrying about data exposure.

Step 5.1 — Generate an Encryption Key

On your Proxmox VE host, open a shell and run:

# Generate a new client-side encryption key
proxmox-backup-client key create /etc/pve/priv/backup-encryption.key

# This will prompt you for a passphrase to protect the key file
# Choose a strong passphrase and document it securely

Alternatively, generate the key via the PBS web UI under Configuration → Encryption Keys.

Step 5.2 — Create a Master Key Backup (Critical)

The encryption key is everything. If you lose it, your backups are permanently unrecoverable — even with full access to the PBS datastore. Generate a paper key for physical offline backup:

# Generate a human-readable paper key version
proxmox-backup-client key paperkey /etc/pve/priv/backup-encryption.key

Print this output and store it in a physically secure location (e.g., a fireproof safe). This is not optional.

Step 5.3 — Enable Encryption in the Backup Job

In the Proxmox VE backup job configuration, set the Encryption field to your key. All future backups for that job will be encrypted at the client before transmission and storage.

To verify encryption is working:

# On the PVE host, list backup snapshots and check for encryption flag
proxmox-backup-client list --repository backup-user@pbs!pve-token@192.168.1.60:local-backups

Encrypted backups are marked in the PBS web UI with a lock icon.

Part 6: Configure Remote Sync for Offsite Backups

Backing up to a PBS instance in the same location as your VMs protects against accidental deletion and hardware failure — but not against site-level events (fire, flood, theft, ransomware). For genuine resilience, sync your backups to a second PBS instance offsite.

PBS 4.2 makes this straightforward with push and pull sync jobs.

Step 6.1 — Set Up a Second PBS Instance (Offsite)

This can be:

• A PBS instance at a second physical location
• A cloud-hosted PBS instance (VPS running PBS)
• A managed PBS service

Step 6.2 — Configure a Sync Job in PBS

1. In your on-site PBS web UI, go to Datastore → local-backups → Sync Jobs
2. Click Add Sync Job
3. Configure:

• Remote: Add the offsite PBS as a remote under Configuration → Remotes
• Remote Store: The datastore name on the remote PBS
• Local Store: local-backups
• Schedule: daily or 0 3 * * * (run after local backups complete)
• Remove Vanished: Enable to prune remote snapshots that no longer exist locally
• Encrypt on Sync (PBS 4.2 new feature): Enable if pushing to a less-trusted remote

Only the delta since the last sync is transferred, making remote sync bandwidth-efficient even over slow internet connections.

Part 7: Verifying Backup Integrity

A backup that has never been tested is not a backup — it is a hope. PBS provides automated tools to verify data integrity, and you should be testing restores on a regular schedule.

Step 7.1 — Schedule Automated Verify Jobs

1. In the PBS web UI, click your datastore
2. Go to Verify Jobs and click Add
3. Set a schedule (e.g., weekly on Sunday at 06:00)
4. Set Outdated After to 30 (force re-verification of chunks not checked in the last 30 days)

The verify job reads every stored chunk and validates its SHA-256 checksum, confirming that backup data has not been corrupted by bit rot, storage hardware issues, or partial writes.

Step 7.2 — Restore a Single File (Live File Browser)

PBS supports single-file restore directly from the web UI without booting a full VM:

1. In the PBS web UI, navigate to your datastore
2. Select a VM backup snapshot
3. Click File Restore
4. Browse the virtual filesystem of the VM image and download individual files or directories

This is invaluable for recovering a specific configuration file, database dump, or accidentally deleted document without performing a full VM restore.

Step 7.3 — Restore a Full VM to Proxmox VE

For a full VM restore:

1. In the Proxmox VE web UI, go to your PBS storage (pbs) in the left panel
2. Select the VM snapshot you want to restore
3. Click Restore
4. Select the target storage, optionally assign a new VM ID, and click Restore

Alternatively, use the Live Restore feature for minimal downtime: the VM starts immediately from the backup while the data is still being transferred in the background.

From the command line on the PVE host:

# Restore VM 100 from a specific backup snapshot to VM ID 9100
qmrestore pbs:backup/vm/100/2026-05-01T02:00:05Z 9100 \
  --storage local-lvm \
  --unique true

# Check restored VM status
qm status 9100

Step 7.4 — Monthly Restore Drill (Best Practice)

Schedule a monthly restore test into your calendar. The procedure:

1. Pick a representative VM (database server, web server, or critical VM)
2. Restore it to a test node with a different VM ID (use --unique true to auto-assign)
3. Start the restored VM and verify it boots correctly
4. Check application functionality (web service responds, database is accessible)
5. Delete the test VM when done

Passing this test monthly means you can confidently state your RTO (Recovery Time Objective) with real data — not theory.

Part 8: Tape Backup for Long-Term Archiving

For environments with compliance requirements or long-term archival needs, PBS supports backing up datastore content to LTO tape libraries. PBS supports LTO-5 and later (with best-effort support for LTO-4), including hardware encryption.

Tape backup is ideal for:

• GDPR, HIPAA, PCI DSS, or NIS2 compliance requiring immutable, air-gapped copies
• Long-term archival at low cost per GB (tape media is extremely cheap per TB)
• Ransomware protection (offline tapes cannot be encrypted by a network attacker)

Configure tape backups under Tape Backup in the PBS left panel. Content can be archived at media-set granularity and restored from tape when needed.

Common Mistakes to Avoid

Not backing up your encryption key. If you enable client-side encryption and lose the key file and its passphrase, your backups are permanently unrecoverable. Generate the paper key, print it, and lock it away before encrypting a single VM.

Skipping the verify job. Silent corruption can happen. Without regular verification, you may discover your backups are unreadable at the worst possible time — during an actual disaster. Schedule weekly verify jobs.

Running PBS as a VM on the same host it backs up. If that PVE host goes down, you cannot reach PBS to restore. Use a dedicated physical machine for PBS.

Sharing a VLAN between backup traffic and production traffic. A large nightly backup can saturate your network. Dedicate a VLAN or physical interface to backup traffic.

Ignoring off-site backups. A PBS server in the same server room as your VMs does not protect you against ransomware that compromises PVE (which would also compromise PBS if they share credentials), fire, or physical theft. Always configure a sync job to a geographically separate PBS instance.

Forgetting to run garbage collection. Without scheduled GC, deleted snapshots do not free disk space. Schedule GC during off-hours, after your backups complete.

PBS Architecture Summary

┌─────────────────────────────────────────────────────────┐
│                 Proxmox VE Host(s)                      │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐         │
│  │  VM 100    │  │  VM 101    │  │  LXC 200   │         │
│  └────────────┘  └────────────┘  └────────────┘         │
│         │                │               │              │
│         └────────────────┴───────────────┘              │
│                          │                              │
│              Backup Job (scheduled, encrypted)          │
└──────────────────────────┼──────────────────────────────┘
                           │ TLS + AES-256 GCM
                           ▼
┌──────────────────────────────────────────────────────────┐
│             Proxmox Backup Server (dedicated)            │
│                                                          │
│  ┌──────────────────────────────────────────────────┐    │
│  │             Datastore (ZFS pool)                 │    │
│  │  • Deduplicated chunks (SHA-256 addressed)       │    │
│  │  • Zstandard compressed                          │    │
│  │  • Encrypted at rest (if client-side enc on)     │    │
│  │  • Integrity verified (verify jobs)              │    │
│  └──────────────────────────────────────────────────┘    │
│                         │                                │
│              Prune + GC (scheduled)                      │
└─────────────────────────┼────────────────────────────────┘
                          │ Sync job (delta only)
                          ▼
┌──────────────────────────────────────────────────────────┐
│        Remote PBS / S3-Compatible Storage (offsite)      │
│          (3-2-1 backup strategy completed)               │
└──────────────────────────────────────────────────────────┘

Quick Reference: Essential PBS CLI Commands

# List all backup snapshots in a datastore
proxmox-backup-client list \
  --repository backup-user@pbs!token@192.168.1.60:local-backups

# Manually run a backup job from PVE shell
vzdump 100 --storage pbs --mode snapshot --compress zstd

# Restore VM 100 from backup to new VM ID 9100
qmrestore pbs:backup/vm/100/2026-05-01T02:00:05Z 9100 \
  --storage local-lvm --unique true

# Run a manual garbage collection on a datastore
proxmox-backup-manager garbage-collection start local-backups

# Run a manual verify job on a datastore
proxmox-backup-manager verify-job create manual-verify \
  --store local-backups \
  --schedule "now"

# Check datastore status and deduplication factor
proxmox-backup-manager datastore status local-backups

Summary

Proxmox Backup Server is one of the most compelling pieces of open-source infrastructure software available today. The combination of incremental backups, global deduplication, AES-256 client-side encryption, SHA-256 integrity verification, automated scheduling, and native Proxmox VE integration — all at zero licensing cost — is genuinely difficult to match even with expensive commercial alternatives.

With PBS 4.2 bringing native S3 storage support, parallel sync workers, and on-the-fly push encryption, the platform has matured into a solution that holds its own in serious production environments.

The key takeaways from this guide:

• Always run PBS on a dedicated physical machine, separate from your VMs
• Use a ZFS pool for the backup datastore
• Enable client-side AES-256 encryption and back up your encryption key offline
• Schedule automated backup jobs, verify jobs, and garbage collection to run during off-hours
• Configure a remote sync job to satisfy the off-site requirement of the 3-2-1 rule
• Test your restores monthly — a backup is only valuable if it restores successfully

Your VMs are your infrastructure. Protecting them properly with Proxmox Backup Server is the single most important thing you can do for the resilience of your environment.