How to Add Datastores in Proxmox Backup Server: SMB/Samba, NFS, and ZFS Configuration

The datastore is the core unit of storage in Proxmox Backup Server. Everything in PBS, like deduplication, incremental backup, verification, garbage collection, and retention operates on a datastore. Getting datastore configuration right determines whether PBS delivers its promised storage efficiency or quietly underperforms. Getting it wrong leads to permission failures, missed backup windows, and storage that fills faster than expected.

This guide covers how to add datastores in Proxmox Backup Server across the three main storage backends: locally attached ZFS (best performance), NFS-mounted shares (flexible but with performance caveats), and Proxmox Backup Server to Samba via SMB/CIFS (most common in Windows-adjacent environments). We compare all three, walk through Proxmox backup server add datastore configuration for each, and flag the failure points that catch teams off guard.

See how Zmanda Pro simplifies this

What Is a PBS Datastore and Why It Matters

A PBS datastore is a directory-backed storage location where PBS stores backup data as chunks. Unlike traditional backup formats that write monolithic backup files, PBS breaks VM disk data into variable-sized chunks, deduplicates them within the datastore, and stores the result as a content-addressed chunk store on the filesystem.

The chunk store lives on whatever filesystem path you specify when creating the datastore. PBS does not care whether that path is on locally-attached storage or a network mount, but the underlying storage type has a significant impact on backup performance, chunk operation speed, and reliability. The three common backends are local ZFS, NFS, and SMB/Samba.

PBS Datastore Backend Comparison: Local ZFS vs NFS vs SMB/Samba

Attribute	Local ZFS	NFS	SMB / Samba
Performance	Best — no network latency for chunk I/O	Good on 10 GbE; limited on 1 GbE	Moderate — SMB overhead higher than NFS for small files
Data integrity	Best — ZFS checksums detect silent corruption	Depends on NAS filesystem	Depends on SMB server filesystem
Setup complexity	Low — ZFS pool + PBS datastore path	Medium — NFS export config + mount	Medium-High — credentials, mount, permissions
Best use case	Primary PBS datastore; production environments	PBS datastore on existing NAS capacity	Environments with existing Windows/Samba file servers
Deduplication efficiency	Full PBS dedup performance	Slightly reduced due to NFS latency	Reduced — SMB small-file overhead impacts chunk operations
PBS natively supports?	Yes — direct path	Via OS mount (not native PBS feature)	Via OS mount (not native PBS feature)

Option 1: Add a PBS Datastore on Local ZFS (Recommended)

Locally-attached ZFS is the recommended storage backend for PBS. It eliminates network latency from chunk I/O, provides ZFS data integrity checksums that catch silent disk corruption before it propagates into backups, and allows ZFS RAIDZ for drive redundancy without a hardware RAID controller.

Create the ZFS Pool

If your backup disks are not yet in a ZFS pool, create one. For two drives (basic mirror):

zpool create backup-pool mirror /dev/sdb /dev/sdc

For RAIDZ2 across four drives (recommended for production, tolerates two simultaneous drive failures):

zpool create backup-pool raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

Create a dataset for PBS datastore use:

zfs create backup-pool/pbs-datastore

Add the PBS Datastore

In the PBS web UI, navigate to Administration → Datastore → Add Datastore. Set the path to /backup-pool/pbs-datastore. PBS creates its chunk directory structure at this path. After creation, configure a prune job and a GC job under the datastore settings before running any backup jobs.

Option 2: Add a PBS Datastore on NFS

For teams with existing NAS capacity (Synology, TrueNAS, QNAP), pointing a PBS datastore at an NFS-mounted path is a cost-effective way to leverage that storage for PBS incremental backup. PBS itself treats the NFS mount as a local path, the mount must exist and be accessible before PBS can use it as a datastore.

Mount the NFS Share on PBS

mkdir -p /mnt/nfs-backup
mount -t nfs [NAS-IP]:/volume1/pbs-datastore /mnt/nfs-backup

