Sync jobs — mirroring backups to a second PBS

Sync jobs mirror backups from one PBS to another — complete, incremental and in the background. That gives you a second copy at a different location and cuts the single-point-of-failure risk considerably.

When sync jobs make sense

• You want your backups at home too: your xaweho PBS holds all backups, a second PBS in your cabinet fetches them as well.
• You want to mirror backups between two xaweho locations: PBS in Nuremberg syncs to PBS in Falkenstein. Open a ticket — we can set that up.
• You want protection against logical errors: if your PBS prunes accidentally deleted snapshots and GC runs, they’re gone. A second PBS with its own (slower) retention keeps the backups longer.

Sync jobs run PBS-to-PBS, not PBS-to-other-storage. You need another PBS on the target side — either your own, or a second plan with us.

Requirements

• Source PBS: that’s your existing PBS at xaweho.
• Target PBS: must be able to reach the source PBS over the network. The sync job runs on the target and pulls from the source.
• API token or user login on the source PBS for the pull.

Step 1 — create an API token on the source PBS

On the source PBS (i.e. with us):

1. Configuration → Access Control → API Token → Add.
2. Pick any token ID, e.g. sync-target-home.
3. Permissions: read/write only your own datastore.
4. Note down the token secret — it is shown once, never again after that.

The token ID has the format <user>!<token-name>, e.g. 12345@pbs!sync-target-home.

Step 2 — set up the remote on the target PBS

On the target PBS:

1. Configuration → Remotes → Add.
2. Fields:
   • Remote ID: anything you like, e.g. xaweho-pbs01.
   • Host: address of the source PBS, e.g. pbs01.xaweho.de.
   • Port: 8007.
   • User ID: the token ID from step 1, e.g. 12345@pbs!sync-target-home.
   • Password: the token secret from step 1.
   • Fingerprint: fingerprint of the source PBS (you’ll find it in PBS under Configuration → Certificates).
3. Save.

Step 3 — create the sync job

On the target PBS:

1. Datastore → <your-target-datastore> → Sync Jobs → Add.
2. Fields:
   • Source: select the remote you just created.
   • Source Datastore: <your-customer-number> (datastore name on the source).
   • Owner: leave empty (default).
   • Schedule: e.g. 04:00 — nightly, after our backup jobs.
   • Remove vanished: enabled if you want snapshots deleted on the target that no longer exist on the source.
   • Group filter: leave empty, or restrict to specific VMs.
3. Save.

The first run copies everything — depending on the data volume, that can take several hours to days. Subsequent runs are incremental, only new snapshots are transferred.

Testing the sync job

Don’t wait for the schedule:

1. On the target PBS: Datastore → Sync Jobs → select the job → Run now.

In the task log you can watch it pulling snapshots from the source:

INFO: Starting datastore sync job
INFO: Sync snapshot vm/100/2026-05-08T02:00:00Z
INFO: chunks: 4523 / 4523 (100%)
INFO: Sync of 'vm/100/...' done

Sync jobs as pull or push?

Both work. Classically, PBS does pull — the target fetches from the source, as described in this guide. Since PBS 3.3 there are also sync jobs in push direction: the source actively sends to the target.

For the ransomware scenario, we still recommend pull. The reason: with pull, the source doesn’t know the target — if the source gets hacked, the attacker can’t manipulate the target. With push, the target credentials sit on the source, and those are exactly what you don’t want to hand an attacker.

Sync jobs combined with append-only

For disaster-recovery-grade setups: the target datastore is Verify only or has strict permissions that allow only sync pulls — nothing can be deleted, not even by a compromised source. More on this in append-only mode.

Frequently asked questions

Can the sync job run in parallel with the backup job? Yes. The backup on the PVE writes to the source, the sync job on the target pulls in parallel. The source handles both at the same time.

What happens when a snapshot gets pruned on the source? With Remove vanished: enabled, it gets deleted on the target at the next sync too. With Remove vanished: disabled, it stays on the target — so you can use the target as a long-term archive with a longer retention than the source.

Can I restore from a sync pull on the source PBS? No. A restore always runs from the PBS that holds the datastore. So you restore either from the source or from the target — depending on where your PVE has the storage mounted.

How much bandwidth does a sync job need? Incrementally, very little — only the new chunks. A full sync (first run) needs as much as the datastore is large. On a 1 Gbit connection, roughly 10 GB per minute.

Can I sync several sources to one target? Yes. One sync job per source. Handy for example if you want to consolidate several locations or customers onto one central backup hub.

What if the target PBS fails mid-sync? The next run continues from the point where it broke off. PBS is crash-safe.

Can I configure sync jobs on the source instead of the target? Yes, since PBS 3.3 as a push sync — you need credentials with write access on the target for that. Handy if you have no configuration access on the target. For ransomware protection, pull remains the better choice: the source shouldn’t know the target.

What’s next

• Append-only mode — protection against ransomware
• Multiple Proxmox VE hosts on one datastore
• Performance tuning for slow backups