1) Design the topology
- Primary PBS (yours, on-prem): receives backups from your PVE clusters and serves fast local restores.
- Offsite PBS (hosted): receives a push sync from your primary — your DR copy, outside the building.
- Namespaces/datastores: mirror names across both sides to keep restores and permissions unsurprising.
- Network: a single outbound TLS connection from your PBS to the offsite server (TCP 8007). No VPN or inbound rules required.
2) Why push, not pull
PBS sync jobs run in either direction. Push — your server sends snapshots to the offsite PBS — is the direction we recommend, for three practical reasons:
- It works from wherever your PBS lives. Push needs only an outbound connection to port 8007, so NAT, dynamic IPs, and strict inbound firewalls are all non-issues. Pull requires the offsite server to reach into your network.
- It's entirely self-service. You create the remote and the job on your own PBS and it's syncing minutes later — nothing to coordinate or wait on with the far side.
- Your credentials stay yours. Nothing offsite holds a credential into your environment.
Push direction requires PBS 3.3 or later on your side — worth the upgrade on its own. Paired with a scoped token (below), push also holds up in the ransomware threat model; see immutable backups for the full permission story.
3) Plan bandwidth and capacity
- Estimate your daily change rate — after the first full sync, only changed chunks cross the wire.
- The first sync is the big one. On our hosted plans your first month's transfer is unmetered precisely so you can seed the full dataset.
- Use the sync job's rate limit if backups share an uplink with production traffic.
- Run a test sync, measure the effective throughput, and set the schedule so each night's delta finishes before morning.
4) Set up the push sync job
Everything happens on your PBS — the offsite side needs no configuration. Using a hosted instance, your hostname, fingerprint, and credentials come from the billing portal.
- Configuration → Remotes → Add: enter the offsite hostname, credentials, and TLS fingerprint.
- Datastore → Sync Jobs → Add: set Sync Direction: Push, your local datastore as the source, and the remote datastore as the target. Pick namespaces if you use them, and a schedule.
- Leave Remove vanished off unless you deliberately want local deletions mirrored offsite — off means the offsite copy keeps history even if the local side is purged.
CLI equivalent:
# on your PBS — remote details come from the billing portal
proxmox-backup-manager remote add onecolo \
--host pbs.example.onecolo.com --auth-id 'user@pbs' \
--fingerprint <fingerprint>
proxmox-backup-manager sync-job create offsite-push \
--sync-direction push \
--remote onecolo --remote-store <your-datastore> --store local \
--schedule "daily" --remove-vanished false
5) Security and isolation
- Push with a scoped token that can write backups but not prune or delete other groups — a stolen push credential then can't destroy offsite history.
- Keep Remove vanished off so a mass deletion on the primary never propagates.
- Let the offsite side enforce its own retention and verification — on hosted plans, that's our job.
- Separate admin accounts per PBS; enable 2FA and rotate tokens on your side.
6) Run failover restore drills
- Monthly: restore a VM/CT from the offsite PBS to a test PVE cluster; measure recovery time and throughput.
- Keep the offsite storage entry pre-configured (disabled is fine) in your PVE cluster so a real failover doesn't start with typing fingerprints.
- Document the sequence: point PVE at the offsite PBS, restore, validate application health, switch back.
7) Example DR playbook
- Document who owns the primary and who owns the offsite copy (on hosted plans: you and us, respectively).
- Keep a runbook with failover and restore steps next to the systems it describes — not only on a wiki that's inside the blast radius.
- Monthly: one restore from offsite to a test cluster. Quarterly: full failover simulation with lessons captured.
Want an offsite target that's ready in minutes?
Point a push sync job at a hosted PBS — first month's transfer unmetered for seeding, retention and verification handled on our side.