PBS Performance Tuning: Optimize Backup Speed

Your backup job is taking four hours. It could finish in 45 minutes. Proxmox Backup Server has a collection of tuning knobs buried in sysctl, ZFS properties, and the PBS daemon config that most admins never find. Initial seed uploads crawl over WAN not because the link is too slow, but because TCP buffers are sized for 1999. This post covers the specific changes that actually move the needle.

Where PBS Bottlenecks Happen

Before touching any settings, identify which layer is your actual bottleneck. Tuning TCP buffers on a disk-bound system wastes time.

Three places kill PBS performance:

Network limits initial seeds and remote sync jobs. Symptoms: backup throughput tracks exactly with your link speed, CPU and disk sit idle.

Disk I/O limits incremental backups and restores. Symptoms: iotop shows 100% utilization on the datastore drive, network interface is underutilized.

CPU limits encryption and compression throughput. Symptoms: htop shows one or more cores pinned, disk and network are both idle.

Diagnostic Commands

Check what is saturated before tuning:

# Disk I/O per process — look for proxmox-backup or backup-proxy
iotop -a -o

# CPU per core
htop

# Active connections and current socket buffer sizes
ss -tnp | grep backup

# Real-time disk throughput on your datastore volume
iostat -xm 2 /dev/sdX

If iotop shows proxmox-backup saturating your disks, fix storage first. If ss shows tiny socket buffer sizes on an offsite link, start with network tuning.

Network Optimization

Network is the bottleneck for offsite sync and initial seeds. Linux's default TCP socket buffers were calibrated for LAN speeds and have not kept pace with modern WAN links.

TCP Buffer Tuning

The kernel defaults cap socket buffers around 128K-256K. On a 1Gbps WAN link with 20ms RTT, this limits throughput well below line rate. The bandwidth-delay product at that RTT demands a buffer of at least 2.5MB to fill the pipe:

# Maximum socket receive and send buffers (128 MB)
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728

# TCP read/write buffers: min, default, max
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

# Required for large buffers to take effect
net.ipv4.tcp_window_scaling = 1

# BBR congestion control — better than cubic on variable-latency WAN links
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Apply with sysctl -p /etc/sysctl.d/99-pbs-network.conf. These settings survive reboots.

MTU Considerations

If your backup VLAN supports jumbo frames end-to-end (switches, NICs, and the remote side), set MTU 9000 on the backup interface. This reduces per-packet overhead and lowers CPU interrupt load at high throughput:

# Test first (non-persistent)
ip link set eth1 mtu 9000

# Verify with a large ping to the remote PBS target
ping -M do -s 8972 <pbs-target-ip>

Only configure this if your entire path supports jumbo frames. A mismatch causes fragmentation and usually makes performance worse.

Bandwidth Throttling

PBS sync jobs accept a --rate limit. Set this during business hours to protect production traffic; remove it or increase it for overnight windows:

# Limit to 100 MiB/s
proxmox-backup-manager sync-job update your-sync-job --rate 100MiB

# Remove limit for overnight runs
proxmox-backup-manager sync-job update your-sync-job --rate ""

Without a rate limit, a large initial sync will saturate your uplink and affect everything else on the connection.

WireGuard vs Direct Connection

If your offsite PBS target is behind WireGuard, expect 5-10% throughput reduction from tunnel overhead. WireGuard at the kernel level is significantly faster than OpenVPN userspace. For a dedicated backup link where both machines sit in the same datacenter, a direct VLAN without a tunnel is faster still — though you lose the encryption layer in transit.

Storage Backend Tuning

Most PBS deployments use ZFS. The default ZFS properties are not optimized for PBS write patterns.

ZFS recordsize

Proxmox Backup Server stores data as variable-size chunks that average around 4MB. ZFS's default recordsize is 128K, which means a single PBS chunk write triggers roughly 32 separate ZFS record writes. Setting recordsize to 1M aligns ZFS records much closer to PBS's write size and reduces metadata overhead:

zfs set recordsize=1M tank/pbs-datastore

Other ZFS Properties

