Push vs. Pull Sync Jobs in Proxmox Backup Server

A Proxmox Backup Server sync job copies backup snapshots from one PBS datastore to another. It is the standard way to keep an offsite copy without backing every VM up twice: your cluster backs up to a local PBS, and the PBS replicates to a second server — for example a hosted datastore at OneColo. Since PBS 3.3 a sync job can run in either direction, and which direction you choose decides who has to open ports and who configures the job.

The moving parts

• Remote — a saved connection to another PBS: hostname, fingerprint, and a user or API token. Remotes are defined on the server that initiates the sync.
• Sync job — ties a remote and a source datastore/namespace to a local datastore/namespace, with a schedule and options such as remove vanished, max depth, a group filter, and rate limits.
• Direction — pull (the classic mode) or push.

Pull sync jobs

In a pull job, the destination server does the work: it connects to the remote source, lists its snapshots, and downloads whatever it does not have yet. This is the original PBS sync mode and it is ideal when the destination can reach the source over the network. The destination needs read access on the source (the DatastoreReader role on the source datastore or namespace).

The catch for offsite copies is that "destination reaches source" means the hosted server must connect inbound to your PBS on TCP 8007. That works if your PBS has a public address or you allow it through your firewall, but many networks would rather not expose it.

Push sync jobs

In a push job, the source server does the work: your on-premises PBS connects outbound to the remote and uploads snapshots. Nothing inbound is required on your side, and the connection is outbound TCP 8007 over TLS just like a regular backup. The source needs write access on the destination (the DatastoreBackup role, plus DatastorePowerUser if you want remove vanished to delete snapshots on the remote). Push requires PBS 3.3 or newer on the initiating server.

Which one should I use for an offsite copy?

For almost everyone the answer is a push job from your on-prem PBS: no firewall changes, and you keep control of the schedule and bandwidth.

What this means on Pay As You Grow

Pay As You Grow does not include the PBS web interface, so anything that lives on OneColo's server is set up by our admins. In practice:

• Push from your PBS to OneColo — self-service. On your PBS add a remote pointing at the hostname and fingerprint from your OneColo control panel, using your OneColo token, then create a push sync job targeting your datastore (and namespace, if you have one). If your token needs extra privileges for remove vanished, open a ticket and we adjust it.
• Pull into OneColo from your PBS — open a ticket. Tell us the address and fingerprint of your PBS, a read-only token for it, the source datastore/namespace, the target namespace on our side, and the schedule. We create the remote and the job.
• Pull from OneColo back to a new on-prem PBS (disaster recovery) — self-service on the new PBS using your existing token.

On a reserved instance you have the full web interface and can create remotes and sync jobs in either direction yourself under Configuration → Remotes and Datastore → Sync Jobs.

Options worth knowing

• Remove vanished — deletes snapshots on the destination that no longer exist on the source. Leave it off if the offsite copy should keep a longer history than the source.
• Max depth and namespaces — a job can sync one namespace or a whole subtree; see Using Namespaces in Proxmox Backup Server.
• Group filter — sync only certain VMs, containers, or hosts.
• Transfer last — sync only the newest N snapshots per group, useful for seeding.
• Rate limits — cap upload bandwidth so a nightly sync does not saturate your uplink.

Sync jobs only copy chunks the destination does not already have, so after the first run they are as incremental as backups themselves. If you have not connected a cluster yet, start with adding the hosted PBS to Proxmox VE.