Proxmox Backup Server (srv-pbs)

Off-host backups for rumba's guests: a PBS 4.2 VM running on the FS2500 under Synology Virtual Machine Manager, so a rumba failure (host, pool or upgrade gone wrong) cannot take the backups with it. Deployed 2026-08-03; the architecture decision and rejected alternatives (RDS2216, Active Backup, NFS datastore on rumba) are in the ops backups page.

Why PBS and not a plain NFS dump target

A vzdump job writing to an NFS share on the NAS would have been simpler — one share, no VM. What PBS buys over that, with this fleet's numbers (one nightly run ≈ 300 GB, 97 % of it the idle Learn-mirror VM 107):

• Deduplication — every vzdump archive is complete and independent, so a 14/8/6 schedule on NFS costs slots × 300 GB ≈ 8 TB and would not even fit the volume. PBS chunks are shared across snapshots: the same schedule costs ≈ one full copy + daily churn, ≈ 0.5 TB expected.
• Incremental nightly runs — vzdump re-reads and re-transfers every guest in full, every night. PBS tracks QEMU dirty bitmaps, so after the first pass a VM backup only reads and sends changed blocks — minutes instead of hours for VM 107. (Containers are still re-read, but only changed chunks are uploaded.)
• Granular restores — browse any snapshot and pull a single file from the PVE UI; live-restore boots a VM while it streams back. A vzdump archive restores whole or not at all.
• Scheduled verification — verify jobs re-checksum snapshots so bit rot is caught before restore day; an NFS directory of .zst files is write-and-hope.
• Blast-radius control — rumba authenticates with an API token that can back up and prune, not delete the datastore; with NFS, root on a compromised rumba can rm -rf its own safety net.
• Off-site is built in — the planned second copy is a PBS sync job pulling deduped chunks incrementally, not an rsync of terabytes of monolithic archives.

What plain NFS would have had going for it — fully portable, self-contained archives that restore on any PVE with no PBS in existence — is covered by the local 02:00 vzdump job on rumba (keep-daily=3): the two jobs are complementary, not redundant.

The VM (August 2026)

Fact	Value
Host	FS2500 VMM, storage on Volume 2 (/volume2, 6.7 TB)
Name / address	srv-pbs.calypso = 192.168.88.161 (static, baked in by the installer; DHCP lease + DNS pinned on the CCR2004)
Resources	2 vCPU, 3 GB RAM — sized for the stock 8 GB NAS; bump after the 16 GB DIMM arrives (~Aug 10)
Disks	sda 32 GB (system, ext4/LVM), sdb 5 TiB thin (datastore, grown from 2 TiB on 2026-08-04) — VMM exposes them as SATA
Web UI	https://srv-pbs.calypso:8007, root@pam (password in secretzone → rumba page)
SSH	key-based root@srv-pbs.calypso (pmudry's key, baked in by the answer file)
MAC	02:11:32:29:75:01 (the lease pin)

Install was unattended: proxmox-auto-install-assistant-prepared ISO, answer file on rumba at /root/pbs-answer.toml, ISO kept at rumba:/hdd/backup/template/iso/pbs-4.2-auto.iso. ⚠ That ISO embeds the PBS root password and SSH key — treat it like the secretzone.

Datastore and retention

• Datastore rumba on the 5 TiB disk (/mnt/datastore/rumba).
• Retention lives PBS-side: prune job daily-rumba keeps 14 daily / 8 weekly / 6 monthly (≈ a half-year window, widened 2026-08-04 once Volume 2 was dedicated to PBS); garbage collection runs daily. The PVE job carries no retention of its own.
• Verify job weekly-rumba re-checksums snapshots Saturdays 06:00 (outdated-after 30 days).
• Sizing: dedup means the whole 28-slot schedule costs ≈ one full copy (~300 GB compressed, 97 % of it VM 107) plus daily deltas — expect ≈ 0.5 TB steady state in the 5 TiB disk. Growing the vdisk again: resize in VMM (VM off), then sgdisk -e /dev/sdb; sgdisk -d 1 -n 1:0:0 -t 1:8300 /dev/sdb; partx -u /dev/sdb; resize2fs /dev/sdb1 (no parted/partprobe on PBS).

How rumba uses it

• PVE storage pbs-fs2500 (type pbs), auth rumba@pbs!pve API token (secret in secretzone → rumba page).
• Nightly job at 03:00, all guests, snapshot mode — one hour after the local 02:00 vzdump to hdd-backup, which stays as the fast on-host copy with keep-daily=3 (the local pool cannot hold more: 14 × ~300 GB ≈ 4.2 TB against ~1.9 TB effective).
• First test backup (CT 108) verified 2026-08-04.

PBS API tokens are permission-separated

A token's effective rights are the intersection of its own ACLs and its user's. Granting DatastoreBackup to rumba@pbs!pve alone leaves the datastore invisible ("Cannot find datastore") — the same ACLs must also be granted to the user rumba@pbs.

VMM's public API silently ignores ISO parameters

SYNO.Virtualization.API.Guest create/set accept iso_ids and answer success: true without mounting anything. Mount install media through the VMM UI (Edit → Others → ISO file for bootup) and verify with the qemu command line, not the API response. Same family of trap: VMM vdisks attach as SATA (sda), so Proxmox answer files must not assume vda.

Future

Off-site stays open: the target architecture adds a second PBS that pulls a sync job from this instance (ops backups). A PBS on a future cluster node is fine as that second copy, never as the primary — a backup server must live outside the failure domain it protects. Open items: ops todo → NAS.