Proxmox Backup Server 4.0: What Has Changed Since 3.x

Proxmox Backup Server (PBS) is the backup component in the Proxmox stack — tightly integrated with Proxmox VE, but also usable standalone as a deduplicating backup target. PBS 4.0 has been available as a stable release since mid-2025, in parallel with the jump from Proxmox VE 8.x to 9.x. Several point releases have followed, and the picture of what 4.0 actually brings over 3.x has become clearer.

This article summarises the most important changes from the official PBS 4.0 release notes and Proxmox forum threads — no invented benchmarks. Where we contextualise a statement, the source is named.

What PBS does — a brief recap

PBS stores VM and container backups from Proxmox VE in a deduplicating data store. Unlike classic image backups, PBS processes only the changed data blocks per backup run (dirty bitmap from the hypervisor) and adds them to a content-addressed store in which identical blocks live only once. That saves both backup window and storage consumption substantially — typical deduplication ratios for VM workloads sit between 5:1 and 15:1 depending on data pattern (per PBS documentation and our customer-setup experience, not measured in a controlled benchmark).

Version base: 3.x vs. 4.x

Component	PBS 3.x (latest stable: 3.4)	PBS 4.x (4.0+)
Debian base	Bookworm (12)	Trixie (13)
Linux kernel	6.8	6.x (Trixie default with backports)
ZFS	2.2	2.3
Rust toolchain	stable 2024	current stable 2025
Database	proxmox-backup native	proxmox-backup native (internal structures extended)
GUI framework	ExtJS 7.x	ExtJS 7.x (reworked views)

The jump to Trixie is the main reason for the 4.0 version number — analogous to Proxmox VE 9.0, which also moved to Trixie. That means new glibc, new OpenSSL, updated tape drivers and therefore a hard backward compatibility line.

What is actually new

1. Synthetic backup

One of the more useful additions: synthetic backup. Previously every backup run was a full snapshot sync against the production VM/CT. With synthetic backup new backup snapshots can be assembled from existing snapshots — e.g. a weekly full backup from the last full plus the incrementals in between, without touching the VM itself.

Practical value:

• Long retention chains can be smoothed without weekly real full backups
• Off-hour servers (e.g. powered down at night) can still get consistent weekly full backups
• Bandwidth between production cluster and PBS drops noticeably for long retention policies

Source: PBS 4.0 and 4.1 release notes.

2. Mountpoint backup for containers

Container backup in PBS 3.x was already decent for LXC, but treated additional mountpoints somewhat poorly. PBS 4.x backs up mountpoints more explicitly — including bind mounts and external storage mountpoints — making restore scenarios more reliable when a container aggregates data from several volumes.

Anyone running LXC containers with large data volumes (e.g. file servers, nginx reverse proxy with cache volumes, database containers with separate tablespace mounts) gets a more consistent backup model with 4.x.

3. Tape improvements

Tape backup has become rare in SMB environments, but still has its place in regulated industries — particularly as an air-gap layer in a defence-in-depth strategy. PBS 4.0 brings several tape improvements from the Trixie update:

• Updated mtx, mt-st, lto-cli versions — with better detection of newer LTO generations
• More stable library robotics communication (notably for HP MSL and Quantum Scalar libraries)
• Improved tape pool management in the WebUI
• Faster restore indexing for long tape sets

A tape air-gap strategy in a 3-2-1 backup model (see our 3-2-1 backup rule) becomes attractive again for SMB banks, insurers and healthcare customers.

4. S3 object store targets (in preparation / preview)

One of the most discussed additions: S3-compatible object store targets as secondary backup destinations. According to the official roadmap wiki page, S3 support is listed as a planned extension; part of the functionality is available as a preview in current point releases, but not yet generally production-ready.

What it will bring:

• Off-site replication into cost-optimised object storage (AWS S3, Wasabi, Backblaze B2, TrueNAS S3)
• Reduced setup for third-site backups — no second PBS instance required
• Clear separation of fast recovery (primary PBS) and long-term retention (S3 tier)

Important framing: anyone planning this for production should verify the current release date and maturity against the forum thread or roadmap before making an architecture decision. At DATAZONE we currently recommend using S3 targets for test and secondary setups, not as a primary line.

5. ZFS 2.3 as storage base

PBS data stores often sit on a ZFS pool. With the move to ZFS 2.3 PBS automatically gets:

