For an offsite PBS copy, use a second server with its own datastore and a deliberate sync direction. This example has the offsite PBS pull one VM group from the primary, with Remove vanished disabled and independent destination retention. Prove the copy by restoring from offsite while the primary is unavailable to the recovery host.
Sync gives you another copy of selected backups. Whether it survives a building failure, stolen credentials or an unwanted deletion depends on placement, access and retention. Describe those boundaries before calling it disaster recovery.
Validation: documentation-based guide, researched November 10, 2026 against PBS manuals labeled 4.2.9-1. No sync, permission test, deletion drill or restore has been run. This recipe uses pull; push and sync-side encryption need their own configuration review.
Fix the direction and scope on paper
| Setting | Example |
|---|---|
| Primary | pbs-primary.example.com, datastore lab-backups |
| Offsite | pbs-offsite.example.com, separate datastore offsite-copy |
| Job location | Offsite PBS |
| Remote definition on offsite | primary-lab, pointing to the primary |
| Direction | Pull: offsite initiates; backup data travels primary → offsite |
| Namespaces | Root → root; recursion depth 0 |
| Group filter | Include group:vm/201 only |
| Deletion policy | Remove vanished off; destination prune managed separately |
The hostnames are documentation examples. Use a private authenticated network path appropriate to your sites and verify its recovery dependencies. Capacity, power and administration of the second datastore must also survive the failure you are planning for. A second datastore on the same failed disks cannot help.
Separate the three identities
On the primary, create a dedicated identity that can read the source scope.
A scoped DatastoreReader role is a starting point; with a token, check both
the parent user’s and token’s ACLs. A routine backup credential may only read
groups it owns. See PBS access control.
On offsite, create the remote definition with that source credential and the independently checked primary certificate fingerprint. It should not need primary administrative access. Keep the offsite administrator’s credential out of the primary PVE host and primary PBS configuration for this design.
The local job owner is a third identity: it needs access to the remote definition and permission to write the destination. The sync permission rules distinguish these local permissions from the credential used on the source. Set and record the intended owner rather than relying on an unexplained default. Test effective access; a GUI form accepting an identity does not prove it can read the chosen group.
Configure one manual pull before scheduling
On offsite, add a datastore sync job using the table’s values. Inspect the saved direction, source and destination namespace, depth, group filter and owner. Leave Remove vanished off explicitly. With no group filter, the scope can be broader than the single VM intended here.
Run the job manually and examine the task log, then inspect the destination content. Record the exact snapshot present at each end. A successful job that finds no selected snapshots is not evidence that VM 201 has an offsite copy. Choose bandwidth and timing from measured conditions after this first test. Never invent a throughput or completion window from the WAN link speed.
Then add a schedule with a named time zone. Allow for the backup finishing before sync starts, and alert on a stale destination recovery point as well as explicit task failures. Job frequency alone is not a measured data-loss bound: a successful source backup still needs a completed sync.
Decide which deletions the second copy should survive
Keep Remove vanished off for this design. Source disappearance then is not an instruction from this job to remove the destination copy. That does not make the destination immutable: local prune rules or an offsite administrator can still remove snapshots.
Build destination retention around the required recovery history and capacity, not merely the source’s settings. Check the local protected state separately; the source snapshot’s protected flag is not carried across by sync. Use the retention and GC guide for the distinction between pruning snapshots and reclaiming chunks.
Test deletion behavior only with a disposable group and two expendable snapshots after checking destination retention. Compare the expected surviving timestamps before and after the sync. Do not use the only recovery copy for this rehearsal.
Restore while the primary is unavailable
On a recovery PVE host, add the offsite datastore directly using separate recovery access and the correct encryption key where required. Make the primary unreachable from that recovery host in the isolated test environment; do not interrupt a working production backup service.
Restore one selected offsite snapshot to an unused VM ID with startup disabled. Isolate NICs before boot and check a known application record. Record the destination snapshot time, key source, dependencies, task results and application result. A source verify flag or sync task cannot substitute for this test. Use the VM restore runbook to record each acceptance gate through to the application check.
If recovery works only while the primary is available, find the hidden dependency: credentials, DNS, keys, identity service or an external database. Move or document that dependency before accepting the offsite plan.