# ZFS replication between Proxmox VE nodes: setup guide

> How to set up ZFS replication between Proxmox VE nodes: intervals, storage.cfg, manual runs, and recovery after a failure.

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](https://www.zevshost.net/en/kb/proxmox-cluster-nastroika/). 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](https://www.zevshost.net/en/kb/proxmox-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 status` shows 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.

---

Source: https://www.zevshost.net/en/kb/proxmox-zfs-replikaciya/