# PBS compresses its own chunks. ZFS compression on top wastes CPU.
# Disable if PBS compression is enabled (the default).
zfs set compression=off tank/pbs-datastore

# If PBS compression is disabled (e.g., for pre-compressed VM images),
# lz4 at the ZFS level is reasonable:
# zfs set compression=lz4 tank/pbs-datastore

# Prevent your ZFS management tool from snapshotting the datastore
zfs set com.sun:auto-snapshot=false tank/pbs-datastore

SLOG and L2ARC

A SLOG (ZIL separate log device) accelerates synchronous writes. PBS issues fsync() calls when finalizing chunk writes, so a small NVMe SLOG device can help on spinning-disk arrays by offloading those sync operations. On all-NVMe pools, SLOG adds hardware complexity without meaningful benefit.

L2ARC (second-level read cache) benefits restore workloads, not backup writes. If you restore frequently from a spinning-disk datastore, an L2ARC SSD can cut restore times significantly. It does nothing for ongoing backup throughput.

ext4 and XFS Alternatives

ZFS has overhead that matters on commodity hardware. For dedicated PBS nodes on modern NVMe storage where you do not need ZFS checksumming or snapshots, ext4 or XFS with tuned mount options can outperform ZFS for raw sequential throughput. Test both if you are building a new node. For existing setups, the ZFS tuning above closes most of the gap.

PBS-Specific Settings

Chunk Verification After Backup

By default, Proxmox Backup Server runs a verification pass immediately after each backup job completes. This re-reads the written chunks and validates their hashes. On unreliable or untested storage it is a reasonable safeguard. On a ZFS pool with checksums enabled, it is redundant and adds significant I/O and CPU load right at the end of your backup window.

Disable per-backup verification in the datastore settings (Datastore > Options > "Verify New Backups" off). Replace it with a scheduled verify job during off-peak hours where you have full control over timing. See PBS verify jobs for scheduling strategies.

Compression Settings

PBS uses ZSTD at level 1 by default for stored chunks. Level 1 is a sensible default — it compresses substantially better than LZ4 at similar CPU cost. Higher ZSTD levels (3, 6, 12+) produce meaningfully smaller chunks only for highly compressible data, while consuming dramatically more CPU per chunk.

If your backup data is already compressed (database dumps with page compression, pre-compressed archives, media files), disable PBS compression for those jobs entirely:

proxmox-backup-manager datastore update your-datastore \
    --tuning compress=false

Compressing incompressible data wastes CPU cycles and saves zero space.

Parallel Job Limits

PBS scales worker task counts with CPU count, but you can set explicit limits to prevent backup storms from overwhelming I/O:

# Show current node configuration
proxmox-backup-manager node-config show

# Cap concurrent workers — tune to your CPU and storage I/O capacity
proxmox-backup-manager node-config update --max-workers 8

More concurrent workers increase throughput when you have spare CPU and disk headroom. They hurt performance when you exceed either.

Garbage Collection Scheduling

GC is I/O-intensive and competes directly with active backup jobs. Running GC during a backup window cuts effective throughput roughly in half. Schedule GC for off-peak maintenance windows, well clear of your backup start times. See pruning and garbage collection for retention policy configuration and safe scheduling.

Client-Side Optimization

Exclusion Patterns

Backing up temp directories, cache files, and virtual filesystems adds data that has no recovery value. Adding exclusion patterns to vzdump shrinks backup size and cuts runtime:

# Exclude directories that contain no useful backup data
exclude-path: /tmp
exclude-path: /var/tmp
exclude-path: /var/cache
exclude-path: /run
exclude-path: /proc
exclude-path: /sys

For VM backups with the QEMU guest agent active, exclusions apply at the guest filesystem level. Without the agent, vzdump snapshots the entire disk.

vzdump Performance Settings

# Reduce I/O priority so backup does not compete with production VMs
# ionice class 3 (idle) — backup runs only when disk is otherwise free
vzdump 101 --ionice 7 --storage pbs-storage

# Limit bandwidth in KB/s during business hours (102400 = 100 MB/s)
vzdump 101 --bwlimit 102400 --storage pbs-storage