Add to /etc/fstab for persistence (the _netdev flag ensures mounting waits for the network):

[NAS-IP]:/volume1/pbs-datastore  /mnt/nfs-backup  nfs  defaults,_netdev  0  0

Verify the mount: df -h /mnt/nfs-backup

Add the Datastore in PBS

In PBS: Administration → Datastore → Add Datastore. Set the path to /mnt/nfs-backup. The NFS export must have root squash disabled for the PBS server’s IP, root squash maps root to nobody and prevents PBS from creating its chunk directory structure and writing backup data. This is the single most common NFS datastore failure cause.

Option 3: Proxmox Backup Server to Samba (SMB/CIFS)

The Proxmox backup server to Samba setup follows the same OS-mount-then-PBS-datastore pattern as NFS Samba/SMB shares are not a native PBS storage type, but PBS will happily use a mounted SMB share as a datastore path once it is mounted on the PBS host filesystem.

Install CIFS Utilities and Mount the Share

apt install cifs-utils -y
mkdir -p /mnt/smb-backup

Create a credentials file to avoid embedding passwords in fstab:

echo "username=backup-user" > /etc/pbs-smb-credentials
echo "password=yourpassword" >> /etc/pbs-smb-credentials
chmod 600 /etc/pbs-smb-credentials

Mount the share:

mount -t cifs //[SERVER-IP]/backup-share /mnt/smb-backup 
  -o credentials=/etc/pbs-smb-credentials,uid=0,gid=0,dir_mode=0755,file_mode=0644

For persistence in /etc/fstab:

//[SERVER-IP]/backup-share  /mnt/smb-backup  cifs  credentials=/etc/pbs-smb-credentials,uid=0,gid=0,dir_mode=0755,file_mode=0644,_netdev  0  0

The uid=0,gid=0 options ensure the root user (which PBS runs as) has full ownership of the mount. Without these, PBS cannot create the chunk directory structure and datastore initialization fails.

Add the Datastore in PBS

Once the SMB share is mounted and accessible, add the datastore in PBS: Administration → Datastore → Add Datastore → set path to /mnt/smb-backup. The remainder of the datastore configuration (prune jobs, GC jobs, retention settings) is identical to any other datastore.

Using CIFS Directly in Proxmox VE (vzdump to SMB. No PBS)

For teams backing up directly with vzdump rather than PBS, Proxmox VE supports CIFS/SMB as a native storage type, no OS-level mount required. In Proxmox VE: Datacenter → Storage → Add → SMB/CIFS. Fill in server, share, username, password, and select VZDump backup file as the content type. This mounts the share and makes it available as a vzdump backup target.

This approach is simpler than the PBS-to-SMB route but produces full backups only, no deduplication, no incremental. It is appropriate for small environments where simplicity outweighs storage efficiency.

PBS Datastore Configuration Best Practices

• Never use the PBS OS disk as a datastore path. Backup data filling the OS disk renders PBS inaccessible and causes all backup jobs to fail.
• Schedule prune and GC jobs before the first backup job runs. Without retention management from day one, storage accumulates without bound.
• For NFS and SMB mounts, test persistence across reboots. Missing _netdev in fstab causes mount failures at boot, which means PBS starts without the datastore, and backup jobs fail silently.
• Monitor datastore disk usage proactively. PBS will fail backup jobs when the datastore disk is full. Set a monitoring alert at 80% capacity.
• Set verify jobs on the datastore. PBS verify jobs validate chunk integrity without running a full restore. Schedule weekly at minimum.

For teams managing NFS and iSCSI backup across multiple Proxmox clusters, the per-cluster PBS datastore configuration model means each cluster requires its own configuration and monitoring. Zmanda Pro centralizes this across clusters with unified management, automated alerting, and policy enforcement, removing the need to maintain separate datastore configurations per cluster.

The full architecture options for Proxmox environments are covered in the Proxmox Backup Server complete guide.