Backup Strategy for SMBs: Proxmox PBS + TrueNAS as a Reliable Backup Solution

Most SMBs back up their data — few can actually restore it when disaster strikes. The combination of Proxmox Backup Server (PBS) as the primary backup target and TrueNAS as the replication destination delivers a complete 3-2-1 strategy built on open source. No license fees, no vendor lock-in — and with automated restore tests that prove the backups actually work.

Understanding the 3-2-1 Rule

The 3-2-1 rule is the foundation of every backup strategy:

• 3 copies of the data (original + 2 backups)
• 2 different media types (e.g., SSD + HDD, local + cloud)
• 1 copy offsite (physically separated from the production system)

In practice with Proxmox and TrueNAS:

Copy	Location	Media Type	Function
Original	Proxmox VE (Ceph/local storage)	SSD/NVMe	Production data
Backup 1	Proxmox Backup Server (local)	HDD (ZFS pool)	Primary backup
Backup 2	TrueNAS (offsite or second location)	HDD (ZFS pool)	Offsite copy

PBS as Primary Backup Target

Why PBS?

Proxmox Backup Server is the native backup solution for Proxmox VE and offers decisive advantages over classic dump backups:

• Block-level incremental backups: Only changed data blocks are backed up
• Deduplication: Identical blocks across all VMs are stored only once
• Client-side encryption: AES-256-GCM, key never leaves the PVE host
• Verification: Automatic checksum validation of backup integrity

PBS Sizing for SMBs

The storage calculation for PBS accounts for deduplication:

Required PBS storage ≈ Total data × Dedup factor × Retention factor

Example for an SMB with 10 VMs (2 TB total usable data):

• Dedup factor: 0.4 (typical for similar VMs with the same OS)
• Retention: 30 daily + 12 monthly + 2 yearly backups
• Storage: 2 TB x 0.4 x 1.5 (retention overhead) = 1.2 TB on PBS

Without deduplication, the same backups would occupy approximately 8–10 TB.

PBS Storage Layout

For PBS, we recommend ZFS as the filesystem with the following configuration:

# PBS datastore: ZFS mirror of two HDDs
zpool create -o ashift=12 backup-pool mirror /dev/sda /dev/sdb

# Enable compression (saves 20-40% for VM backups)
zfs set compression=zstd backup-pool

# Create datastore directory
zfs create backup-pool/datastore1

Configuring Backup Jobs

In Proxmox VE under Datacenter > Backup > Add:

Schedule:       daily 02:00
Storage:        pbs-datastore1
Selection Mode: All (or specific VM IDs)
Mode:           Snapshot
Compression:    ZSTD
Encryption:     Enabled (store the key safely!)

Or via CLI:

# Backup job for all VMs at 02:00
pvesh create /cluster/backup \
  --schedule "02:00" \
  --storage pbs-datastore1 \
  --all 1 \
  --mode snapshot \
  --compress zstd \
  --mailnotification always \
  --mailto admin@example.com

Retention Policies

Retention defines how long backups are kept. A proven policy for SMBs:

Keep Daily:     14    # Last 14 days
Keep Weekly:    8     # Last 8 weeks
Keep Monthly:   12    # Last 12 months
Keep Yearly:    2     # Last 2 years

Configure retention per datastore on PBS:

# Set retention policy
proxmox-backup-manager datastore update datastore1 \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --keep-yearly 2

PBS applies retention automatically and removes older backups that no longer fit the schema. Thanks to deduplication, only chunks that are no longer referenced by any other backup are actually freed.

TrueNAS as Offsite Replication

Architecture

PBS stores backups locally. For the offsite copy, we replicate the PBS datastore to a TrueNAS system at a secondary location:

Proxmox VE → PBS (local) → TrueNAS (offsite)
   [Backup]     [Replication via PBS Sync / ZFS Send]

Option 1: PBS-to-PBS Sync (Remote Datastore)

PBS offers native sync jobs between two PBS instances:

# Configure remote PBS as sync target
proxmox-backup-manager remote add offsite-pbs \
  --host pbs-offsite.example.com \
  --auth-id sync@pbs \
  --fingerprint AB:CD:...

# Create sync job
proxmox-backup-manager sync-job create offsite-sync \
  --store datastore1 \
  --remote offsite-pbs \
  --remote-store datastore1 \
  --schedule "daily 06:00" \
  --remove-vanished true

Option 2: ZFS Replication to TrueNAS

If the PBS datastore runs on ZFS, you can replicate ZFS snapshots directly to TrueNAS:

# Create ZFS snapshot
zfs snapshot backup-pool/datastore1@daily-$(date +%Y%m%d)

# Replicate snapshot to TrueNAS
zfs send -i backup-pool/datastore1@daily-20260502 \
  backup-pool/datastore1@daily-20260503 | \
  ssh truenas.example.com zfs recv tank/pbs-replica/datastore1

Automate this with a cron job or use the TrueNAS replication feature:

1. TrueNAS > Data Protection > Replication Tasks > Add
2. Set up SSH key exchange between PBS and TrueNAS
3. Configure pull replication (TrueNAS pulls snapshots from PBS)

Option 3: PBS Datastore on TrueNAS iSCSI

PBS can operate its datastore on a TrueNAS iSCSI target. This places the backup physically on the TrueNAS:

# Create iSCSI target in TrueNAS
# Sharing > iSCSI > Targets > Add
# Extent: zvol with sufficient capacity

# On PBS: mount iSCSI target
iscsiadm -m discovery -t sendtargets -p truenas.example.com
iscsiadm -m session --login

