Backing up a Proxmox Backup Server is trickier than it looks. I set up PBS as a VM myself and hit the same problems others do. A snapshot of the PBS VM while it is actively writing backups can give you a corrupt or inconsistent copy of the backup metadata. That wrecks restores. Treat PBS differently from the VMs it protects. Plan snapshot management around that reality.
Start by assessing your backup environment. Confirm where the PBS datastores live, and who mounts them. If datastores sit on TrueNAS and are exported as NFS shares, keep them outside the Proxmox storage stack used by the VMs you back up. Avoid including the PBS VM in backup jobs that target those same datastores. Look at each backup job and note whether it writes to or reads from the datastore during the snapshot window. Pick a backup cadence that separates heavy PBS activity from VM snapshot windows. Example: run large retention maintenance and pruning on PBS overnight, and schedule virtual machine backups in a quieter window so snapshots do not overlap peak PBS IO.
When creating consistent backups, do not rely on a single VM snapshot of the PBS server to be a reliable recovery method for the entire backup system. Snapshotting a running PBS VM risks missing in-flight metadata or chunks. Instead, protect three things separately: the datastore contents (on NFS shares or external storage), the PBS configuration and keys, and any external metadata (for example, certificate files, user keys and storage configuration). For configuration and metadata I keep a small, scripted export that runs before major changes. That script copies /etc/proxmox-backup or the relevant config paths and the PBS keyring to another host or to a different datastore that is not subject to the same snapshot strategy. If you must back up the PBS VM image, pause PBS or stop the backup service first, then snapshot. That gives a cleaner state, but it costs downtime.
Monitor snapshot performance closely. Watch PBS job logs for retries, slow chunk uploads, or failed pruning. Track datastore free space and chunk index size; deduplication saves space but still needs headroom. If NFS shares are in use, check mount performance and NFS server load. I use simple metrics: queue length, IO wait, and job completion time. If vm backup jobs suddenly take much longer when PBS is running, stagger schedules or move datastores to a less loaded NFS target. Real examples: move large nightly backups off-peak, or point the PBS datastore at a dedicated TrueNAS dataset with its own network and NIC to reduce contention.
Protect metadata and configuration deliberately. Export PBS server keys and config regularly and store them outside the datastore on a different host or device. Keep the Proxmox Backup Server on a different failure domain than the datastores. Running PBS on a dedicated host removes many edge cases. In my setup I run PBS on a small physical host and use a TrueNAS box for datastore NFS shares. That separates compute, backup control and storage. If you cannot run a dedicated host, place datastores on external storage that the hypervisor can access but the PBS VM does not rely on locally. That reduces the chance of snapshot loops and accidental inclusion of the datastore in a VM image backup.
Concrete takeaways. Do not treat PBS like a normal VM. Keep datastores on external NFS shares and avoid backing up the PBS VM while it is active. Export and store configuration and keys separately. Stagger heavy PBS maintenance and VM backup jobs so snapshots do not overlap peak IO. Where practical, run PBS on a dedicated host or isolate its storage and network. Follow those steps and snapshot management stops being a source of silent corruption and becomes a predictable part of the backup workflow.