• RAIDZ expansion (tech preview in 2.2, production-ready in 2.3): existing RAIDZ VDEVs can be extended with additional disks
• Block cloning improvements: faster clones of datasets in PBS-internal operations
• Better ARC memory management on systems under high memory pressure

Anyone planning the further jump to OpenZFS 2.4: PBS 4.x is pinned to 2.3, a 2.4 update will come in a later PBS version. AnyRaid and BRT improvements from 2.4 are therefore not directly available in PBS — anyone building new backup storage in parallel can realise this as a sync target on TrueNAS 26 with OpenZFS 2.4.

6. Improved verification and garbage collection

Verify jobs (checking block-level hashes) and GC jobs (removing old chunks) are noticeably faster and more parallelisable in PBS 4.x. The docs mention factors between 1.5x and 3x depending on data store size and storage type; our own experience from DATAZONE customer setups confirms the order of magnitude, but we have not run controlled benchmarks in a lab — read the statement as “noticeably better, but workload-dependent”.

What has not changed — and that is good

A few things stayed deliberately stable in PBS 4.x:

• Data store format — backups from PBS 3.x can be read by PBS 4.x without conversion. Moving data stores between PBS versions or importing an old one has no compatibility breakage.
• API — scripts against proxmox-backup-client that ran under 3.x continue to run under 4.x. We have seen no breakage in several migration tests; Proxmox’s API stability is a real advantage.
• Replication format between PBS instances — sync jobs between 3.x and 4.x are compatible.

Updated hardware guidance

With the move to Trixie and ZFS 2.3 it is worth looking at hardware sizing again — what we see in customer setups as pragmatic lower bounds:

Workload size	CPU	RAM	Storage
Small (1–5 VMs, < 1 TB backup volume)	4 cores	16 GB	2× SSD/HDD ZFS mirror, from 1 TB
Medium (5–30 VMs, 1–10 TB)	8 cores	32 GB	RAIDZ2 4–6× HDD or all-flash mirror
Large (30+ VMs, > 10 TB)	16+ cores	64 GB+	RAIDZ2/dRAID with NVMe special VDEV

Important: PBS is clearly RAM-sensitive due to chunk index cache structures. ZFS ARC and PBS internal caching compete — for large data stores 64 GB RAM is not exaggeration, it is a prerequisite for verify and GC performance.

Upgrade path 3.x → 4.x

The official upgrade path is documented in the PBS wiki. Short form:

1. Update PBS 3.x to the latest 3.4.x version — the last stable line before 4.x
2. Run a data store verification before touching the system
3. System backup (config dump + optionally full OS backup if VM/container)
4. Run the pbs3to4 check script — reports known incompatibilities
5. Switch repo list to Trixie, apt update && apt dist-upgrade
6. Reboot, smoke test — VM backups, restore test, tape test
7. Re-verify data store sync jobs to PBS partners

Experience: with clean preparation the upgrade on a medium-size PBS instance takes 30–60 minutes including reboot. Data store reindexing then runs as a background task.

What does it mean for the backup strategy?

PBS 4.x does not change the what of backup strategy — the 3-2-1 rule remains the right model, immutable backups against ransomware remain important, replication to an off-site location remains mandatory.

PBS 4.x changes the how:

• Synthetic backup simplifies long retention without production load
• Improved mountpoint backup makes container backups more reliable
• Tape stability reactivates air-gap strategies
• S3 targets (once production-ready) extend the off-site options

DATAZONE recommendation

Anyone running PBS 3.x with stable operations can plan, but not rush the upgrade. PBS 3.4 continues to receive security fixes in parallel; the natural moment for the jump to 4.x is the next maintenance window or in combination with a Proxmox VE 9.x upgrade.

Anyone building new backup infrastructure: start with PBS 4.x directly. The benefits (synthetic backup, better mountpoint handling, more modern storage stack) come for free in the initial install.

We help with sizing — from hardware specification through retention policy to restore testing. More under our backup strategy advisory.

Sources and related articles

• Proxmox Backup Server roadmap and release notes
• Upgrade from PBS 3 to 4 — official wiki
• Proxmox forum — PBS 4.x discussions
• 3-2-1 backup rule for SMBs
• Backup strategy with Proxmox and TrueNAS
• Immutable backups against ransomware
• TrueNAS replication as air-gap backup
• Proxmox VE 9.2 — the current hypervisor release