July 14, 2026

How VM replication works in Proxmox (and where it falls short)

Replication is the foundation of disaster recovery. Here's how Proxmox VE replicates VMs today, what it can't do, and how a storage-agnostic engine changes the picture.

Proxmox replicates at the storage layer

Unlike VMware's hypervisor-level replication, Proxmox replicates at the storage layer. That has a big consequence: what you can replicate depends entirely on your storage backend.

ZFS: pvesr

On ZFS, Proxmox uses pvesr (built on zfs send/recv) to replicate datasets asynchronously, down to roughly 1-minute intervals. It's efficient and block-consistent — but ZFS-only.

Ceph: RBD mirroring

With Ceph, RBD mirroring replicates block devices between clusters using snapshot or journal modes. Great for Ceph deployments, but it requires Ceph on both sides.

The gap: everything else

If your VMs live on LVM-thin, directory/qcow2, or NFS storage — very common in real deployments — Proxmox has no native replication at all. That leaves a lot of workloads without a low-RPO DR option out of the box.

Dirty-bitmap replication: storage-agnostic changed-block tracking

QEMU maintains dirty bitmaps — the same changed-block tracking Proxmox Backup Server uses for fast incremental backups. Because dirty bitmaps live in the hypervisor's block layer, they work regardless of the underlying storage. A DR engine can use them to ship only changed blocks to a recovery site on any backend — including LVM-thin, where Proxmox can't natively replicate.

This is exactly how ProxDR achieves storage-agnostic replication. Combined with recovery plans and non-disruptive testing, it turns Proxmox's storage-limited replication into full, orchestrated disaster recovery. Learn more in the Proxmox disaster recovery guide.