ZFS Replication in Proxmox VE: Fast Failover Without Shared Storage

You have a two- or three-node Proxmox cluster and no SAN. When a node dies, your VMs die with it, and restoring from backup means an hour or more of downtime plus whatever data was written since the last backup ran. The useful takeaway: if your VM disks live on ZFS, Proxmox's built-in replication jobs can push incremental snapshots to a second node every few minutes, giving you a warm copy you can start manually after a failure. It is not automatic HA, but it cuts both your recovery time and your recovery point objective (RPO — how much data you can afford to lose) dramatically compared to restore-from-backup.

What the feature actually does

Proxmox VE's replication feature is a scheduled wrapper around zfs send and zfs receive. ZFS snapshots are point-in-time references to a dataset that initially consume almost no extra space — they only grow as the original data changes. A replication job takes a snapshot of a VM's disk on the source node and transfers it to the target node. The first run sends the full disk; every run after that sends only the blocks that changed since the last snapshot, which is why a 15-minute schedule is realistic even for large disks.

The result on the target node is a complete, bootable copy of the VM's disks, frozen as of the most recent successful job. If the source node fails, you start the VM on the target (the VM configuration is already replicated cluster-wide via Proxmox's cluster filesystem, /etc/pve), and you are back up in minutes.

Requirements and the one naming rule that bites people

Replication works between nodes in the same cluster. The hard requirements:

• Both source and target storage must be ZFS (local zfspool storage entries).
• The ZFS pool must have the same name on both nodes. If the source pool is rpool/data, the target must also have rpool/data. This trips up nearly everyone the first time, because the default Proxmox install creates rpool/data anyway — but if you named one pool tank and the other storage, the job will fail.
• Nodes need network reachability over the cluster network; replication traffic uses SSH.

Note what is not required: shared storage, a quorum of three nodes, or the HA stack. Replication works fine on a two-node cluster with a QDevice for quorum.

Worked example: replicating VM 100 every 15 minutes

In the GUI, select the VM, open the Replication tab, and click Add. Choose the target node and a schedule such as */15 (every 15 minutes). That is genuinely all the configuration there is.

If you prefer the CLI, run this on any cluster node as root:

pvesr create 100-0 --target node2 --schedule '*/15' --rate 100

Here 100-0 is the job ID (guest ID plus an index), node2 is the target, and --rate 100 caps bandwidth at 100 MB/s so the initial full sync does not saturate your link — drop or adjust it for your network. Check job status with:

pvesr status

You should see the job listed with a last-sync timestamp and duration. The Replication tab's log shows the underlying send/receive operations. To verify the copy exists on the target, run zfs list -t snapshot on node2 and look for the VM's disk dataset with timestamped snapshots.

One thing to know: the first job sends the entire disk, so schedule it during a quiet window if the disk is large. Subsequent runs are incremental and typically finish in seconds.

Failing over when the source node dies

Because replication is asynchronous, Proxmox does not fail over automatically — this is a deliberate design boundary. The recovery procedure is manual:

1. Confirm the source node is actually down (avoid split-brain).
2. On the target node, start the VM: qm start 100 as root, or via the GUI. If the VM is locked to the dead node in the cluster config, remove the stale lock first with qm unlock 100 after confirming the guest is not running anywhere.
3. Once the source node returns, either migrate the VM back or reverse the replication direction.

Your data will be as current as the last successful replication run — with a 15-minute schedule, at worst 15 minutes of writes.

Trade-offs you should accept up front

Replication is not backup. Snapshots live inside the same ZFS dataset lineage. If you delete the VM, the replicated copies go with it; if ransomware or accidental deletion is replicated, both copies are poisoned. You still need Proxmox Backup Server (or another backup) on a separate failure domain.

It is not HA. There is no automatic failover and no synchronous writes. For VMs that cannot tolerate minutes of downtime or any data loss, you need shared storage with the HA manager, or application-level replication.

Frequency costs I/O. Aggressive schedules (every minute) add snapshot churn and network load on the source. For most workloads, 5–15 minutes is a sensible floor.

Closing: verify before you trust it

Set up one replication job today, then do the two checks that matter: confirm pvesr status shows recent successful syncs, and — the step everyone skips — actually boot the replica on the target node once in a test window. A failover copy you have never started is a hypothesis, not a plan. Exact GUI behavior and CLI options can shift between Proxmox VE releases, so confirm against the documentation for your installed version (pveversion -v) before relying on this in production.