Open-source alternative to VMware Live Recovery and Site Recovery Manager: the short answer
If your vSphere disaster recovery orchestration depends on a VVF or VCF subscription, and Live Recovery 9.0.x reaches end of service on October 11, 2027, plan for a replacement made of parts rather than a drop-in product. No single open-source project reproduces Site Recovery Manager (SRM) end to end. The realistic replacement combines Ceph RBD mirroring between sites for block replication, Proxmox VE storage replication for ZFS-backed guests, and Proxmox Backup Server for restore points, with the recovery runbooks, failover tests and evidence that you write and run yourselves. SRM gave you recovery plans with ordered priority groups, test failover into an isolated network, protection status per VM and a single place to execute a planned migration or failover. In the open-source stack, Ceph mirroring keeps a remote copy of RBD images current, Proxmox VE handles VM start order and high availability within a cluster, and Proxmox Backup Server supplies verified restore points you can restore to a recovery site. Ordering, network re-addressing, DNS changes and application-level startup checks are not built in. Confirm with your own team which of those steps you will script, and who owns each one.
Accept or fill these gaps before you commit. Proxmox VE replication works between cluster nodes with ZFS, not as a generic cross-site orchestrator, and Ceph mirroring needs a sound design for journaling overhead, bandwidth and split-brain handling, so have the storage team validate it against the Ceph documentation for your release, such as the Tentacle or Squid branch. High availability needs at least three cluster nodes, shared storage and watchdog fencing at each site. Test failover is a process you must schedule and record, and a successful restore is the evidence auditors will ask for, so keep dated test reports with measured recovery point objectives. Ask the vendor or integrator to confirm each of these in your environment before the 2027 deadline.
Which open-source component covers each SRM and Live Recovery capability
This table maps each recovery capability that SRM and Live Recovery provide to the open-source component that handles it, with an honest coverage level and the gaps to confirm. Read the coverage column as a starting point for design, not as feature parity, and treat every gap as work your runbooks or scripts must cover.
| Capability | Open-source component | Coverage and gaps |
|---|---|---|
| Replication of VM data to a second site | Ceph RBD mirroring between clusters for Ceph-backed disks; Proxmox VE storage replication for ZFS-backed guests | Covers block-level replication of guest disks. Ceph mirroring is asynchronous and replicates images, not the VM configuration. Confirm the replication interval and loss window against current Ceph and Proxmox VE documentation for your topology. |
| Recovery plans with ordering | Manual runbook layer, optionally scripted against the Proxmox VE API | Partial. No native recovery plan object equivalent to SRM. Boot order and start delays can be set per guest, but cross-VM dependency handling must be designed and tested by your team. Confirm current Proxmox VE startup ordering options. |
| Test failover without disrupting production | Isolated test network and restored replica copies, combined with Proxmox Backup Server restores to a sandbox | Partial. Achievable with a documented procedure, but there is no built-in isolated test network workflow like SRM's. Confirm how replicas can be brought up without touching production networking. |
| Planned migration | Proxmox VE live migration within a cluster, with storage replication for cross-site moves | Partial. Live migration across sites depends on shared or replicated storage and network design. Confirm the supported cross-site path and downtime behavior in your Proxmox VE version. |
| Failback | Reverse replication configured in the runbook, with Ceph mirroring or storage replication set up in the opposite direction | Manual. Failback is a documented sequence of steps you must rehearse. No automated orchestration is provided by the components listed here. |
| Protection reporting | Proxmox Backup Server job reports, Ceph health and mirroring status, and your own monitoring stack | Partial. Status is available from each component, but a single protection report across replication and backup must be assembled. Confirm which metrics your monitoring stack can collect. |
| Backup-based restore | Proxmox Backup Server with client-side encryption, deduplication and restore to the same or another cluster | Covers restore of backed-up VM and container data. Restore time and point-in-time options depend on job schedules and datastore design. Confirm restore procedures and test them against your recovery objectives. |
Which DR building blocks fit which recovery pattern
SRM bundled replication orchestration, failover plans and test runs into one product. In open source, those jobs are split across storage replication, backup restore points and your own runbooks. Each card below covers one building block, when it fits, and what it costs you to operate.
Ceph RBD mirroring between clusters
Ceph RBD mirroring replicates block images asynchronously from a primary Ceph cluster to a secondary one, so VM disks can exist at a second site. It fits estates that already run Ceph for Proxmox VE or Kubernetes storage and need a warm copy off site. Confirm whether you deploy with cephadm or Rook, and pick the release line you can support: Squid (19.2.x) and Tentacle (20.2.x) are both listed as actively maintained, with Squid's estimated end of life falling before Tentacle's. Plan for replication lag, the secondary site's bandwidth, and staff who can run cluster failover by hand.
Proxmox VE ZFS storage replication
Proxmox VE can replicate VM disks on local ZFS storage from one node to another at a set schedule, which suits node-to-node or site-to-site copies without shared storage. The trade-off is that replicas are point-in-time copies, so the data you can lose is bounded by the replication interval, and it is not a substitute for a restore history. Test that the target node has enough capacity and matching storage names before you rely on it. Keep the procedure in a written runbook, because the failover steps are manual unless you have built automation around them.
Proxmox Backup Server for restore points
Proxmox Backup Server (PBS) provides incremental, deduplicated backups with client-side AES-256-GCM encryption and remote sync of only new data, which gives you restore points at a second site. Version 4.2 moved S3-compatible object store datastores to full support and lets push sync jobs encrypt snapshots before they leave the source, which helps when the remote copy sits in a bucket that you do not fully control. Backups answer a different question from replication: they let you go back to an earlier state, but restoring a large estate takes time you must measure in tests. Confirm your restore time and retention settings during failover exercises.
Ceph-based shared storage for HA
Shared Ceph storage lets Proxmox VE high availability restart a failed node's guests on another node, because every host reads the same disks. It fits clusters that need automatic recovery inside one site rather than a cross-site failover. High availability needs at least three cluster nodes, shared storage, redundant hardware and watchdog-based fencing, so the design is a site-level dependency: if the Ceph cluster fails, the guests lose their disks. Ceph's hardware guidance calls for a dedicated drive per OSD, separate faster devices for WAL and DB on HDD-based OSDs, and bonded network links across two switches. Size memory for peak load and benchmark before purchase.
How Ceph RBD mirroring and Proxmox replication cover failover without SRM
SRM was one orchestrator, and the replacement is a set of mechanisms that you assemble and own. Site Recovery Manager combined replication control, recovery plans, test failover and reporting in one product. On the open-source side, the data path is handled by Ceph RBD mirroring between sites, or by Proxmox VE storage replication where ZFS is in use, while the cluster and HA layer decides where guests restart. Nothing in that stack produces a recovery plan document or a test report on its own. Your team has to define the order of recovery, script the steps that are not automated, and keep the evidence that an auditor will ask for. Treat the design as three layers to be tested separately: replication, quorum and fencing at the recovery site, and the human runbook that ties them together. Proxmox VE high availability sets hard prerequisites for the recovery site. The HA wiki calls for at least three cluster nodes for reliable quorum, shared storage that guests can reach from any node, redundant hardware, and watchdog-based fencing so that a failed node is reset before its guests are started elsewhere. A two-node recovery site cannot meet the quorum requirement, and a site without shared storage cannot restart guests on another host without a separate replication step. Confirm these requirements against the current Proxmox VE High Availability wiki before sizing the recovery site, because they determine the node count and the storage design more than any other choice. The Ceph hardware recommendations apply directly to the replicated storage, and they should drive the purchase rather than follow it. The guidance is a dedicated drive per OSD, WAL and DB moved to shared enterprise-class SSDs on HDD-based OSDs, bonded network links spread across two switches, and memory sized for peak use rather than calm periods. Replication traffic competes with production I/O during resync, so an undersized network or an under-provisioned OSD host shows up as a missed RPO, not as a slow dashboard. Benchmark the candidate hardware against your own write profile and your inter-site link before purchase, because the Ceph documentation itself notes that no two clusters are alike. Record the measured replication lag at each benchmark step, since that number becomes your RPO evidence.
How the replacement runs alongside the rest of vSphere during the transition
When a Proxmox VE cluster is built as a recovery site while vSphere still runs production, both platforms hold copies of the same data. Backup and replication overlap because the vSphere side may still protect VMs through its own tooling, while the Proxmox side collects replicas through Proxmox Backup Server or storage replication. Network mapping must be planned on both sides so a recovered VM keeps its addressing, VLANs and firewall scope, or the recovery plan fails at the moment it is needed. Until a failover test passes, vSphere remains the owner of production recovery, and the Proxmox site is treated as a candidate target only.
- Single owner per VM: Record which platform is the recovery owner for each VM. Do not let two runbooks claim the same workload.
- Schedule audit: Compare backup jobs in vSphere and in Proxmox Backup Server so that one VM is not snapshotted by both at the same hour against the same storage.
- Network map parity: Document the VLAN and subnet mapping for every recovery network on the Proxmox side and check it against the vSphere port groups.
- Replication scope: Confirm which datastores or Ceph pools carry replicas, and keep replica targets separate from production storage.
- Handover record: Write down the date on which recovery ownership moves to Proxmox for each application group.
Confirm with your storage and network teams which replication features your chosen storage design supports before any VM is assigned to the new site.
VMs protected by Site Recovery Manager have a replication target, recovery plan and test history in VMware. Those assets must keep working until the open-source target has passed the same kind of test. Running both protections on one VM at the same time is possible but creates double replication traffic and two recovery paths that may disagree about the current state. The safer pattern is to keep the SRM plan active for a workload, build the Proxmox target in parallel, and retire the SRM protection only after a successful recovery exercise and a recorded RPO result.
- Parallel protection: Keep SRM protection in place for each application group until the Proxmox target has been tested end to end.
- Replication overlap: Turn off or pause the SRM replication for a VM only after the new target holds a verified copy, so the recovery point is never lost.
- Recovery plan freeze: Freeze changes to the SRM recovery plan for a group while it is being migrated, so the runbook matches what is actually protected.
- Retirement gate: Require a documented failover test and an RPO measurement before an SRM plan is removed.
- Evidence retention: Keep SRM test reports and logs for the audit period, because they are the baseline the new process is measured against.
Confirm with your auditors and business owners which recovery evidence they will accept as equivalent before retiring any SRM plan.
Some workloads will remain on ESXi for a period, for example because of vendor certification, a vSAN dependency or a later wave. vCenter keeps owning inventory, placement and the recovery of those VMs, and the open-source platform must not reach into the same hosts or datastores. Backup and replication for these VMs continue under the vSphere tooling, and any Proxmox Backup Server jobs must cover only the Proxmox-hosted workloads. Network mapping stays under vCenter for the ESXi side, and the cross-platform links between the two must be documented so that a dependent application is not recovered on one side while its database is on the other.
- Scope boundaries: Keep a list of VMs, datastores and networks that stay under vCenter, and exclude them from any Proxmox job.
- Backup separation: Ensure a single backup system does not target a VM from both sides, which would double the restore points and complicate retention.
- Cross-platform dependencies: Map which ESXi-hosted services a Proxmox-hosted application depends on, and define the recovery order for both.
- Shared network paths: Confirm that firewall rules and routing used by both platforms are changed through one approved process.
- Owner of record: Name the team that answers for recovery of the ESXi estate until the last host is retired.
Confirm with your vendor and application owners whether any ESXi-bound workload has a dependency that prevents moving it, and record that decision.
Moving SRM recovery plans and protection groups to a tested Proxmox and Ceph design
This sequence turns SRM's recovery plans and protection groups into a documented Proxmox VE and Ceph design, with one tested wave at a time and recorded evidence for each RPO target.
Inventory protected VMs and recovery plan order
Export the current SRM protection groups, recovery plans, priority order and dependency notes, then match every protected VM to its datastore, disk type and network. Flag any VM whose disks sit on vSAN, since those cannot be imported directly into Proxmox VE and need a separate data path decided up front. Confirm current import limits, including vSAN-backed disks, snapshot behavior and tested ESXi versions, in the Proxmox migration wiki before the list is final. The step is done when every VM has one row with its plan, boot order, storage source and import method, and the owner of each application has signed off on the list.
Classify tiers and set RPO targets
Group the inventory into recovery tiers based on business impact, then set a recovery point objective for each tier that the platform can meet with its replication or backup interval. Ask the application owners and the risk function to approve the targets in writing, and record which targets depend on the Ceph RBD mirroring path, the Proxmox VE ZFS storage replication path or Proxmox Backup Server restores. The output is a signed tier table that maps every VM to one replication method and one RPO, which becomes the acceptance criteria for later testing.
Build the recovery cluster and storage
Stand up the recovery site as a Proxmox VE cluster with at least three nodes for quorum, watchdog-based fencing and the storage layout chosen in the earlier design. For Ceph, follow the hardware recommendations for dedicated OSD drives, shared SSDs for WAL and DB on HDD-based OSDs, enterprise SSDs for metadata and bonded network links across two switches. Deploy Proxmox Backup Server as a separate host for restore points. The step is complete when the cluster passes its health checks, Ceph reports a healthy state and a test VM can be created, started and migrated on the recovery site.
Enable replication for the first wave
Configure replication for the first wave only: Ceph RBD mirroring between sites for shared-storage VMs, or Proxmox VE ZFS storage replication for local-ZFS VMs, plus Proxmox Backup Server jobs for longer retention. Set the replication schedule to match the tier RPO and confirm that the sync lag stays inside the target during normal load. Document each job name, source, destination and interval in the runbook. The step is done when the first wave has replicated for a full observed cycle and the lag graph or job log shows it meeting the agreed RPO.
Run a test failover in an isolated network
Bring up the first wave's replicas on the recovery cluster inside an isolated network that has no route to production, with DNS, identity and any dependent services replaced by test copies. Follow the runbook in the recovery order that SRM used, starting dependencies first, and time each boot and application health check. Note every manual step, failed dependency and change needed. The step is done when the application owner confirms the restored service works in isolation and the isolated network has been torn down or verified closed.
Record results against the RPO and runbook
Write a test record for each VM with the replication lag at failover, the restore point used, the boot sequence, the health check results, the people involved and any deviation from the plan. Compare the measured data loss window with the tier RPO and log every gap as an action with an owner. Store the record, runbook version and configuration exports in a controlled location, since these become the evidence an auditor or internal assurance team will ask to see. The step is complete when the record is approved and every open gap has a named owner.
Repeat per wave and retire SRM protection groups
Repeat steps three to six for each remaining wave, reusing the runbook template and changing only the VM list, storage path and tier. Once a wave has passed its test and has run through a full replication cycle, disable its SRM protection group and recovery plan so that SRM no longer holds a duplicate copy of the protection. Keep the SRM configuration exported and the vCenter environment intact until the last wave is verified. The step is done when every tier has a passed test record on the Proxmox and Ceph design and no active SRM protection group remains for migrated workloads.
What runbooks and RPO evidence the open-source design must produce
SRM produced evidence as a by-product of running recovery plans. Operators used recovery plans to define the order in which protected VMs powered on at the recovery site, and the platform generated test failover reports and protection status views that auditors could read without rebuilding the environment. The open-source design has no single product that does this, so the replacement has to produce the same artifacts deliberately: a runbook per recovery tier, a dated record of each test failover, the measured recovery point and recovery time for each workload, and a protection inventory showing which VMs are covered by which replication or backup job. Confirm with your assessor which of these artifacts they expect in what format before the first test, because the layout of an acceptable evidence pack is set by their requirements, not by the tooling.
Write one runbook per tier, not per VM. Each runbook should name the Ceph RBD mirroring pool or Proxmox VE ZFS replication job that protects the workloads, the Proxmox Backup Server datastore used for restore, the boot order, the network mapping to the recovery site, and the person who approves failback. Record every test with its start and end time, the replication lag observed at the moment of cutover, the restore time of a sampled VM from Proxmox Backup Server, and the outcome. Measured RPO should come from the replication or backup timestamps in the logs, not from the schedule you configured. Keep the restore evidence next to the replication checks, since a replica that mirrors cleanly but cannot be booted or restored is a finding an assessor will raise.
DeployOpen prepares these runbooks, test records, control mappings and evidence packs for an independent assessor, and documents them in the client's own environment. DeployOpen does not issue audit reports, attestations or certifications. Auditors and certification bodies form the opinion on whether the recovery design meets a given requirement. Before scoping, ask your assessor which recovery objectives they will test against, how often they expect a test, and whether they want evidence exported from the systems themselves or generated from a controlled test script. Those answers determine how much of this evidence has to be automated from the start.
What does it cost and take to replace SRM with open source?
What are the cost components of replacing SRM with open source?
The main cost components are software subscriptions, hardware, storage, staff time and external implementation and testing. The software itself can be free: Proxmox VE, Proxmox Backup Server and Ceph are open-source, so the recurring license line is optional support rather than a per-core fee. Hardware and storage are usually the largest items, because a second site needs compute, capacity and network links sized for failover. Staff time covers building the runbooks, testing failover and operating the new platform. Ask any partner to split their quote into these components so you can see who is paid for what.
Which costs are one-time and which recur each year?
Hardware purchase, network build-out, initial configuration, runbook creation and the first failover test are one-time costs. Recurring costs include Proxmox VE and Proxmox Backup Server subscriptions if you buy them, power, data center space, replacement hardware, staff time for patching and periodic failover tests, and any retainer for support. Proxmox lists Proxmox VE subscriptions per CPU socket per year at 120 euros (Community), 370 euros (Basic), 550 euros (Standard) and 1,100 euros (Premium), according to the Proxmox VE pricing page. Proxmox Backup Server subscriptions are listed per server per year at 560 euros (Community), 1,120 euros (Basic), 2,240 euros (Standard) and 4,480 euros (Premium), according to the Proxmox Backup Server pricing page. All Proxmox VE tiers carry the same features, so the choice is about support entitlement and response time.
What makes the effort of an SRM replacement go up or down?
Effort rises with the number of recovery plans and the number of VMs in each, because every plan needs an ordered boot sequence, network mapping and a test that proves it works. The storage backend matters most: Ceph RBD mirroring between sites needs a different design from ZFS storage replication, and each adds its own monitoring. Site count, the number of applications with database or clustered dependencies, and how much you must document for auditors all add work. Effort falls when recovery plans are standardized and the sites share the same hardware and network design.
How long does a fixed-scope engagement take?
The timeline depends on the agreed scope, so DeployOpen does not quote a generic duration. Scope, deliverables and timelines are agreed in writing before work starts, and they reflect the site count, storage design, number of recovery plans and the change windows your organization can use for failover tests. Ask for a written plan that lists each phase, its deliverables and the dates you must hit, and confirm which environment access and approvals the plan assumes.
Can our team replace SRM without outside help?
Many teams with strong Linux, storage and network skills can build the platform internally, but the risk sits in the recovery evidence rather than the install. Successful work needs someone who can design Ceph or ZFS replication, configure Proxmox high availability with at least three cluster nodes and watchdog-based fencing, and run failover tests that produce records. Assess your staff against those skills before deciding. An external partner can be engaged for a fixed scope, such as the design and runbooks, while your team operates the platform.
What does the work need from our network, DNS, identity and change calendar?
Plan for a dedicated replication network between sites, with bonded links across two switches, as the Ceph hardware recommendations advise for production. You will need DNS records that can change during failover, identity sources that the recovery sites can reach, firewall rules for replication and backup traffic, and certificates for management interfaces. Change windows must be booked for each failover test, and application owners must approve the test plan. Confirm each of these with your network, identity and application teams before the scope is signed.
How do I check whether replication meets our recovery point evidence needs?
Measure it. Run replication on a schedule, record the time each recovery point is confirmed, and compare the gap with the recovery point objective each application owner has signed. Proxmox Backup Server supports incremental backups, deduplication, client-side AES-256-GCM encryption and remote sync of only new data, according to its documentation, which helps keep backup copies current across sites. Ask the implementation partner to deliver test logs and a summary of measured gaps, and confirm with your auditors which format they accept.
How DeployOpen scopes and delivers an SRM replacement
DeployOpen plans and implements self-hosted open-source disaster recovery inside your own infrastructure, from Ceph RBD mirroring and Proxmox VE storage replication to Proxmox Backup Server. Each engagement starts with a written scope that defines the recovery tiers, runbooks and evidence you need before any failover is tested.
How we scope
- Inventory which VMs and services need recovery, grouped by recovery tier and dependency order.
- Agree target RPO and RTO values per tier in writing, with the business owner signing off.
- Confirm the sites, network links, storage backends and Proxmox VE or Ceph versions in scope.
How we build
- Configure Ceph RBD mirroring between sites and Proxmox VE ZFS storage replication for each cluster.
- Set up Proxmox Backup Server datastores, retention and encryption to match the recovery tiers.
- Script failover and failback steps, then document the cutover order for each protected group.
How we hand over
- Deliver recovery runbooks written for your operations team, with step-by-step failover and failback procedures.
- Run scheduled failover tests and record measured recovery points and times as evidence.
- Provide documentation and training so your staff can run and repeat the tests without us.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for the support scope, response expectations and test cadence to be stated in your quote.
