Proxmox ZFS Replication for Short RPO Failover Without Full HA

The concrete problem is a small to medium Proxmox deployment that cannot justify a full HA cluster, but cannot tolerate losing a day of work when a node fails. The useful takeaway is to use Proxmox VE built-in ZFS incremental replication for operational resilience with a short recovery point objective, and pair it with Proxmox Backup Server for longer retention and deduplicated archives.

Why replication is different from backup in Proxmox

Proxmox VE exposes ZFS send/receive through Datacenter Replication in the web UI and API. Replication copies VM disks and LXC container root filesystems as ZFS snapshots between nodes over the network. It is not a backup system. It gives you recent, bootable copies on a second node for fast manual failover, with a retention window you control.

Backups via Proxmox Backup Server give you versioned, deduplicated archives, longer retention, and protection against logical corruption. The common engineering decision is to use both: replication for short RPO and quick recovery, PBS for disaster recovery and point-in-time restore.

How the replication model works

A replication job is defined per VM or container. It records source node, target node, target storage, schedule interval, snapshot retention on source and target, and an optional bandwidth limit. Proxmox creates periodic ZFS snapshots on the source pool and incrementally sends changes to the target pool.

ZFS replication requires ZFS storage on both source and target. It does not apply to LVM-thin, Ceph RBD, or directory storage without converting the storage backend. Replication produces crash-consistent copies. Application-consistent state requires guest quiescing or tools inside the VM. Network limits are per job and can impact production traffic if not sized.

A practical replication pattern

Assume two Proxmox nodes, node-a and node-b, both using ZFS pools, e.g., tank on node-a and tank on node-b, and a critical VM 100 on node-a.

In the web UI go to Datacenter -> Replication -> Add. Choose VM 100 on node-a as source, node-b as target, and the matching ZFS storage on node-b. Set an interval such as hourly for operational workloads, and set retention, for example 24 snapshots on source and target to bound disk use. Add a bandwidth limit if the replication link is shared.

Verification is manual. Check Datacenter -> Replication to see job status, last run time, and error messages. On each node as root you can inspect snapshots with a command like:

zfs list -t snapshot -r tank/vm-100-disk-0

Look for snapshot names created by the replication job on both source and target pools. Confirm the VM configuration is present on the target node and understand that starting a replicated VM requires manual steps and resource checks. Starting a VM from a replicated disk without the config can lead to mismatched resources.

Trade-offs and limits to plan for

Retention settings prune snapshots on both nodes. Short retention reduces storage but limits restore points. Bandwidth limits protect production traffic but increase RPO. Replication does not replicate VM configuration changes automatically in all cases, and failover is manual.

Crash consistency means databases may need application-level quiescing before a snapshot for clean restore. Behavior can vary across Proxmox VE releases.

Actionable closing: define RPO and RTO first, keep replication for the handful of workloads that need fast manual recovery, size bandwidth and retention to those workloads, and keep PBS jobs for weekly or daily long-term archives. Review replication status weekly and test manual start of a replicated VM in a maintenance window.