Learn Proxmox Backup Server - Backup Storage: ZFS, ext4 & SMB/NFS

#Introduction

Security in episode 14 makes the repository resilient — now we talk about the ground the data stands on: storage. All PBS chunks, dedup, and snapshots live on top of a filesystem, and the filesystem choice determines durability, performance, and the features available. Episode 15 covers ZFS, ext4 + LVM, and NFS/SMB as datastore hosts.

Imagine PBS like a hospital: the datastore is the sample storage room. ZFS is an air-conditioned room with a recording system and automatic backup; ext4+LVM is a simple room maintained manually; and NFS is a room in the building across the street — it still works, but every time you fetch a sample you must cross the road (network latency).

#ZFS: The Primary Choice

#Compression, Snapshots, and Checksums

ZFS is Proxmox's primary recommendation for datastores because of three capabilities that perfectly complement PBS:

Compression: ZFS can be compressed (lz4/zstd) as a second layer after PBS compression. Be careful with double compression — if PBS already compresses (zstd by default), the stored chunks are already dense and ZFS cannot compress them further. Many admins choose to compress in PBS only.
Snapshots: the immutability foundation from episode 14 — read-only ZFS snapshots for anti-ransomware protection.
Checksums: ZFS validates block integrity when read (end-to-end checksum), a second layer below PBS chunk checksums to catch bit rot earlier.

#Best Practice: recordsize 1M

One setting is a must for PBS datastores: recordsize 1M (1 MiB). The ZFS default for data datasets is 128K — but PBS chunks are up to 4 MiB and written sequentially. A larger record size means:

Large sequential I/O is more efficient (fewer metadata blocks).
Matching large chunk sizes → less fragmentation.

Create a datastore dataset with recordsize 1M

zfs create -o recordsize=1M -o compression=lz4 rpool/data

Also set xattr=sa and atime=off for better metadata performance and reads. A separate ZFS dataset for the datastore makes snapshots and space monitoring easier.

Important

Change recordsize before the datastore fills up, and weigh ZFS compression vs PBS compression: enable only one of them to avoid wasting CPU on already-dense data. ZFS lz4 is very light, but compressed PBS chunks will not shrink any further.

#The Alternative: ext4 + LVM

#When to Choose It

Not every environment has ZFS — whether due to team preference or existing hardware. ext4 on top of LVM is a stable alternative:

LVM separates logical volumes from physical disks, making expansion and LV snapshots (if needed) easier.
ext4 is a battle-tested filesystem with mature recovery tools (e2fsck).

What you lose compared to ZFS: end-to-end checksums (rely on PBS checksums), and ZFS-based immutable snapshots. For anti-ransomware protection in this scenario, rely on off-site sync and the firewall.

LV and filesystem for the datastore

lvcreate -L 1T -n pbs-data vg1
mkfs.ext4 /dev/vg1/pbs-data
mount /dev/vg1/pbs-data /var/lib/proxmox-backup/datastore/store1

#ext4 Notes

Use the noatime mount option to reduce metadata writes.
Monitor df and inodes (df -i) — PBS chunks are numerous; inodes can become the limit on small filesystems.
No native filesystem snapshots (besides the less practical LVM snapshots); rely on retention + sync.

#NFS/SMB: Network Storage

#Performance Cost

A datastore on NFS or SMB is legal and supported — for example to take advantage of an existing NAS/array. But there are real costs:

Latency: every chunk write crosses the network; heavy dedup reads of metadata can feel slow.
Bandwidth: network storage shares the link with other traffic; a backup burst can saturate the NIC.
Dependency: PBS will not work if the mount drops — make sure the mount is persistent and monitored.

For serious production, 10G network storage and a separate network (episode 13) are a reasonable minimum. For lab needs or small environments, NFS on a 1G link is enough.

Mount NFS for the datastore

mount -t nfs 10.0.20.5:/backup /mnt/pbs-nfs

#Calculating Capacity

Storage capacity is calculated from the actual data after dedup and compression, not the raw backup size:

Capacity estimation formula

Capacity ≈ (Total Data × RPO window snapshots)
            ÷ Dedup Ratio ÷ Compression Ratio

Example: 4 TB of VM data, dedup ratio 5x, compression 2x, full 30-day retention:

Add a 20-30% margin for metadata, GC watermark, and ZFS snapshots. The most accurate way: measure the Original vs Dedup vs Compressed metrics in your datastore (episode 6) after a few days of running, then project.

Tip

Project capacity from your datastore's real ratios, not guesses: after a week of backups, take the Dedup and Compressed numbers from the PBS web UI and multiply by your data growth projection. That is far more accurate than a theoretical formula.

#Closing

Key takeaways:

ZFS is the primary choice: built-in compression, snapshots, and checksums.
recordsize=1M is a mandatory best practice for PBS datastores on ZFS.
Enable ZFS or PBS compression, not both.
ext4 + LVM is stable for environments without ZFS; monitor inodes and rely on sync for redundancy.
NFS/SMB can be used at the cost of latency and bandwidth; network storage needs 10G and a separate network for production.
Calculate capacity from real dedup/compression ratios plus a 20-30% margin.

In the next episode, episode 16, we will face the hard times: troubleshooting & recovery — reading detailed task logs, using proxmox-backup-manager commands, handling common cases like full disks, GC races, and fingerprint mismatch, and recovering a datastore to a new server via sync/import with thorough recovery testing. Being on standby does not mean problems never happen!