[TUTORIAL] What Replaces SRM and vSphere Replication on Proxmox?

[bbgeek17]

Hi Everyone,

Disaster recovery keeps coming up with folks moving off VMware, usually as some version of "what replaces SRM?" We've answered pieces of this in threads for years, so we finally sat down and wrote the whole thing up properly.

Mapping VMware DR Features to Proxmox VE: SRM, vSphere Replication, and Site Recovery https://kb.blockbridge.com/technote/proxmox-vmware-disaster-recovery/

The technote maps each VMware DR feature to its nearest native PVE equivalent: pvesr and pve-zsync, the PBS two-site pattern, the HA manager, PDM, stretched clusters with Ceph stretch mode, and array-based replication. It also walks through what doing SRM's job by hand involves: configurations, identity, addressing, start order, and testing. There's a feature mapping table at the end if you want the one-screen version. We stuck to native tooling; third-party tools exist but are out of scope here.

Everything was checked against current docs (PVE 9.2 / PBS 4.2 / PDM 1.1) or confirmed in our lab, and where we couldn't verify something, we say so. One thing we'll say up front: we have never run Ceph RBD mirroring failover ourselves, and public operational reports are scarce. If you've run it through a real or rehearsed site failure, we'd love to learn more and update the doc.

If you're doing DR on PVE in a way we didn't cover, or you think we got something wrong, post it here. We'll update the article.

As always, let me know if you have questions, corrections, or if we've missed anything!

Enjoy, The Blockbridge Team!

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[christophe]

Hi,

Thanks for your link.

We have run Ceph RBD mirroring (by pool, by image, snapshot-based and journal-based, one-way, two-ways). Not in production environment. Working as expected. Requires some care during implementation...

It needs some user friendly integration in WebUI, otherwise only advanced users can deploy.

But it is an essential feature - the multi-cluster equivalent of intra-cluster pvesr.

No doubt Proxmox Team is working on this.

Christophe.

 

[bbgeek17]

Thanks, @christophe! That's more configuration coverage than most reports we've found. "The multi-cluster equivalent of intra-cluster pvesr" is a good way to put it.

Since you've run both modes in both directions, a few things you're in a rare position to answer:

1. What did "some care during implementation" involve? For example, journal mode needs the journaling feature enabled per image, which requires librbd and doesn't mix with the krbd storage option. Was it that kind of thing, or something else?

2. What did you observe on the primary side while a peer was unreachable? Journal growth in journal mode, or mirror-snapshot buildup in snapshot mode? Space behavior during an outage is where we have the least data.

3. Did you ever end up in split-brain after a forced promote? The docs say resync deletes the image and copies from scratch. Curious how long that took at your sizes, or whether you found a better path.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[christophe]

Hi @bbgeek17,

In our context, we are preparing configurations intended to be instantiated by non-specialist departments; we are therefore prioritizing ease of implementation.

1. At the very beginning we followed multiple docs, mainly https://pve.proxmox.com/wiki/Ceph_RBD_Mirroring,https://docs.ceph.com/en/reef/rbd/rbd-mirroring/ and https://docs.ceph.com/en/latest/rados/operations/user-management/#user-management. A mix not so happy, an ill-advised combination led to an implementation that didn't work! A second try followed exclusively and strictly PVE doc. Journal mode is very interesting, particularly at the pool level, as it significantly simplifies management for operations teams : move a virtual machine disk to this pool, and it is automatically registered for replication! However, it comes at a cost: it doubles the number of write operations... In fact, we primarily conducted investigations using snapshot mode. krbd were not used in our lab tests but shouldn't be problematic with recent kernels / Ceph versions?

2. Good point! The tests conducted so far assume two healthy clusters to start with. The issue of a failing backup system will need to be added to our list!

3. Yes, every time we bring the disks back to the first Ceph cluster : split-brain! Because in the Cluster 1 configuration, the image was set to "primary"... So, we need to do the following on cluster 1 (primary / main) :

rbd mirror image demote ceph-disks/vm-101-disk-1

rbd mirror image resync ceph-disks/vm-101-disk-1

Showing :

rbd mirror pool status ceph-disks --verbose
health: WARNING
daemon health: OK
image health: WARNING
images: 1 total
    1 unknown

DAEMONS
service 7614135:
  instance_id: 7614216
  client_id: cluster1-test
  hostname: vpx1-ceph
  version: 19.2.3
  leader: true
  health: OK

IMAGES
vm-101-disk-1:
  global_id:   43c71802-a1a2-4c4f-b48a-fc33882aa4d2
  state:       up+error
  description: split-brain
  service:     cluster1-test on vpx1-ceph
  last_update: 2026-05-28 16:50:49

Then after resync completed :

rbd mirror pool status ceph-disks --verbose
health: WARNING
daemon health: OK
image health: WARNING
images: 1 total
    1 unknown

DAEMONS
service 7614135:
  instance_id: 7614216
  client_id: cluster1-test
  hostname: vpx1-ceph
  version: 19.2.3
  leader: true
  health: OK

IMAGES
vm-101-disk-1:
  global_id:   43c71802-a1a2-4c4f-b48a-fc33882aa4d2
  state:       up+unknown
  description: remote image is not primary
  service:     cluster1-test on vpx1-ceph
  last_update: 2026-05-28 16:52:18

Followed by

rbd mirror image promote ceph-disks/vm-101-disk-1

Wait fot Ceph status :

...
IMAGES
vm-101-disk-1:
  global_id:   43c71802-a1a2-4c4f-b48a-fc33882aa4d2
  state:       up+stopped
  description: local image is primary
  service:     cluster1-test on vpx1-ceph
  last_update: 2026-05-28 16:52:48

Then, finally, on the second cluster :

 rbd mirror image demote ceph-disks/vm-101-disk-1

I cannot say for sure whether the image was destroyed before the resynchronization; the operation took two minutes for a 32GB image. That is another good question to consider before moving to production!

All in all, the system isn't exactly user-friendly and, in its current state, cannot be offered to non-expert teams; however, all the individual components are there and work quite well.

Christophe.