Learn Proxmox Backup Server - Remote Sync & Off-site Backup

#Introduction

Verify in episode 9 ensures stored data is healthy — but one question remains unanswered: what happens if an entire location is lost? Fire, flood, or a ransomware attack that consumes local servers will also devour backups that live in only one place. Episode 10 answers this with remote sync & off-site backup.

Imagine it like duplicating archives to a warehouse in another city: the archive contents (snapshots) are copied to a separate location on a regular schedule, with the same recording system, so if the main warehouse burns down, the archive in the other city stays intact and can be retrieved at any time.

#Sync Jobs: Pulling Snapshots to a Remote PBS

#The Concept: Pull from the Remote Server

A PBS sync job is a pull operation: the destination PBS server (target) pulls snapshots from the source PBS server (remote). This model is safe because only the destination server needs to authenticate to the source — there is no inbound access path into the source network from outside.

The flow:

The destination server runs the sync job on schedule.
The destination server authenticates to the source server (user/token + TLS fingerprint).
Source snapshots are compared with what already exists on the destination.
New chunks are copied; old identical data is deduplicated automatically by the destination PBS.

Because the destination PBS also runs dedup, repeating snapshots from various sources does not add as much storage as the original sizes.

#Setting Up a User and Token on the Source

On the source server, create a dedicated sync user with an API token:

Create the sync user and token (on the source server)

proxmox-backup-manager user create sync@pbs --password 'sync-secret'
proxmox-backup-manager acl update /datastores/store1 sync@pbs DatastoreBackup
proxmox-backup-manager api-token create sync@pbs remote-sync --privsep

Note the generated token — tokens are only displayed once. These credentials are used by the destination server to read the source datastore.

#Creating the Sync Job

On the destination server, create a sync job pointing at the source:

Create a sync job (on the destination server)

proxmox-backup-manager sync job create \
  --remote 10.0.2.20 \
  --remote-user sync@pbs \
  --remote-datastore store1 \
  --datastore remote-store1 \
  --remote-auth token \
  --schedule "daily 03:00"

Important parameters:

--remote: the source PBS hostname/IP.
--remote-user + --remote-auth token: token-based authentication.
--remote-datastore: the datastore synced from the source.
--datastore: the destination datastore on the local server.
--schedule: the schedule — daily is a reasonable starting point.

Verify and run it manually:

View and run the sync job

proxmox-backup-manager sync job list
proxmox-backup-manager sync job run <job-id>

Important

Do not forget retention on the destination side (episode 8): without --keep-* and --remove-vanished, the remote datastore will pile up all history without limit. Set keep per your policy, and make sure --remove-vanished is active so snapshots deleted on the source are cleaned up on the destination too.

#Encrypting Data in Transit and at Rest

PBS sync secures data in two layers:

In transit: a TLS connection with source certificate fingerprint verification.
At rest: if the original backup is client-side encrypted (episode 7), the synced ciphertext remains unreadable to the destination server. The destination server cannot even verify the contents — only chunk integrity.

For cases where client-side encryption is not yet used, at least make sure the sync connection uses TLS and the inter-PBS network is isolated (episode 13).

#Off-site: A Second PBS and the 3-2-1 Strategy

#A Second PBS in Another Location

The off-site best practice is a truly separate second PBS — different building, different city, different power/internet provider. This second server only needs to be a sync destination: it does not need to handle direct backups from PVE, just receive the sync results from the primary PBS.

A typical architecture:

If location A is destroyed entirely, a new PVE elsewhere can register the remote PBS as storage and restore directly — exactly the episode 5 flow with a "different PVE".

#The 3-2-1 Strategy

The 3-2-1 strategy is the industry benchmark: 3 copies of data, on 2 different media/formats, with 1 copy off-site. In the PBS ecosystem, this translates to:

3 copies: original data in the VM, snapshot on the primary PBS, snapshot on the remote PBS.
2 media: e.g. local ZFS disks on the primary PBS + disks/storage at the remote location (different physical media).
1 off-site: the remote PBS in a different location.

Tip

Start with a simple 3-2-1 (two PBSes + one off-site) then move up to 3-2-1-1 by adding an air-gap (offline media) or WORM/immutable for anti-ransomware defense — we build that security layer in episode 14.

#Closing

Key takeaways:

A sync job is a pull operation: the destination server pulls snapshots from the source server.
Set up a user + API token on the source (proxmox-backup-manager api-token create), use it on the destination with --remote-auth token.
Set --schedule daily, --keep-* retention, and --remove-vanished on the destination side.
Data is encrypted in transit (TLS + fingerprint) and at rest (ciphertext from client-side encryption).
Place the second PBS in a truly separate location as the sync destination.
The 3-2-1 strategy: 3 copies, 2 media, 1 off-site — with a second PBS, it is all achievable.

In the next episode, episode 11, we will extend backup reach beyond VMs: physical host & container backup — using proxmox-backup-client to back up host directories and partitions (like /etc and data) in PXAR format, and backing up and restoring LXC containers just like VMs. Nothing gets left unprotected!