Backing up a Proxmox Backup Server is awkward. I set PBS up as a VM myself and ran into the same issue everyone else does: snapshot the VM while it is writing backups and you can end up with inconsistent metadata. That can break restores. PBS needs to be handled differently from the VMs it protects.
Start by looking at the backup layout. Check where the PBS datastores live and what mounts them. If the datastores sit on TrueNAS and are exported as NFS shares, keep them outside the Proxmox storage stack used by the VMs you are backing up. Do not include the PBS VM in backup jobs that hit those same datastores. Check each job and see whether it is reading from or writing to the datastore during the snapshot window. Then set a cadence that keeps heavy PBS activity away from VM snapshots. For example, run pruning and retention work overnight, and keep VM backups in a quieter window so the jobs do not overlap peak IO.
Do not treat a single snapshot of the PBS VM as a safe recovery method for the whole backup system. A running PBS VM can miss in-flight metadata or chunks. Keep three things separate: the datastore contents, the PBS configuration and keys, and any external metadata such as certificate files, user keys, and storage configuration. For config and metadata, I keep a small scripted export that runs before major changes. It copies /etc/proxmox-backup or the relevant config paths and the PBS keyring to another host or to a different datastore that is not part of the same snapshot setup. If you have to back up the PBS VM image, stop PBS first, then take the snapshot. That gives a cleaner state, but it means downtime.
Watch snapshot performance closely. Read the PBS job logs for retries, slow chunk uploads, or failed pruning. Keep an eye on datastore free space and chunk index size. Deduplication saves space, but it still needs headroom. If you use NFS shares, check mount performance and NFS server load. I use simple checks: queue length, IO wait, and job completion time. If VM backup jobs suddenly slow down while PBS is busy, stagger the schedules or move the datastores to a less loaded NFS target. Moving large nightly backups off-peak or pointing the PBS datastore at a dedicated TrueNAS dataset with its own network and NIC cuts contention.
Protect metadata and configuration on purpose. Export PBS server keys and config regularly and keep them outside the datastore on another host or device. Put Proxmox Backup Server on a different failure domain from the datastores. A dedicated host removes a lot of edge cases. In my setup I run PBS on a small physical host and use a TrueNAS box for datastore NFS shares. That keeps compute, backup control, and storage apart. If you cannot run a dedicated host, place the datastores on external storage that the hypervisor can reach but the PBS VM does not depend on locally. That lowers the chance of snapshot loops and stops the datastore getting dragged into a VM image backup by accident.
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 configuration and keys separately. Stagger PBS maintenance and VM backup jobs so snapshots do not overlap peak IO. If you can, run PBS on a dedicated host or isolate its storage and network. That keeps snapshot management from turning into silent corruption.
