Live migration requires shared storage or transferring the whole disk over the network at the moment of the switch. ZFS replication solves this differently: the virtual machine's disk is synced to a neighboring node in advance, so during a failure you only need to power on the copy in seconds instead of waiting to copy terabytes.
How ZFS replication works in Proxmox VE
The mechanism is built on ZFS snapshots and the zfs send/receive command. Proxmox VE creates a snapshot of the VM disk on a schedule, sends the difference from the previous snapshot to the target node, and keeps an up-to-date copy there. Only the delta is transferred between nodes, not the whole disk, so a repeated replication run takes seconds even for a disk hundreds of gigabytes in size.
Storage requirements before configuration
Both nodes — the source and the receiver — need a ZFS pool with the same name (for example rpool/data), and the nodes must belong to the same Proxmox VE cluster. Check the pool name and its state with:
zpool status rpool
zfs list rpool/data
If the pools are named differently, you will need to configure replication manually through storage.cfg with an explicit target pool.
Setting up a replication job in the interface
A job is created in the virtual machine's properties, under Replication. Fill in the parameters:
| Parameter | Value | Comment |
|---|---|---|
| Target | receiving node name | the second or third cluster node |
| Schedule | */15 | replication interval in minutes |
| Rate limit | 50 MB/s | bandwidth cap on the shared network |
After saving, the job appears in the node's shared replication list and starts the first full snapshot — the longest one, after which only incremental transfers happen.
How to run replication manually and check its status
For a one-off sync or troubleshooting, use this command from the node console:
pvesr run --id 101-0
pvesr status
The pvesr status command shows the time of the last successful replication for each job and the failure reason, if any. A typical error is snapshot desynchronization after manually deleting a disk or moving a VM without updating the job.
What to do when replication breaks
If a job fails with an error about a missing shared snapshot, restore synchronization by deleting the local copy on the receiver and starting a full replication again:
pvesr delete 101-0 --force
qm set 101 --delete replicate
Then recreate the replication job through the interface — Proxmox VE takes a fresh base snapshot and restarts the incremental chain from zero.
How ZFS replication differs from a backup
Replication is not a substitute for regular backups scheduled through a backup schedule. It keeps only the latest copy on a neighboring node and does not protect against logical errors, such as deleting files inside the guest OS, which are replicated along with the disk right away. Use replication for fast failover and backups for point-in-time recovery.
Checklist for working replication
- A ZFS pool with the same name exists on both nodes.
pvesr statusshows a recent time for the last successful sync.- The rate limit is tuned so replication does not interfere with the cluster's regular network traffic.
- Regular backups to separate storage are configured alongside replication.