PBS replication (Proxmox Backup Server) consists of automatically synchronizing your backups between two remote PBS servers. It is the essential building block of a 3-2-1 strategy: your backups exist on two geographically separated sites, protecting you against a local disaster (fire, ransomware, hardware failure). Whether you replicate to your own infrastructure or to a managed PBS such as NimbusBackup, offsite backup through PBS sync is the foundation of any serious disaster recovery plan.
This guide covers two concrete scenarios: replication with NimbusBackup (on request to support) and replication between your own PBS instances using push and pull modes — including if you are a NimbusBackup customer with DatastoreAdmin rights. Whether you are looking to configure a PBS sync remote or understand the difference between PBS pull vs push, you are in the right place.
For automatic geographic replication without complex configuration, an offsite backup with native geo-redundancy like our Double Drive plans dramatically simplifies professional deployment. Operational in less than 15 minutes with automatic synchronization between two French datacenters and guaranteed GDPR/NIS2 compliance. Geo-replicated infrastructure eliminates the need to maintain two distinct instances while respecting the 3-2-1 rule. We detail below how to manually configure replication or benefit from integrated replication.
On the practical side: replication assumes a source PBS already plugged into PVE — if you are not there yet, start with our add a PBS to Proxmox VE tutorial. On the budget side, the cost of a second datastore (push or pull) is detailed in our offsite Proxmox backup pricing guide; and the "why replicate" decision sits inside the broader Proxmox 3-2-1 backup strategy we operate across 4 datacenters.
Table of Contents
1. How Proxmox Backup Server replication works
Proxmox Backup Server natively includes a sync remote mechanism that allows copying snapshots from one datastore to another PBS. Replication is incremental: only modified chunks are transferred, thanks to PBS native deduplication. This significantly reduces the required bandwidth.
PBS terminology: a Remote refers to the authenticated connection to another PBS. A Sync Job is the scheduled task that copies snapshots via this remote. Together, they form PBS replication.
Push mode (sync)
The source PBS sends its backups to the remote PBS. The PBS that receives backups from your PVE nodes initiates the transfer.
Pull mode (sync)
The remote PBS pulls backups from the source PBS. The destination PBS initiates the synchronization.
In both cases, the transfer uses the native PBS protocol on port 8007 (HTTPS). Data is encrypted in transit and deduplication works on both the source and destination sides.
2. NimbusBackup as the offsite target for your PBS
The most common scenario: you already run your own PBS and you need a reliable offsite target for your sync job, without building or maintaining a second site. NimbusBackup then becomes the remote destination of your replication — your PBS stays yours, we host the off-site copy in a French datacenter. It's a turnkey proxmox offsite backup: minimal entry ticket, and you keep control of your existing infrastructure.
And if you are already a NimbusBackup customer with multiple PBS plans (for example a Double Drive PBS, or a combination of two separate plans), you can also benefit from replication between your own datastores.
Default architecture
By default, your Proxmox VE servers send their backups directly to each of your PBS instances. There is no automatic sync job between PBS instances: each PBS receives its backup independently from your PVE nodes.
Enable replication between your PBS instances
By default, each PBS receives its backups directly from your PVE nodes. If you want to add synchronization between your two PBS instances, two options are available depending on your access level:
DatastoreBackup access
This is the default access level on your NimbusBackup PBS instances.
Open a support ticket with RDEM Systems. We configure the sync job for you (pull mode recommended), schedule the synchronization and enable monitoring.
Contact supportDatastoreAdmin access
On request, you can obtain admin rights on your PBS instances.
You can configure replication yourself by following the instructions in section 3, or ask support to set it up for you via a ticket.
See the configuration guideWhich plan combination? Replication works between any combination of two NimbusBackup PBS plans. For example: a Single Drive PBS on site 1 and an AirGapped Drive PBS on site 2, or two Single Drive PBS on two different sites. The Double Drive PBS plan natively includes two datastores on two sites.
Concrete example: combining LTO archival and air-gap
Result: your Proxmox VMs are backed up on two independent sites. Site 1 provides long-term archival on magnetic tape, site 2 offers total physical isolation (air-gap). Pull mode synchronization is enabled on request to support — site 2 pulls backups from site 1, without site 1 having any knowledge of site 2. This combination provides LTO durability, air-gap isolation and replica confidentiality.
NimbusBackup offsite target vs DIY VPS (Hetzner + rclone/S3)
A "bare" remote PBS datastore is quickly compared to a €5/month VPS plus rclone or an S3 bucket. Let's be honest: the difference isn't about raw storage price, but about what is hard to build yourself and maintain over time.
| Criterion | DIY VPS (Hetzner + rclone/S3) | NimbusBackup (managed offsite target) |
|---|---|---|
| Raw storage cost | Unbeatable on paper (~€5/month) | Higher per GB — you pay for the service, not the byte |
| PBS integration | rclone/S3 layer to maintain, or PBS 3.4+ object store to configure | Native PBS remote, deduplication preserved end to end |
| Verifiable immutability / air-gap | Build it yourself, often missing or untested | Real and verified (AirGapped plans, rotating offline disks) |
| Tested restores | verify jobs and restore tests are on you | Scheduled verify jobs, verified restores (the "0" of the 3-2-1-1-0 rule) |
| FR sovereignty / GDPR | Depends on the provider and chosen region | French datacenters, contractual GDPR/NIS2 compliance |
| Operations | You manage OS, updates, monitoring, incidents | No infrastructure to operate, support included |
Bottom line: if you want the cheapest possible storage and enjoy operating everything yourself, the DIY VPS remains relevant. If you want a verifiable, sovereign offsite target with no operational burden, that's exactly what NimbusBackup adds on top of your existing PBS.
Monitoring your backups
By default, your NimbusBackup account has DatastoreBackup access: you can back up and restore, but you cannot see the sync jobs in the PBS interface. To check the status of your backups and replication, log in to your client portal:
Client portal:
Dashboard with the status of your services, backups and replications.
Torn between self-hosting your offsite target and delegating it?
3. Replication between your PBS instances (admin)
If you have administrator rights on your PBS instances — whether your own servers or a NimbusBackup PBS with the DatastoreAdmin option — you can configure PBS replication yourself. Two modes are available: push (send) and pull (fetch).
Prerequisites
- Two PBS servers installed and operational (version 3.x or higher)
- Admin access (root or user with DatastoreAdmin + Remote.Audit privileges)
- Network connectivity between both PBS instances on port 8007/tcp
- A configured datastore on each PBS with sufficient space
3.1 Push mode: the source PBS sends to the remote PBS
In push mode, the PBS that receives backups from your PVE nodes initiates the send to the remote PBS. This mode is suitable when the source PBS has outbound network access to the destination.
Data flow:
Step 1: Create the Remote on the source PBS
On the source PBS, add the connection to the remote PBS:
# Add the remote to the distant PBS
proxmox-backup-manager remote add pbs-distant \
--host pbs-distant.example.com \
--auth-id sync-user@pbs \
--password
# Verify the connection
proxmox-backup-manager remote listVia the web interface: Configuration → Remotes → Add. Enter the host, user and password (or API token).
Step 2: Create the Sync Job in Push mode
Still on the source PBS, create a sync job:
# Create a push sync job
proxmox-backup-manager sync-job create push-to-distant \
--store local-datastore \
--remote pbs-distant \
--remote-store distant-datastore \
--schedule "0/6:00" \
--remove-vanished true
# Schedule "0/6:00" = every 6 hours
# --remove-vanished true = removes snapshots
# that no longer exist on the sourceVia the web interface: Datastore → your-datastore → Sync Jobs → Add Sync Job. Select the remote, the remote datastore, and the schedule.
Step 3: Create the user on the remote PBS
On the remote PBS, create a user with minimal permissions:
# Create a dedicated replication user
proxmox-backup-manager user create sync-user@pbs \
--comment "User for PBS replication from source"
# Set the password
proxmox-backup-manager user update sync-user@pbs --password
# Grant DatastoreBackup permissions on the remote datastore
proxmox-backup-manager acl update /datastore/distant-datastore \
DatastoreBackup --auth-id sync-user@pbsStep 4: Test and validate
Before triggering the first manual sync, double-check the four prerequisites below — a sync-job that "runs" but writes nothing is the most common silent failure we see in PBS replication audits:
- The remote datastore (
distant-datastore) exists on the destination PBS - The job ID matches the one created in Step 2 (here
push-to-distant) sync-user@pbshas DatastoreBackup on the destination ACL (Step 3)- Namespace prefix matches on both sides — see section 6.2 for
--ns/--remote-ns
Trigger the job manually from the source PBS:
proxmox-backup-manager sync-job run push-to-distantThe command returns as soon as the job is queued — it does not block until the transfer completes. To know whether the actual sync succeeded (and not just got accepted), watch the proxy log or pull the per-task log file directly:
journalctl -u proxmox-backup-proxy -f | grep sync
ls -lt /var/log/proxmox-backup/tasks/$(date +%a)/Gotcha — silent "TASK OK": if the task log shows TASK OK but the destination datastore is empty after the run, the sync most likely skipped due to a namespace mismatch, a schedule lock from a stuck previous run, or a vanished snapshot that was already pruned upstream. The full diagnosis flow is in the sync-job variations & errors section below.
3.2 Pull mode: the remote PBS pulls from the source PBS
In pull mode, the destination PBS initiates the connection to the source PBS to retrieve backups. This mode is recommended by RDEM Systems because it offers better security: even if the primary backup is compromised, the attacker has no knowledge of the existence of other backups nor any path to the replication PBS.
Data flow:
Step 1: Create the user on the source PBS
On the source PBS, create a read-only user for the pull:
# Create a read-only user
proxmox-backup-manager user create sync-reader@pbs \
--comment "Read-only user for PBS pull replication"
# Set the password
proxmox-backup-manager user update sync-reader@pbs --password
# Grant DatastoreReader only
proxmox-backup-manager acl update /datastore/local-datastore \
DatastoreReader --auth-id sync-reader@pbsSecurity: in pull mode, the remote PBS only needs read access on the source PBS. Even if the remote PBS is compromised, the attacker cannot delete your backups on the source PBS. Conversely, a compromise of the source PBS reveals no information about the replication PBS — the source PBS does not even know it exists.
Step 2: Create the Remote on the remote PBS
On the remote PBS, add the connection to the source PBS:
# Add the remote to the source PBS
proxmox-backup-manager remote add pbs-source \
--host pbs-source.example.com \
--auth-id sync-reader@pbs \
--password
# Verify
proxmox-backup-manager remote listStep 3: Create the Sync Job in Pull mode
On the remote PBS, create the sync job:
# Create a pull sync job
proxmox-backup-manager sync-job create pull-from-source \
--store distant-datastore \
--remote pbs-source \
--remote-store local-datastore \
--schedule "0/6:00" \
--remove-vanished true
# Manually run to test
proxmox-backup-manager sync-job run pull-from-sourceVia the web interface: on the remote PBS, Datastore → distant-datastore → Sync Jobs → Add Sync Job. Select the remote "pbs-source", the source store, and the schedule.
Step 4: Validate the replication
# Verify that snapshots have arrived
proxmox-backup-manager snapshot list distant-datastore
# Verify integrity
proxmox-backup-manager verify distant-datastoreNimbusBackup customer: we can configure our PBS in pull mode from your own PBS, provided it is accessible on the Internet (port 8007). Contact support to discuss.
4. PBS Pull vs Push: which mode to choose?
| Criteria | Push | Pull |
|---|---|---|
| Who initiates the transfer? | Source PBS | Remote PBS |
| Rights required on the source | DatastoreRead (local read) | DatastoreReader (read-only) |
| Rights required on the destination | DatastoreBackup (remote write) | DatastoreBackup (local write) |
| Security if the destination is compromised | Medium — the source actively pushes | Strong — read-only access on the source |
| Security if the source is compromised | Medium — the source knows the destination | Strong — the source is unaware of the replica |
| Firewall | Source → Dest (outbound) | Dest → Source (outbound) |
| Typical use case | The source site controls the send | The DR site controls the reception |
| RDEM Systems recommendation | When the destination is not administrable | Recommended |
Our recommendation: prefer pull mode. The disaster recovery site controls the synchronization and only needs read-only access on the source PBS. If the source PBS is compromised, the attacker discovers no path to the replica — the source PBS simply has no knowledge of the remote copy's existence.
5. PBS replication best practices
Scheduling
- Schedule replication after PVE backup jobs complete
- Recommended frequency: every 6 to 12 hours
- Avoid continuous replication to prevent bandwidth saturation
Security
- Use dedicated accounts with minimal privileges
- Prefer API tokens over passwords
- Enable proxmox backup client encryption (encryption key) so data remains encrypted even in transit
Storage
- Plan for the same amount of space on source and destination (PBS deduplication is local)
- Configure retention (prune) independently on each PBS
- Monitor disk space with alerts
Verification
- Run a regular verify job on the destination datastore
- Periodically test a full restore from the DR site
- Monitor sync logs to detect failures
Useful monitoring commands
# List all sync jobs
proxmox-backup-manager sync-job list
# View status of a sync job
proxmox-backup-manager sync-job status push-to-distant
# List configured remotes
proxmox-backup-manager remote list
# Verify integrity of replicated backups
proxmox-backup-manager verify <datastore>
# View space used per datastore
proxmox-backup-manager datastore list6. sync-job variations & common errors
Beyond the standard push and pull setups above, three day-to-day operations come up frequently in PBS replication: triggering a pull job manually from the receiving side, syncing only a single namespace, and reading task logs when a run did not complete cleanly.
6.1 Manual sync-job in pull mode
In pull mode the sync-job lives on the destination PBS, not the source — so the manual trigger and the resulting task log are both on the receiving side. Running the same command on the source PBS does nothing, because the source has no sync-job entry to begin with.
proxmox-backup-manager sync-job run pull-from-sourceIf you administer both sides of the replication, always read the task log on the receiving PBS — it is the only one that records the worker UPID and the per-chunk transfer counters.
6.2 Sync only one namespace (--ns / --remote-ns)
When the source datastore is segmented into namespaces (one per tenant, per PVE cluster or per environment), you usually want to replicate one namespace, not the whole datastore. Both --ns and --remote-ns must be set at job creation:
proxmox-backup-manager sync-job create tenant-a-only \
--store distant-datastore \
--remote pbs-source \
--remote-store local-datastore \
--remote-ns tenant-a/ \
--ns tenant-a/ \
--schedule "0/6:00"If only one of the two flags is set, the job exits TASK OK with zero chunks transferred — the silent failure called out in Step 4 of Push mode. Always verify the first run by listing snapshots on the destination side.
6.3 Diagnosing common failures
Network timeout
Appears as connection refused or i/o timeout in the proxy log.
Verify port 8007/tcp end-to-end with curl -k https://destination:8007/api2/json/version and any intermediate firewall.
Authentication failure
Logged as permission denied: authentication required or invalid token.
The dedicated sync user lost its ACL or its API token rotated — re-grant with acl update and confirm with acl list.
Schedule lock
Visible as unable to acquire lock when a previous run is still active.
List ongoing tasks with proxmox-backup-manager task list --running and either wait, or stop the stale UPID.
For all three, the per-task log file in /var/log/proxmox-backup/tasks/<weekday>/<UPID> contains the full stack trace — read it before retrying, otherwise PBS will keep retrying the same failure on the next scheduled cycle.
7. FAQ — PBS Replication
PBS replication managed by NimbusBackup
Don't want to manage replication yourself? With a managed PBS like NimbusBackup, combine two hosted PBS plans (e.g. Double Drive PBS, or a Single Drive + an AirGapped Drive) and ask support to enable synchronization. 24/7 monitoring included.