# Create ZFS pool on the iSCSI device
zpool create -o ashift=12 pbs-remote /dev/sdb

Encryption: End-to-End

Client-Side Encryption in PBS

PBS encrypts backups with AES-256-GCM on the Proxmox VE host — before data leaves the server:

# Generate encryption key
proxmox-backup-client key create /etc/pve/priv/pbs-encryption-key.json

# Store key safely (create paper key)
proxmox-backup-client key paperkey /etc/pve/priv/pbs-encryption-key.json

Critical: Without the key, encrypted backups cannot be restored. Store the paper key in a physically secure location (safe, bank vault).

Encryption of the Offsite Replication

Since backups are already encrypted client-side, the offsite copy is automatically encrypted. Additionally, secure the transport:

• PBS-to-PBS sync: Uses TLS (HTTPS) — already encrypted
• ZFS send over SSH: SSH-encrypted transport
• iSCSI: Enable iSER or IPsec for transport

Automating Restore Tests

A backup that has never been tested is not a backup — it is a hope. Automated restore tests regularly prove that recovery works.

PBS Verify Jobs

PBS automatically checks the integrity of backup chunks:

# Create verify job (checks all backups weekly)
proxmox-backup-manager verify-job create weekly-verify \
  --store datastore1 \
  --schedule "weekly sat 04:00" \
  --outdated-after 30

Automated Restore Test Script

A full test restores a VM from backup, checks whether it boots, and deletes it:

#!/bin/bash
# restore-test.sh — Automated restore test

VM_ID=999          # Temporary VM ID for test
BACKUP_VM=100      # Original VM to test
PBS_STORE="pbs-datastore1"
TEST_STORAGE="local-lvm"

# Find latest backup version
BACKUP=$(pvesh get /nodes/$(hostname)/storage/$PBS_STORE/content \
  --vmid $BACKUP_VM | jq -r '.[0].volid')

# Restore VM from backup
qmrestore $BACKUP $VM_ID --storage $TEST_STORAGE --unique true

# Start VM and wait 120 seconds
qm start $VM_ID
sleep 120

# Check if VM is running
STATUS=$(qm status $VM_ID | awk '{print $2}')
if [ "$STATUS" = "running" ]; then
    echo "RESTORE TEST PASSED: VM $BACKUP_VM boots successfully from backup"
    RESULT="PASS"
else
    echo "RESTORE TEST FAILED: VM $BACKUP_VM did not boot from backup"
    RESULT="FAIL"
fi

# Clean up test VM
qm stop $VM_ID --timeout 30
qm destroy $VM_ID --purge

# Send result via email
echo "Restore Test $RESULT for VM $BACKUP_VM at $(date)" | \
  mail -s "Restore Test $RESULT" admin@example.com

Run this test weekly via cron:

# Weekly restore test (Sunday 05:00)
0 5 * * 0 /usr/local/bin/restore-test.sh >> /var/log/restore-test.log 2>&1

Cost Comparison: Open Source vs. Commercial

Criterion	PBS + TrueNAS	Veeam Backup & Replication	Commvault
License cost	EUR 0	from EUR 400/socket/year	from EUR 2,000/TB/year
10 VMs, 5 years	EUR 0	~EUR 4,000	~EUR 10,000+
Deduplication	Yes (PBS)	Yes	Yes
Encryption	Client-side (AES-256)	AES-256	AES-256
Offsite replication	PBS Sync / ZFS Send	WAN Accelerator	Yes
Bare-metal restore	No (VM-focused)	Yes	Yes
Support	Community / Proxmox subscription	Commercial	Commercial
Complexity	Low	Medium	High

For SMBs using Proxmox VE as their hypervisor, PBS is the most economically sensible solution. The saved license costs can be invested in better hardware — larger backup pools, faster network connectivity, or redundant offsite locations.

Monitoring and Reporting

Keeping Track of Backup Status

Monitor backup status using these methods:

# Show VMs not yet backed up
pvesh get /cluster/backup-info/not-backed-up

# PBS garbage collection status
proxmox-backup-manager gc-job status datastore1

# Datastore utilization
proxmox-backup-manager datastore list

Integration with Monitoring Systems

PBS exposes metrics through its API:

# Query datastore usage via API
curl -s "https://pbs.example.com:8007/api2/json/admin/datastore/datastore1/status" \
  -H "Authorization: PBSAPIToken=monitor@pbs!token:UUID" | jq

Integrate these checks into Checkmk, Zabbix, or DATAZONE Control for comprehensive backup monitoring.

Weekly Backup Report

Create an automated report covering the following:

1. Success rate: How many backup jobs succeeded?
2. Failed backups: Which VMs were not backed up?
3. Storage utilization: How full is the PBS datastore?
4. Replication status: Is the offsite copy current?
5. Restore test result: Did the latest restore test pass?

Disaster Recovery Runbook

Document the recovery process in a runbook:

1. Assessment: Which systems are affected? What is their priority?
2. PBS access: Is PBS reachable? If not, access the offsite copy (TrueNAS)
3. Restore order: Domain Controller, Database Server, Application Server, Workstations
4. Network: Document IP addresses and VLANs for emergency operations
5. Validation: Verify each restored service for correct function
6. Communication: Inform stakeholders about status and timeline

Conclusion

The combination of Proxmox PBS and TrueNAS delivers a complete 3-2-1 backup strategy without license costs. PBS ensures efficient, deduplicated, and encrypted backups, while TrueNAS provides the offsite copy. The decisive difference between a backup concept and a real backup strategy lies in regular restore tests — only when recovery is proven can you truly feel secure.