Two sites, one Proxmox cluster — and the question: how do we survive if one site goes completely dark? The obvious answer is Proxmox Replication via pvesr. It mirrors VMs whose disks live on a ZFS pool to a ZFS pool on the second site on a configurable schedule. This is not synchronous storage, not automatic HA, not a backup replacement — but it is a surprisingly pragmatic disaster-recovery strategy once you understand its limits.

This article shows how it works in practice, what to watch for, and how it differs from related concepts.

What Proxmox Replication Is — and Isn’t

pvesr (Proxmox VE Storage Replication) is built on ZFS snapshots and ZFS send/receive. A VM with disks on a ZFS pool is replicated incrementally to a second Proxmox node with its own ZFS pool.

What it is:

Asynchronous, block-level replication (ZFS snapshot → send → apply)
Incremental after the initial full sync
Configurable per VM and per frequency (1 minute up to hourly/daily)
Integrated into the Proxmox UI — no extra tooling
Works in a cluster and between standalone nodes (cluster linkage strongly recommended)

What it isn’t:

Not synchronous storage: between replications there are at least 60 seconds (best case) — data loss on failover is possible
Not automatic failover: if the primary site goes down you must manually switch to the secondary
Not a backup replacement: a file accidentally deleted in the VM gets deleted in the next replication too — you still need Proxmox Backup Server
Not an HA cluster: classical HA needs shared storage (Ceph, NFS, iSCSI) on the same subnet — pvesr is the alternative when that’s not feasible

When Is Replication the Right Tool?

Concrete scenarios from DATAZONE projects:

Scenario A: HQ + branch with DR role

A GmbH with 80 employees has its HQ in city A; the managing director lives 30 km away with a small office. HQ has 3 Proxmox nodes, the branch has 1. The five most important VMs (AD, mailserver, ERP frontend, fileserver, web) are replicated every 15 minutes to the branch. In a fire scenario at HQ the MD can keep the business running with manageable data loss.

Scenario B: Hot-cold DR with a second rack at a fallback site

A mid-sized company with its own mini data centre adds a second rack at a warehouse 5 km away — connected via WireGuard and 1 Gbit/s. All production VMs replicate every 30 minutes. In a real incident the team manually switches to the cold site; RPO 30 min, RTO ~1 hour.

Scenario C: Multiple small branches

Branch setup with one Proxmox box per branch. HQ keeps a “hot-standby” VM set for every branch. On hardware failure in the branch the VM starts centrally and users connect via VPN.

In all three scenarios replication isn’t the only piece — it’s part of a DR strategy with backup, documentation and a runbook.

Prerequisites

Before you set up pvesr, a few things need to be in place:

ZFS-based storage

The VM must live on a ZFS pool. On both sides. Working storage types:

local-zfs (default ZFS pool on local disks)
Any ZFS pool configured as a Proxmox storage

Storage that does not work for pvesr: Ceph, LVM, iSCSI without ZFS, NFS, CIFS, directory storage.

Network connectivity

Port 22 (SSH) must be open between nodes — zfs send runs over SSH
Ideally a dedicated replication interface (VLAN or physical NIC) — replication can saturate the link
For cross-site replication: plan WAN bandwidth with headroom. A 100 GB VM during initial sync needs at least 2 hours on 100 Mbit/s — and blocks other traffic on the link during that time

Cluster or standalone?

pvesr works best inside a Proxmox cluster — authentication and reporting flow through Corosync. Two standalone nodes can replicate too, but UI status visibility and failover are clumsier.

Recommendation: Build a cluster across both sites. With only two sites think about quorum — either a QDevice as a third member (small VM or Raspberry Pi at a third location), or accept that you’ll skip cluster features beyond replication.

See also Proxmox 3-Node Cluster with TrueNAS for cluster basics.

UI Configuration

The simple path via the Proxmox web UI:

Select a VM on a ZFS pool from the left tree
Open the Replication tab
Click Add
Target: select the target node
Schedule: how often? Cron-style or presets (*/15 = every 15 min, 0 */1 = hourly, etc.)
Rate limit (MB/s): budget WAN bandwidth — e.g. 50 MB/s to leave room for other traffic
Comment: description
OK

The job starts at the next scheduled tick — or click Schedule now for the initial sync.

CLI Configuration

For scripts and automation:

# Replication job for VM 100 to "node2" every 15 minutes
pvesr create-local-job 100-0 node2 --schedule "*/15"

# With bandwidth limit (in KB/s, 50000 = 50 MB/s)
pvesr create-local-job 100-0 node2 --schedule "*/15" --rate 50000

# Status of all replication jobs
pvesr status

# Trigger manually
pvesr run --id 100-0

# Delete job
pvesr delete 100-0

The job ID 100-0 denotes VM 100, replication job number 0. A VM can have multiple replication targets (e.g. a local secondary node plus a remote site).

Initial Sync: The Pain Point on Big VMs

The first replication is a full transfer — all VM disk data crosses the network. A 500 GB VM on a 100 Mbit/s site link best-case takes ~11 hours — in practice longer.

Three ways to speed it up:

