Proxmox Replication: Slow WAN, Low RPO

Proxmox VE is a robust and versatile virtualization solution, but managing replication between sites with slow WAN links presents specific challenges. Implementing an effective Disaster Recovery (DR) strategy is crucial for business continuity. This article explores how to configure asynchronous replication in Proxmox, optimizing available bandwidth and ensuring an acceptable Recovery Point Objective (RPO), even with a 100 Mbps link.

When I designed the DR for a client with two data centers connected by a 100 Mbps fiber link, I immediately realized that synchronous replication was out of the question. Link saturation would have paralyzed critical applications. The goal was to replicate over 300 VMs, some with tens of gigabytes of frequently changing data, ensuring a maximum RPO of one hour. The solution involved meticulous configuration of Proxmox asynchronous replication, leveraging compression, rate limiting, and intelligent scheduling to avoid impacting daily operations.

Tested on: Proxmox VE 8.2 · ZFS · August 2026

Prerequisites / Test Environment

To configure asynchronous replication between two sites, the following prerequisites are necessary:

Two Proxmox VE nodes: Installed and configured, with mutual SSH access. Ideally, the nodes should be part of a Proxmox cluster, but replication can also work between manually configured standalone nodes.
Shared or dedicated storage: On the destination node, you need storage (ZFS, LVM-Thin, directory) where VM replicas will be saved. Ensure the storage has sufficient space.
Network connectivity: A WAN link between the two sites. For testing, I simulated a 100 Mbps bandwidth with an average latency of 20ms.
SSH credentials: The Proxmox root user must be able to access the remote node via SSH without a password (using an SSH key) to automate data transfer. Read also: Passwordless SSH Linux: Configure Keys in 5 Minutes (2026)

1. Configuring the Remote Replication Target

The first step is to configure the destination Proxmox node as a target for replication. This can be done via the web interface (GUI) or command line.

Adding the remote node via GUI

Access the GUI of the source Proxmox node.
Go to Datacenter -> Storage.
Click Add and select Proxmox Backup Server (even if it’s not a PBS, we can use it to configure a generic remote target via SSH) or Directory if you are replicating to a specific folder via NFS/CIFS.
The most common and flexible approach for replication between Proxmox nodes is to configure the target directly from the replication panel for each VM, which will use SSH.

Manual SSH configuration for replication

Ensure the source node can reach the destination node via SSH. If you haven’t already, copy the source node’s public SSH key to the destination node:

ssh-copy-id root@<DESTINATION_NODE_IP>

Verify the connection:

ssh root@<DESTINATION_NODE_IP> 'pveversion'

2. Creating Asynchronous Replication for a VM

Now we configure replication for a specific virtual machine. This can be done from both the GUI and the CLI. The CLI offers greater control over optimization parameters.

Via Web Interface (GUI)

Select the VM you want to replicate in the left panel.
Go to the Replication section.
Click Add.
In the Target field, select the remote Proxmox node (if it’s part of a cluster) or the Proxmox Backup Server configured previously (if you used it as a workaround for the remote target).
Schedule: set the replication frequency (e.g., every hour).
Bandwidth limit: crucial for slow WANs. Set a value (e.g., 10MB/s for 80 Mbps, leaving a margin on the available 100 Mbps).
Compression: select ZSTD for the best efficiency.
Rate Limit: specify a limit in MB/s or Mbit/s.
Prune: configure replica retention.
Click Create.

Via Command Line (CLI) – Optimal Control

The CLI allows you to specify all parameters with precision. We will use the pvesr create command.

pvesr create <VMID> --target <remote_storage_name> --schedule '*/30 * * * *' --rate 10M --compress zstd --remote <remote_node_name>

Parameter explanation:

: ID of the virtual machine to replicate.
--target : The name of the storage on the destination node where the VM will be replicated (e.g., local-zfs-remote). This storage must be reachable and have space.
--schedule '/30 ': The schedule in cron format. This example replicates every 30 minutes. You can use a less frequent one (e.g., 0 * for every hour).
--rate 10M: Limits bandwidth to 10 Megabytes per second (approximately 80 Mbps). This is essential to avoid saturating a 100 Mbps link. Experiment with this value based on production traffic and available bandwidth. Read also: UFW Firewall Ubuntu: Complete Configuration from A to Z (2026)
--compress zstd: Enables Zstandard compression. ZSTD offers an excellent balance between compression/decompression speed and compression ratio, significantly reducing the amount of data transmitted.
--remote : The name or IP of the destination Proxmox node. If the nodes are in a cluster, it will be the node name. If standalone, the IP.