Encryption Overhead

PBS uses AES-256-GCM for client-side encryption. On CPUs with AES-NI hardware acceleration (Intel Westmere and later, AMD Zen and later), encryption adds less than 5% to total backup time. The bottleneck on encrypted jobs is almost never the encryption itself.

Run proxmox-backup-client benchmark to see the exact delta on your hardware. If your PBS nodes lack AES-NI and encryption overhead is significant, consider a dedicated PBS node with a modern CPU. Read PBS client-side encryption for full key management tradeoffs.

Multi-Client Optimization

When multiple clients back up to the same PBS datastore simultaneously, they compete for the same disk I/O pool. PBS processes jobs in parallel, but the underlying storage has fixed IOPS.

Stagger Backup Windows

Schedule jobs with 30-60 minute offsets between clients. Ten VMs starting at 02:00 simultaneously produce a write storm for the first several minutes. The same ten VMs starting at 02:00, 02:30, 03:00... each get room to complete their initial burst before the next job stresses the datastore.

PBS backup scheduling covers cron syntax and staggering strategies for multi-client environments.

Per-Client Bandwidth Limits

For sync jobs sending data to remote PBS targets, set per-job rate limits so no single large client monopolizes the uplink:

proxmox-backup-manager sync-job update client-a-offsite --rate 50MiB
proxmox-backup-manager sync-job update client-b-offsite --rate 50MiB
proxmox-backup-manager sync-job update client-c-offsite --rate 50MiB

Namespace Isolation

PBS namespaces partition a single datastore into logical segments per client or tenant. Namespaces share the underlying disk pool, so they do not provide I/O isolation. They do provide credential isolation (separate tokens per namespace) and allow per-namespace retention policies. See capacity planning for multi-client setups for datastore sizing across tenants.

Benchmarking Your Setup

Tune against real numbers. Before changing anything, establish a baseline.

Raw Network Throughput

# On the PBS target (server mode)
iperf3 -s

# On the source machine (4 parallel streams for 30 seconds)
iperf3 -c <pbs-target-ip> -t 30 -P 4

This gives you the ceiling for backup transfers to that target. If you see 900 Mbps raw but 200 Mbps in PBS, the bottleneck is not the network link.

Raw Disk Throughput

fio --name=write-test \
    --ioengine=libaio \
    --rw=write \
    --bs=4M \
    --direct=1 \
    --size=10G \
    --numjobs=1 \
    --runtime=60 \
    --group_reporting \
    --filename=/mnt/pbs-datastore/fio-test

# Clean up after
rm /mnt/pbs-datastore/fio-test

Compare this against your actual PBS backup throughput reported in the task log. If PBS backup speed is less than 50% of raw disk write speed, compression and chunking overhead is the likely cause.

PBS Built-in Benchmark

proxmox-backup-client benchmark

This tests local chunk write throughput and reports MB/s for both encrypted and unencrypted modes. Use it to verify that AES-NI is active and to quantify encryption overhead on your specific CPU before deciding whether it matters for your workload.

Establishing a Baseline

Before tuning, run a full backup job and record:

• Wall-clock time from start to finish
• Average MB/s from the PBS task log
• CPU and disk utilization during the job (sar -u 1 and sar -d 1)

Change one variable at a time. Run the same backup again. Compare. This is the only reliable way to know whether a change actually helped or just moved the bottleneck elsewhere.

Wrapping Up

The highest-return changes for the least effort are ZFS recordsize and TCP buffer tuning. Set recordsize=1M on your PBS datastore dataset before the next GC cycle, apply the sysctl buffer changes on both source and target, and you will see measurable improvement without touching anything else.

From there, work inward. Disable double-compression (ZFS compression off when PBS compression is on). Stagger backup schedules so jobs do not pile onto disk simultaneously. Replace per-backup chunk verification with scheduled verify jobs during off-peak windows.

The more specialized tuning — BBR congestion control, SLOG devices, explicit worker limits — pays off mainly at scale or under specific hardware constraints. For a handful of VMs on modern hardware, the first three changes close most of the gap between a default install and a tuned one.