PBS Sync Jobs: Offsite Backup to a Second Proxmox Backup Server

Anyone running Proxmox VE in production knows the mantra: one backup is no backup. A backup only becomes worth something once it sits in a second, physically separate location. This is exactly what Proxmox built into Proxmox Backup Server (PBS) with so-called sync jobs — a PBS-native datastore-to-datastore replication mechanism between two PBS instances.

In this article we show you how to set up a sync job between a PBS at your main site and a second PBS in a data center, a branch office or at a managing director’s home network. We cover API tokens, encryption, bandwidth limiting and group filters — and explain why this approach is clearly superior to a classic rsync-based setup.

Why PBS sync instead of rsync?

It is tempting to simply rsync a PBS datastore onto a second piece of storage. Technically that works — but you lose exactly those properties that make PBS attractive in the first place:

Property	rsync on the datastore directory	PBS sync job
Deduplication during transfer	no, chunks are copied raw	yes, only missing chunks
Incremental on chunk level	no, file-based	yes, content-addressed
Chunk signature verification	no	yes, SHA-256 verified
Encryption pass-through	file-level only	yes, client encryption is preserved
Retention control at the target	manual	per prune job per namespace
Consistency during running backups	risky	yes, snapshots are transferred atomically
Resume after abort	limited	yes, chunk-precise

On top of that: PBS does not store VM disks as monolithic files but as a collection of 4 MiB chunks under /.chunks/. An rsync over several million tiny files is not only slow, it also puts significant load on the metadata subsystem of the source file system. Sync jobs read the datastore via the PBS API and only transfer those chunks that are actually missing on the target datastore.

Requirements and architecture

For a clean offsite setup you need:

• Two PBS instances, at least version 3.4 (as of 2026). PBS 4.x with the current sync-job push/pull model is recommended.
• Reachability on TCP 8007 from source to target PBS (or the other way around in push mode).
• A dedicated datastore at the target, ideally on a ZFS pool with compression enabled.
• Sufficient bandwidth — as a rule of thumb: the daily backup delta should be transferable in 6 to 8 hours.
• Optional: a VPN or a direct WireGuard connection if you do not want to expose the PBS directly to the internet.

Architecturally, we recommend pull mode: the target PBS actively pulls from the source PBS. This way only a single outbound port has to be open at the main site, and the target PBS at the offsite location is not reachable from the outside.

Create an API token on the source PBS

Sync jobs do not authenticate with username/password but with an API token. The advantage: you can revoke the token at any time without touching the actual user.

On the source PBS, create a new token under Configuration — Access Control — API Token. It is just as quick on the command line:

# Create dedicated sync user
proxmox-backup-manager user create sync@pbs --comment "Offsite Sync"

# Create token -- the secret is shown only once!
proxmox-backup-manager user generate-token sync@pbs offsite \
    --comment "Pull from offsite PBS"

# Permission: read-only on the source datastore
proxmox-backup-manager acl update /datastore/main \
    DatastoreReader \
    --auth-id 'sync@pbs!offsite'

Important: the DatastoreReader role is completely sufficient for a pull sync. You do not need to grant the token admin rights. Note down token ID (sync@pbs!offsite) and secret — the secret is stored encrypted in the remote entry on the target PBS.

Remote entry on the target PBS

On the target PBS you now register the source PBS under Configuration — Remotes. Pick a descriptive name like pbs-hq. Enter hostname/IP, port (default 8007), the token ID and the token secret. You can find the fingerprint of the server certificate on the source PBS with proxmox-backup-manager cert info.

On the CLI:

proxmox-backup-manager remote create pbs-hq \
    --host pbs.hq.example.com \
    --auth-id 'sync@pbs!offsite' \
    --password 'TOKEN-SECRET' \
    --fingerprint 'aa:bb:cc:...'

proxmox-backup-manager remote list shows whether the entry exists. A proxmox-backup-manager remote test pbs-hq confirms that the connection and the token work.

Configure the sync job — schedule, bandwidth, group filter

The actual sync job ties together remote, source datastore and target datastore. A realistic example for an SMB with three backup groups (vm/ct/host):

proxmox-backup-manager sync-job create offsite-nightly \
    --remote pbs-hq \
    --remote-store main \
    --store offsite \
    --schedule 'mon..fri 02:30' \
    --rate-in 50MiB \
    --group-filter 'type:vm' \
    --group-filter 'type:ct' \
    --remove-vanished false \
    --comment 'Nightly pull from HQ'

The most important options at a glance:

• --schedule takes the systemd calendar format. mon..fri 02:30 runs on weekdays at 02:30.
• --rate-in sets the bandwidth limit for the pull — 50 MiB/s here, roughly 400 Mbit/s. This keeps the WAN link free during the day.
• --group-filter restricts what gets synced. type:vm and type:ct exclude host backups, which are often uninteresting offsite.
• --remove-vanished false keeps snapshots on the target that have already been pruned at the source. This way you build a longer retention offsite than at the main site — classically 30 days HQ, 90 days offsite.

Encryption pass-through and retention at the target

A common misconception: if the VM backups are already client-encrypted on the source PBS (--keyfile on PVE), they remain so on the target. PBS transfers the chunks unchanged. The target PBS also only sees encrypted chunks — it has no access to the plaintext. That is exactly what you want for a GDPR-compliant offsite backup, for example when the second PBS sits at an external service provider.

You obviously have to back up the key separately — without it, the offsite backup is worthless in an emergency. A sealed envelope in a bank deposit box is the unromantic but working solution.

For retention on the target PBS, create a prune job per datastore that runs independently from the sync:

proxmox-backup-manager prune-job create offsite-prune \
    --store offsite \
    --schedule 'sun 04:00' \
    --keep-daily 14 \
    --keep-weekly 8 \
    --keep-monthly 12

This way you cleanly decouple the retention strategies of both sites from each other — a core advantage over rsync solutions where you laboriously maintain mirror images at the target. You can find more on clean backup concepts on our Backup service page.

Monitoring and practical tips

A sync job nobody monitors is Schroedinger’s backup. Three things you should wire up:

1. Enable e-mail notifications in /etc/proxmox-backup/node.cfg, at least at notify-error level. You want to know when nothing has run for three nights in a row.
2. A verification job on the target PBS that checks chunks against their SHA-256 weekly. Otherwise you only notice bit rot on the offsite storage during the restore.
3. A restore test at least quarterly: pull back a small test VM from the offsite PBS and boot it. Only then do you know that the entire chain — key, network, datastore, PVE — actually works.

In practice we see initial syncs of several terabytes at customer sites over VDSL links with 50 Mbit/s upload. Such an initial sync runs for several days, but thanks to chunk resume it also survives connection drops. If you want it faster: do the initial sync of the target PBS once at the main site and then physically move it to the offsite location — a classic “sneaker net” for the initial seeding.

Conclusion

With PBS sync jobs you get a robust, deduplicated, cryptographically signed offsite backup that classic rsync hacks cannot match. API tokens, group filters and independent prune jobs at the target make the setup manageable even for SMB environments — and in a disaster-recovery scenario you have a second, fully featured backup instance you can restore from directly.

DATAZONE supports you in designing and implementing your backup strategy — from sizing the PBS hardware over setting up the sync jobs to running disaster-recovery tests. Get in touch via Contact or learn more about our Proxmox consulting and our backup solutions.