Initial sync via external disk. Export a ZFS snapshot of the VM locally to a USB-3 drive, drive to the secondary site, import there — then activate replication. The replication picks up the existing snapshot and continues incrementally.
Initial sync inside HQ, then move hardware. Stand up the secondary node in the HQ LAN, sync fully, then transport to the secondary site. Often the fastest option on small setups.
Buy bandwidth or work overnight. When the data-to-bandwidth ratio is bearable.

Practical note: Plan the initial sync window realistically. Experience: take the theoretical value × 1.5 for protocol overhead, waits, throttling.

Incremental Replication: Realistic Bandwidths

After the initial sync only deltas cross the wire. How big depends on the VM profile:

Web server (static content): a few MB per cycle
Mailserver: hundreds of MB to a few GB per hour
Database server with write load: GB range per hour (often better: use the DB’s logical replication stream, not VM replication)
Backup VMs: unsuitable — they themselves churn large volumes constantly

Rule of thumb: Watch closely during the first production week — how big is the delta? Does 100 Mbit/s suffice? If not, more bandwidth, less frequent replication or fewer VMs in scope.

Snapshots and Retention

Proxmox replication creates one snapshot per cycle per job. That’s normal and intended — but replicating every 15 minutes for 30 days quickly gives you 2,880 snapshots on the source.

By default pvesr only keeps two snapshots per job (the latest and the previous). That’s right and shouldn’t be changed casually — snapshot retention is a backup concern, not a replication concern.

Failover: The Manual Switch

In a disaster (primary gone) the procedure is:

1. Source is unreachable

Assumption: power outage, internet failure or hardware death at primary.

2. On the secondary: activate the VM

# On the secondary node:
qm rollback 100 __replicate_100-0_<timestamp>
# Find the last successful snapshot via:
zfs list -t snapshot -o name | grep <vmid>

Alternatively via the UI: select the VM → Hardware → Disk → the latest snapshot is used → start the VM.

3. Delete the replication job

The original job points at the unreachable primary. Delete it and set up an inverse job once the primary is back online — this time from secondary toward primary.

4. When the primary returns

Never start both VMs at once — split-brain. Instead:

On the primary: keep the VM stopped
Set up reverse replication (secondary → primary)
After full re-sync: stop on the secondary, start on the primary (or stay on secondary)

This switch process should be documented and rehearsed — like the restore test (Backup Test Day).

Differences from Alternatives

vs. HA cluster with Ceph

A classical HA cluster means: shared storage (Ceph, NFS, iSCSI), live migration, automatic restart on another node. Requirements: all nodes on the same subnet, low latency (< 1 ms between nodes ideally), fast storage interconnect.

Replication is not HA. If you need “no data loss, automatic failover” you need Ceph or another shared-storage model — see Proxmox High Availability Clustering and Ceph vs. ZFS.

vs. stretched cluster

A stretched cluster is HA across two sites with synchronous storage replication. Possible with Ceph but expensive (sync needs very low latency, often dedicated dark fibre) and usually over-dimensioned for SMB budgets.

vs. Proxmox Backup Server (PBS)

PBS answers “I need versioning and long-term retention”. pvesr does not replace PBS. Run both is the right architecture:

PBS: hourly/daily backups with long retention (30/90/365 days)
pvesr: near-real-time replication (15 min) for DR failover

vs. Cloud DR (Azure Site Recovery etc.)

Cloud DR is an alternative when the second “site” is a cloud provider. Trade-off: ongoing cost and egress vs. own hardware investment.

Lessons from Projects

From DATAZONE experience:

Start with small, non-critical VMs. Try replication on a test system before you replicate the mail server.
Always set a bandwidth limit. An unlimited replication can saturate the WAN link for 30 minutes and block everything else.
Monitor replication status. pvesr status reports errors, but if you have monitoring (Grafana/Prometheus/Zabbix), hook the status in there — see Grafana + Prometheus Stack.
Failover drills twice a year. Run a planned switch to the secondary every six months — including switch-back.
Keep the runbook. Which switch process for which VM? Who has the authority to call the switch? A “runbook” belongs to the design.
Snapshot hygiene. When VMs migrate or old replication jobs are removed, orphan snapshots stay behind. Periodically check zfs list -t snapshot.

Common Pitfalls

Replication runs, secondary lags behind. Often: WAN link too slow for the interval. Fix: longer interval or more bandwidth.
Snapshots fill the pool. Short intervals + write load grow snapshots on the source. Fix: bigger pool reserve.
VM doesn’t start on the secondary. Hardware version or driver differences. Fix: same Proxmox version + similar CPU/network setup on both sides.
Replication hangs after reboot. SSH keys must be exchanged between nodes — after reinstalling a node OS disk, re-establish trust.

Conclusion

Proxmox replication is a sober, well-functioning tool for asynchronous DR between two sites. It is not HA, not synchronous, not a backup replacement — but inside its lane it is robust and reachable for SMB budgets. Once that is understood you can build site resilience that used to require enterprise licences just a few years ago.

We at DATAZONE deploy pvesr regularly in customer projects — usually together with Proxmox Backup Server and a documented switch process. If you are planning such a DR strategy, we help with both architecture and the failover drill.

Proxmox Replication Between Two Sites