WZ-IT supports this through the relevant service: Proxmox setup.
Integrated Proxmox storage replication transfers guest volumes between cluster nodes using ZFS snapshots. After an initial full sync only changes are sent. Replication is asynchronous: changes since the last successful run may be missing after a failure (vendor manual). This article covers prerequisites, setup through the web interface and pvesr, operations and error handling, and the limits compared with backup, HA and pve-zsync. As of October 2026.
Contents
- 1. Check prerequisites and storage
- 2. Create the replication job
- 3. Operations, acceptance and failures
- Failure and migration
- Distinguish pvesr and pve-zsync
1. Check prerequisites and storage
Integrated replication works with local ZFS storage (zfspool). The ZFS pool must exist on source and target node and carry the same name; the storage ID must be available at the target. The cluster also needs quorum and sufficient capacity at the target.
pvesm status # storage IDs, type and usage per node
zpool list # ZFS pools of the node; compare the name on both nodes
zfs list -r rpool/data # datasets of the guest volumes (adjust the pool name)
Record all guest disks and check which are actually replicated. An unreplicated extra volume can prevent recovery on the target node. The storage basics explain the distinction from Ceph and LVM; the two-node guide covers quorum separately.
2. Create the replication job
In the web interface choose "Replication" on the guest, set the target node and schedule and limit the transfer rate if needed. On the command line use pvesr create-local-job. The job ID consists of the guest ID and a job number, which is assigned per guest:
# VM 100, job 0, target node pve-target, every 15 minutes, limited to 20 MB/s
pvesr create-local-job 100-0 pve-target --schedule "*/15" --rate 20 --comment "VM 100 to pve-target"
pvesr status
The schedule uses a subset of systemd calendar events; the smallest interval is one minute, the largest one week. Examples:
| Schedule | Meaning |
|---|---|
*/15 |
every 15 minutes (default) |
*/5 |
every 5 minutes |
22:00 |
daily at 22:00 |
mon..fri 22:00 |
weekdays at 22:00 |
--rate limits the transfer in MB/s so that replication overloads neither storage nor network. A guest can be replicated to several target nodes but not twice to the same one. The first run transfers all data; schedule it for a coordinated time and mind the network (network planning).
3. Operations, acceptance and failures
Check and control the jobs with these commands:
pvesr list # configured jobs
pvesr status # last run, duration, failure count, next run
pvesr schedule-now 100-0 # schedule the job immediately
pvesr update 100-0 --schedule "*/5" # change the schedule
pvesr disable 100-0 # pause the job, re-enable with enable
pvesr delete 100-0 # remove the job
The configuration lives cluster-wide in /etc/pve/replication.cfg. Check not only that the job exists but the age of the last successful run in pvesr status and the job log.
Error handling: If a job hits a problem it enters an error state. The configured schedule is then suspended temporarily and replication is retried every 30 minutes. After a success the original schedule applies again. Typical causes:
- Target pool full or unreachable, network outage between the nodes
- Storage ID or pool name missing or different at the target
- Snapshots or datasets on the target changed or deleted outside of replication
- Guest volumes that cannot be replicated, for example on another storage type
Record these acceptance criteria: time since the last successful sync, guest disk coverage, free target storage, alerting for a missing sync and the planned migration path. The management network should not be loaded by replication.
Failure and migration
If a guest is migrated to a node it is already replicated to, Proxmox transfers only the changes since the last sync. That shortens the migration considerably.
If the source node fails, the guest data sits on the target node, but only up to the state of the last successful sync. Without HA you start the guest manually: the guest configuration must be moved from the failed node to the target node (/etc/pve/nodes/<failed>/qemu-server/<vmid>.conf to /etc/pve/nodes/<target>/qemu-server/, lxc for containers) before the guest starts there. This works only with quorum. Never start the same guest independently on both sides.
Replication alone does not configure an HA resource. An automatic failover path needs HA, quorum and fencing and must be planned separately; for operating jobs and handling failures see Managed Proxmox.
Distinguish pvesr and pve-zsync
pvesr is the integrated cluster replication with jobs in /etc/pve/replication.cfg and GUI integration. The separate tool pve-zsync synchronizes ZFS data with its own jobs and operating conditions, also to hosts outside the cluster. Do not treat it as an interchangeable name for GUI replication and do not combine both unchecked on the same datasets.
Both ways need an independent backup concept: replication only keeps the latest state and replaces no retained data states. For historical backups and recovery see PBS offsite backup. For the build-out WZ-IT offers Proxmox setup.
Further reading
- Proxmox Storage: ZFS, Ceph & LVM - which file system?
- Proxmox two-node cluster with QDevice: quorum without a third node
To the matching service: Proxmox setup.
