Learn Proxmox Backup Server - Ecosystem Integration: Veeam, Bacula & Cloud

#Introduction

The hub-spoke architecture of episode 18 handles PBS-to-PBS. But the backup ecosystem is wider than that: you may still have non-Proxmox physical servers, or commercial backup suites, that need a storage destination in the same place. Episode 19 bridges PBS to other ecosystems: PBS as an NFS/SMB target for Veeam and Bacula, plus S3 object storage in PBS 4.x for cloud off-site.

The analogy is like a central archive warehouse serving many couriers: PBS still manages its own shelves with its own chunk format, but provides a standard entrance (NFS/SMB) so other couriers — Veeam, Bacula — can drop off their own archive boxes in the same warehouse.

#PBS as a Target for Other Backup Agents

#The Concept: An NFS/SMB Door on the Datastore Side

PBS stores VM/CT backups in its own chunk format — that data cannot be read directly by Veeam/Bacula. What can be shared is the filesystem where the datastore lives. The correct pattern:

1. Export a separate directory (not the PBS datastore chunk directory) via NFS/SMB.
2. Veeam/Bacula use it as a regular file repository.
3. PBS and the other agents share the same disk capacity, without understanding each other's formats.

This practice centralizes storage in one place: PBS handles Proxmox VMs/CTs natively, Veeam/Bacula handles other workloads, and both write to the same machine.

#NFS Export on Top of ZFS

If the PBS datastore is on a ZFS pool, the easiest export is via sharenfs:

zfs set sharenfs="on" zpool-pbs/shared
zfs list -r zpool-pbs -o name,mountpoint,sharenfs

Check access from a client (e.g. the Veeam gateway server) with a normal mount:

mkdir -p /mnt/pbs-shared
mount -t nfs 10.0.1.5:/zpool-pbs/shared /mnt/pbs-shared

For SMB, install Samba on PBS and export the same directory. Note the performance caveat from episode 15: NFS/SMB paths have higher latency than local disks — measure throughput first before committing the share as a repository target.

#Veeam: NFS/SMB Repository

Veeam Backup & Replication supports NFS shares and CIFS/SMB shares as backup repositories. On the Veeam side:

• An NFS share requires a gateway server (Windows or Linux) with the NFS client package — this gateway is the "bridge" between Veeam and the share.
• Linux-based repositories in Veeam support hardened repositories (immutable) — a strong combination with the anti-ransomware concept from episode 14.
• For Proxmox environments, Veeam also provides the Veeam Plug-in for Proxmox VE — official integration making PVE a supported workload.

The benefit of using PBS as the share host: one machine, one maintenance cycle, one set of resources — PBS and Veeam coexist without an extra server.

#Bacula: File Storage on NFS

Bacula (an enterprise suite based on a director/storage architecture) writes backups to File storage:

1. The Bacula Storage Daemon (SD) points its storage directory at the NFS mount above.
2. The Storage { Device = PBS-Shared } block in the Bacula configuration points to that path.
3. Bacula volumes are stored on the share, while PBS manages its own VMs/CTs.

The same pattern applies to Bacula Community and Enterprise (File/autochanger types). The Bacula configuration does not change — only the file location now lives on the PBS machine.

#Cloud: S3 Object Storage Off-site

#S3 Datastore in PBS 4.x

Episode 17 introduced the PBS 4.2 headline feature: datastore on top of S3-compatible object storage. This changes how off-site works: instead of a second PBS to maintain (episode 10), the cloud destination can be an object storage bucket.

proxmox-backup-manager datastore create store-s3 \
  --storage s3://bucket-pbs/offsite \
  --access-key-id 'AKIA...' \
  --secret-key '...'

Chunks, dedup, and snapshots work identically to a local datastore — PBS just writes to different "paper". Verify and GC schedules still apply.

#Architecture: Local → S3

The most sensible pattern: fast local backup, S3 as the off-site layer:

Fast local + cloud off-site

[PVE cluster] ──backup──> [Local PBS: ZFS]
                              │  daily sync
                              ▼
                       [S3 datastore: cloud]

This combination avoids two problems at once: S3 latency (not suitable for direct daily backups) and the burden of maintaining a second PBS. Syncing to S3 creates an automatic off-site copy — the "1" layer of the 3-2-1 strategy (episode 10).

#Object Lock & Encryption

Two security layers that can be combined:

• S3 Object Lock (compliance/governance modes): objects in the bucket cannot be deleted/overwritten for a specified period — an immutable anti-ransomware form for the cloud (episode 14).
• Client-side encryption (episode 7): if the original backup is encrypted, the ciphertext synced to S3 remains unreadable to anyone accessing the bucket.

#Closing

Key takeaways:

• A PBS datastore cannot be read by other agents; what is shared is its filesystem via NFS/SMB.
• Set up a separate export directory from the chunk directory; zfs set sharenfs makes ZFS exports easy.
• Veeam uses NFS/SMB repositories with a gateway server; the official Proxmox VE plug-in is available.
• Bacula writes to File storage on an NFS/SMB mount on the PBS machine.
• PBS 4.x: an S3 datastore for cloud off-site; the "fast local + sync to S3" combination replaces a second PBS.
• Combine S3 Object Lock with client-side encryption for an immutable layer in the cloud.

In the next episode, episode 20, we will measure and monitor: monitoring PBS via the API, InfluxDB/Prometheus, and Zabbix, plus performance tuning — chunk size, zstd compression, and io-threads — so backups are fast and their health is tracked. From "it works" to "it is measured"!