Practical example for VM 101, replicated hourly, with a 10MB/s limit and ZSTD compression on a remote node named pve-remote and storage zfs-pool-backup:

pvesr create 101 --target zfs-pool-backup --schedule '0 * * * *' --rate 10M --compress zstd --remote pve-remote

To view the status of configured replicas:

pvesr list

3. Monitoring and Tuning

After configuring replication, it is essential to monitor its performance and bandwidth consumption.

Proxmox Logs: Check system logs (journalctl -f or /var/log/syslog) to verify replication progress and detect any errors.
Network Monitoring: Use tools like iftop, nload, or your router/firewall’s integrated monitoring to check actual bandwidth consumption during replication periods. Verify that the set rate is respected and that there are no unexpected spikes.
RPO: Calculate the effective Recovery Point Objective. If replication takes longer than expected to complete, you might need to reduce the replication frequency or slightly increase the rate if bandwidth allows.
Sizing: Ensure the destination storage is adequately sized to hold replicas and any snapshots Proxmox creates during the process. Read also: LVM Snapshot: Safe Rollback for Critical Updates

Common Errors and Troubleshooting

SSH Connection Refused/Permission Denied: Ensure SSH keys have been copied correctly and that the root user can access the remote node without a password. Check the firewall (ufw status or firewall-cmd --list-all) to ensure port 22 is open.
Storage Not Found/Full: Verify that the destination storage name is correct and that space is available. Check storage permissions on the remote node.
Slow or incomplete replication: Increase the rate or decrease the schedule frequency. Check WAN latency and packet loss (ping, mtr). ZSTD compression helps significantly, but already compressed data (e.g., JPG images, videos) will not benefit much from further compression.
VM stuck during replication: This is rare with asynchronous replication, but if it happens, check the status of the source and destination storage. It might indicate I/O issues or snapshots not being released correctly. Ensure qemu-guest-agent is installed and running inside the VMs for consistent snapshots.

FAQ — Frequently Asked Questions

Does asynchronous replication impact the performance of source VMs?

Yes, but minimally. Snapshot creation (which is the starting point for replication) can cause a brief I/O spike. Data transfer occurs in the background, and disk impact is primarily on the destination node. With ZFS and LVM-Thin, snapshots are very efficient, and the overhead is negligible in most cases.

Can I replicate VMs between different Proxmox VE versions?

It is generally recommended to maintain the same Proxmox VE versions between replication nodes. Small differences (e.g., 8.1 and 8.2) usually work, but larger differences (e.g., 7.x and 8.x) can cause compatibility issues, especially with QEMU versions and virtual disk formats.

How does failover work in case of disaster?

Asynchronous replication prepares a copy of the VM on the secondary node. In case of a disaster on the primary node, you will need to manually start the replicated VM on the secondary node. Proxmox does not offer integrated automatic failover for asynchronous replication between standalone nodes. For automatic failover, a HA cluster with shared storage or external solutions is required.

Is it possible to replicate only parts of a VM (e.g., only one disk)?

No, Proxmox replication works at the full VM level. It replicates all virtual disks associated with the VM. If you need to replicate only specific data, you should consider operating system-level solutions (e.g., rsync, data-specific incremental backups).

Conclusions with Operational Takeaways

Proxmox VE asynchronous replication is a powerful and cost-effective solution for ensuring resilience and Disaster Recovery, even in environments with significant bandwidth limitations. The key to success lies in careful configuration of optimization parameters. Remember to:

Always use ZSTD: Compression is your best ally on slow WANs.
Set an adequate rate: Limit bandwidth to avoid degrading critical application performance.
Schedule intelligently: Leverage low-traffic windows for more substantial replications.
Monitor constantly: Verify RPO, RTO, and bandwidth consumption to adjust as needed.

With these precautions, it is possible to achieve an RPO of 30-60 minutes even on a 100 Mbps link, protecting your virtualized infrastructures.

Sources

Proxmox VE Replication

Updated: August 2026