If you’re running a two-node Proxmox VE 9 cluster using ZFS as your storage backend, one of the most powerful built-in features you can use for disaster recovery is ZFS replication.
ZFS replication automatically synchronizes VM and container data between nodes using ZFS snapshots and incremental data transfers, ensuring your workloads are protected against node failure — even without expensive shared storage.
In this post, we’ll explain how ZFS replication works, how to configure it, and how it behaves during a node failure.
Note: A two node Proxmox VE cluster is NOT recommended in production environments.
What Is ZFS Replication?
ZFS replication is a snapshot-based data synchronization mechanism built into Proxmox VE.
It allows you to replicate local ZFS volumes (VM or container disks) from one node to another — automatically, securely, and incrementally.
It relies on the native ZFS commands:
After the first full copy, only the changed blocks between snapshots are transferred. This makes replication fast and bandwidth-efficient.
Example Setup
| Node | Role | Pool | IP |
|---|---|---|---|
| pve1 | Primary | rpool | 10.10.10.1 |
| pve2 | Secondary | rpool | 10.10.10.2 |
Replication direction: pve1 → pve2
How to Configure ZFS Replication in Proxmox VE 9
Option 1: Using the Proxmox GUI
Go to Datacenter → Replication → Add
Choose:
Source Node:
pve1Target Node:
pve2VM IDs: select the virtual machines
Schedule: e.g., every 15 minutes
Click Create to start replication.
Option 2: Using the Command Line
List replication jobs:
Under the Hood: The Replication Process Explained
Step 1: ZFS Snapshot Creation
Proxmox automatically creates a snapshot for each disk:
You can view snapshots:
Step 2: Data Transfer Over SSH
Proxmox uses a secure SSH connection between nodes:
If the previous snapshot exists on both nodes, only delta changes are sent:
Step 3: Verification and Retention
Once transfer completes:
Checksums verify data integrity
The target dataset is read-only
Old snapshots are automatically deleted according to retention policy
Step 4: Ready for Failover
After replication, VM disks exist on both nodes.
If one node fails, the replicated VM can be started manually — or automatically if HA and quorum are configured.
Advanced Features in ZFS Replication
| Feature | Description |
|---|---|
| Incremental replication | Transfers only changed data blocks |
| Compression | Uses ZFS LZ4 compression (can also compress stream) |
| Bandwidth control | Limit speed, e.g. --rate 20 (MB/s) |
| Resumable transfers | Automatically resumes after network interruptions |
| Parallel jobs | Configure per-node concurrency in /etc/pve/datacenter.cfg |
Example:
Incremental vs. Full Replication
| Type | Description | Use Case |
|---|---|---|
| Full | Sends entire dataset | First replication |
| Incremental | Sends changed blocks only | Routine sync |
| Resume | Continues partial send | After failure |
What Happens When a Node Fails
Without HA or QDevice
Cluster loses quorum (no automatic failover)
Replication stops
You can manually unlock and start VM on target node:
With HA + QDevice
Cluster maintains quorum via QDevice
Proxmox automatically starts replicated VMs on surviving node
Once the failed node is restored, replication resumes and syncs deltas.
Best Practices for Reliable ZFS Replication
| Aspect | Recommendation |
|---|---|
| Network | Use a dedicated 10GbE or VLAN interface for replication |
| Pool Names | Keep identical pool names on both nodes |
| Compression | Keep LZ4 enabled |
| ZFS Scrub | Run monthly: zpool scrub rpool |
| SLOG/ZIL | Use dedicated SSD for synchronous writes |
| Avoid Dedup | High RAM usage, not needed for replication |
Summary
| Feature | Description |
|---|---|
| Mechanism | ZFS send/receive via SSH |
| Direction | One-way (source → target) |
| Sync Type | Snapshot-based incremental |
| Automatic Failover | Requires HA + QDevice |
| Storage Type | Local ZFS pools |
| Efficiency | Only changed blocks sent |
Conclusion
ZFS replication in Proxmox VE 9 offers a simple, efficient, and robust disaster recovery method — perfect for small to mid-size clusters that don’t have shared SAN or Ceph storage.
With incremental snapshots, dedicated replication networks, and QDevice-based quorum, even a two-node Proxmox setup can achieve near-enterprise-grade data protection and uptime.