Mapping VMware DR Features to Proxmox VE: SRM, vSphere Replication, and Site Recovery

This technote maps the disaster recovery features of the VMware platform to their nearest equivalents in Proxmox VE. Proxmox has no single equivalent of SRM. It spreads disaster recovery across several tools. For each VMware capability, we document the Proxmox equivalent, partial equivalent, or absence, and describe the best available approach where no equivalent exists. It is written for administrators leaving vSphere, and for Proxmox administrators handed DR requirements written in VMware terms.

Scope and Method

We compare native tooling on both sides. On the VMware side: vSphere Replication, Site Recovery Manager (SRM, now sold as VMware Live Site Recovery), vSphere High Availability, vSphere Fault Tolerance, vSAN stretched clusters, and array-based replication with Storage Replication Adapters (SRAs). On the Proxmox side: storage replication (pvesr), pve-zsync, Proxmox Backup Server, the HA manager, Proxmox Datacenter Manager, and replication options at the storage layer.

Third-party tools exist for both platforms. Several backup and replication vendors, including Veeam, now support Proxmox VE. We do not evaluate third-party products here. This document covers what ships with the platforms.

All Proxmox behavior described refers to Proxmox VE 9.2, Proxmox Backup Server 4.2, and Proxmox Datacenter Manager 1.1. Claims were checked against the current product documentation, and the failure and recovery behavior of both storage replication and cross-site sync was confirmed in our lab on PVE 9.2. Where neither settles a point, we say so.

Terminology: Reading VMware DR Concepts in Proxmox Terms

Anyone coming from VMware thinks and searches in VMware vocabulary. Proxmox uses different words, and several VMware terms have no Proxmox counterpart. This section aligns the two.

Names used in this document: Five Proxmox components appear throughout:

Storage replication (pvesr) replicates guest volumes between nodes of one cluster, on local ZFS storage only.
pve-zsync synchronizes guest disks and configuration between any two ZFS hosts over SSH; no cluster required.
Proxmox Backup Server (PBS) is the dedicated backup product.
The HA manager restarts guests on surviving nodes within a cluster.
Proxmox Datacenter Manager (PDM) provides visibility and management across clusters, comparable in role to vCenter.

RPO and RTO: Recovery point objective is the maximum data loss a plan accepts, measured as time since the last usable copy. Recovery time objective is the maximum time until service is restored.

The two platforms have different capabilities and different controls. vSphere Replication works per VM on any storage. You set the RPO you want, from 5 minutes to 24 hours, or as low as 1 minute with enhanced replication under specific subscriptions. The software schedules transfers to meet the target and alerts when the newest complete copy is older than the target. Proxmox has no explicit concept of an RPO, only a sync schedule. pvesr and pve-zsync run at the interval you configure, and the recovery point is the last completed transfer. Alerts fire on job failures, not on the age of your newest copy.

Local versus shared storage: The Proxmox replication tools solve a local storage problem: when a node with local ZFS fails, its disks fail with it, so pvesr keeps a copy on another node. On shared storage (Ceph, NFS, SAN) the disks survive a node failure, and these tools do not apply.

Protection group: In SRM, a protection group is a set of virtual machines that fail over together. It is a unit of failover, not of consistency: members recover to a single consistent instant only when array consistency groups provide it, and vSphere Replication groups recover each VM to its own point in time. Proxmox has no grouping construct for replication or recovery. Replication and backup jobs are configured per guest, and backup jobs can select guests by pool or by “all”. There is no protection group to fail over.

Recovery plan: In SRM, a recovery plan is an ordered, testable runbook. It defines which protection groups start, the order they start in, the dependencies between them, and the customization applied to each VM at the recovery site. Proxmox has no equivalent. Where start order matters, it lives in a runbook or in scripts the administrator maintains outside the platform.

Reprotect and failback: After an SRM failover, reprotect reverses the replication direction so the recovery site becomes the protected site, enabling a later failback. Proxmox has no equivalent operation across sites. Within a single cluster, pvesr reverses direction automatically when a guest migrates to its replication target, which is the same idea at node scope.

Planned migration versus disaster recovery: SRM distinguishes a planned migration (source site healthy, zero data loss, ordered shutdown) from a disaster recovery run (source site presumed lost, accept RPO-bounded loss). Keep this in mind when evaluating Proxmox options: several Proxmox mechanisms handle the planned case well, while the disaster case has fewer equivalents.

Warning: High availability is not disaster recovery on either platform. vSphere HA and the Proxmox HA manager restart guests on surviving nodes of the same cluster after a host failure. Neither protects against the loss of the site the cluster runs in. The documentation for both platforms says so.

vSphere Replication and Storage Replication (`pvesr`)

Storage replication is the Proxmox feature most often offered as the answer to “what replaces vSphere Replication.” It has intra-cluster replication, but not cross-site replication.

pvesr protects against node failure. It replicates the volumes of a guest on local ZFS storage to one or more other nodes in the same cluster, so that a copy of the data survives the loss of the node it runs on. Jobs are per guest, configured in the GUI, API, or CLI, and scheduled with calendar events from once a minute to once a week; the default is every 15 minutes. After an initial full sync, only data changes are transferred. Bandwidth can be limited per job. Replication traffic follows the migration network if one is configured, otherwise the management network.

A job covers a guest’s disks. Cloud-init drives are not replicated; Proxmox regenerates them where the guest starts. Individual disks can be excluded with the per-disk skip replication option; every disk that is not excluded must be on the supported storage. Within one run, the volumes are snapshotted in sequence. Each volume’s snapshot is atomic for that volume, and there is no atomic operation across volumes. (ZFS can snapshot multiple datasets in one atomic operation. Proxmox drives every storage backend through the same per-volume interface, so the capability goes unused.) When the guest is running and the QEMU guest agent is running inside it, the whole loop sits inside one filesystem freeze and thaw, so all disks capture one filesystem-consistent point. Without a running agent, each disk is individually crash consistent, captured at a slightly different instant than its neighbors.

Warning: Multi-disk guests are not I/O consistent across disks without the agent. A database with data and log on separate volumes recovers to mismatched points in time. The agent’s freeze has limits of its own. It reaches only mounted filesystems. A disk the guest uses as a raw device has no filesystem to freeze, so its snapshot is crash consistent with or without the agent. Even where the freeze applies, filesystem consistency is not application consistency.

Warning: A configured but unresponsive agent is skipped silently. The snapshots still complete, they are simply taken without the freeze, and nothing in the result reports the difference. Verify the agent responds inside the guest, not merely that it is enabled in the configuration.

pvesr supports only local ZFS (with the zfspool storage type). The pool must be configured on both nodes with the same storage ID. No other storage type is supported. There is no pvesr mode that reaches outside the cluster.

┌──────────────────────────────────────────────────────────────────────────────┐
│ PROXMOX CLUSTER                                                              │
│                                                                              │
│ ┌──────────────────────────┐      ZFS SEND      ┌──────────────────────────┐ │
│ │ NODE [A]                 │    ON SCHEDULE     │ NODE [B]                 │ │
│ │ ┌───────┐ ┌────────┐     │                    │ ┌────────┐               │ │
│ │ │ GUEST ┼─► ZFSPOOL┼─────┼────────────────────┼─► ZFSPOOL│               │ │
│ │ │ [100] │ │ [LOCAL]│     │                    │ │ [LOCAL]│               │ │
│ │ └───────┘ └────────┘     │                    │ └────────┘               │ │
│ └──────────────────────────┘                    └──────────────────────────┘ │
│                                                                              │
│ /ETC/PVE: EVERY GUEST CONFIGURATION, ON EVERY NODE                           │
└──────────────────────────────────────────────────────────────────────────────┘

The guest configuration is not part of the job because it does not need to be. Configurations live in /etc/pve, the cluster filesystem, which every node already holds in full.

Here’s an example of a job that runs every five minutes with a 10 MB/s limit:

# pvesr create-local-job 100-0 pve2 --schedule "*/5" --rate 10

Warning: A failed job enters an error state, suspends its schedule, and retries every 30 minutes until it succeeds. Each failure sends a notification. The notification reports that a sync failed. It does not report how old the copy on the target has grown. A five-minute schedule normally puts about five minutes of data at risk. While a job sits in the error state, the amount at risk is everything written since the last successful sync, and it grows until a retry succeeds.

Migration integrates with replication. Moving a guest to a node that already holds replicas transfers only the last deltas, and the job direction reverses automatically, so the previous source becomes the new target.

Recovery after a node failure

Without the HA manager, recovery is a documented manual procedure. On a surviving node, confirm the cluster is quorate with pvecm status, move the guest configuration from the failed node’s directory to the surviving node, and start the guest. The mv works because the configuration is already present cluster-wide; moving it between node directories reassigns which node owns the guest.

# mv /etc/pve/nodes/A/qemu-server/100.conf /etc/pve/nodes/B/qemu-server/100.conf
# qm start 100

The data recovered is the last completed sync. In our lab, a hard node stop on a two-node cluster with a QDevice and a five-minute schedule confirmed this behavior. The newest data in the recovered guest was from the snapshot of the last completed sync, taken about two minutes before the node stopped.

The HA manager provides the automated alternative. A replicated guest under HA management restarts automatically on the replication target after its node fails.

Warning: HA with replicated storage restarts the guest on data from the last completed sync. Anything written after that sync is lost. The documentation states this plainly; size the schedule to what the workload can afford to lose.

When the failed node returns, the job recovers on its own. In our lab, the replication configuration had reversed direction, with the recovered guest’s node as the new source, and the first run back was an incremental send from the last common snapshot after one stale snapshot was cleaned up. No full resynchronization was needed.

Note: Returning the guest to its original node is an ordinary migration, run with qm migrate --online --with-local-disks. The original node already holds a replica of the disks, so the migration sends only the changes since the last sync rather than the full disks. A stale cloud-init drive can still block the move. Cloud-init drives are not replicated, and the original node may still hold the drive it generated before the failover. The migration then fails with a ‘volume already exists’ error; remove the stale drive and run the migration again.

Watching the recovery point

pvesr status on a node lists each job with its last successful sync time. Run it on the node where your guest runs, as replication state is tracked per-node. There is no built-in alert for a recovery point growing stale while jobs technically keep succeeding, or during the 30-minute retry window; job failure notifications are the only built-in signal. We recommend creating a small cron job that reads last_sync and compares the age against your own threshold.

What does not map

vSphere Replication was storage agnostic, reached any paired site, and reported RPO violations. pvesr covers none of that: it requires ZFS, reaches only nodes of the same cluster, operates on a fixed schedule, and only reports failures. For guests on shared storage, or for a copy at another site, this feature does not apply. The next sections cover those cases.

Cross-Site Replication with `pve-zsync`

Many shops leaving VMware need to replicate between two datacenters, from site A to site B. The native tool for that is pve-zsync.

pve-zsync synchronizes a virtual machine’s disks and configuration from one ZFS host to another over SSH. The destination is not necessarily in the same cluster as the source; it can be a standalone Proxmox host across a WAN. The tool ships as a separate package and is documented on the Proxmox wiki.

Replication is driven by a cron job. Creating a job writes a line to /etc/cron.d/pve-zsync with a default interval of 15 minutes. The schedule is whatever cron expression you put there. Each run snapshots the source volumes and sends an incremental update. The snapshots are taken with no guest coordination of any kind. There is no freeze, and each disk is captured at a slightly different instant. Retention is per job (--maxsnap), bandwidth can be limited (--limit), and a job can be driven from the source or the target side. Because there is no shared cluster filesystem with a remote host, the tool copies the virtual machine’s configuration to the destination with every sync, keeping a timestamped copy per snapshot under /var/lib/pve-zsync/. Each recovery point arrives paired with the configuration that matches it.

┌──────────────────────────┐                        ┌──────────────────────────┐
│ SITE A: CLUSTER NODE     │                        │ SITE B: STANDALONE       │
│ ┌──────────────────┐     │       SSH + CRON       │ ┌──────────────────┐     │
│ │ ZFS POOL [TANK]  ┼─────┼────────────────────────┼─► ZFS POOL [TANK]  │     │
│ └──────────────────┘     │                        │ └──────────────────┘     │
│ ┌──────────────────┐     │       FILE COPY        │ ┌──────────────────┐     │
│ │ CONFIG [100.CONF]┼─────┼────────────────────────┼─► /VAR/LIB/PVE-    │     │
│ │ IN /ETC/PVE      │     │                        │ │ ZSYNC/[100.CONF] │     │
│ └──────────────────┘     │                        │ └──────────────────┘     │
└──────────────────────────┘                        └──────────────────────────┘

Example: A job replicating VM 100 to a remote pool.

# pve-zsync create --source 100 --dest 192.168.1.2:tank --name siteB --maxsnap 4 --method ssh

We ran the documented procedure unchanged on PVE 9.2 and it behaved as described.

Note: Job creation opens the first SSH connection and prompts to accept the destination’s host key. You must accept the key at that time. A job created without the key fails when cron runs it unattended.

Warning: Recovery points are crash consistent per disk, and multi-disk guests are not I/O consistent across disks. For example, a database with data and logs on separate volumes recovers to mismatched points in time. pve-zsync has no agent integration, so a filesystem freeze is not available.

Recovery at the remote site

Recovery is manual. Confirm the source guest is stopped or the source site is unreachable. Disable the job so a sync does not interfere (pve-zsync disable --source <vmid> --name <job>). Copy the newest timestamped configuration from /var/lib/pve-zsync/ to /etc/pve/qemu-server/<vmid>.conf on the destination. Adjust storage names if the pools differ. Then start the virtual machine. In our lab this took about three minutes, and the storage name was the only edit needed. The data recovered is the last completed sync.

There is no reverse operation. Re-protecting the recovered machine requires building a job in the other direction by hand.

Warning: Nothing in the procedure checks whether the original guest is still running. If the source site is up, starting the copy produces two guests with the same identity on whatever networks connect them. The identity discussion later in this document covers the consequences.

Note: The wiki labels pve-zsync a technology preview, and portions of its documentation date from earlier Proxmox releases. It is in current use and Proxmox staff have confirmed it works for remote sync. We recommend that you test the full recovery path with your own pools and names before relying on it.

Watching the recovery point

pve-zsync list shows each job’s state and last sync time. Job failures generate emails. As with pvesr, there is no handling of recovery point age, only job failures. A stalled link that fails every run for an afternoon reports each failure, but nothing tracks the age of the data at site B. As described earlier, we recommend creating automation that compares the last sync timestamp against your own threshold and alerts on the difference.

What does not map

There is no GUI, no grouping, and no orchestration. Each virtual machine is its own job and its own cron line. Direction does not reverse on failover. Nothing coordinates guest startup order at site B. pve-zsync moves the data and the configuration file, while everything else that Site Recovery Manager wrapped around that movement is the administrator’s responsibility to script.

If your storage is not ZFS, neither this tool nor pvesr applies. The remaining options are backups, covered next, and the storage layer, covered later in this document.

Off-Site Recovery with Proxmox Backup Server

Proxmox Backup Server is the most broadly applicable of the Proxmox DR tools, because it is the only one that does not care what storage the guests use. Every guest on every storage type can be backed up, copied off site, and restored at another location.

The usual objection is that backup is not disaster recovery. The distinction is real, but it is a matter of numbers. A backup-based recovery has an RPO of the backup interval and an RTO of the restore. Whether those numbers are acceptable is a per-workload decision. Some services tolerate hours, while some tolerate minutes. The correct approach is to compute the numbers for each tier rather than accepting or rejecting the approach outright.

PBS backups are incremental at the block level. A running virtual machine tracks changed blocks in a dirty bitmap, so a backup transfers only what changed since the last one, typically completing in seconds to minutes. Backups deduplicate at the datastore, and verification jobs check integrity on a schedule.

Note: The dirty bitmap lives in memory with the running guest. It survives live migration and in-guest reboots. A full stop, a disk resize, or a backup to a second target drops it. The next backup then reads the full disk but still transfers only the changed chunks.

For VMware administrators, the dirty bitmap is the counterpart of Changed Block Tracking. CBT persists its tracking on the datastore, so it survives power cycles, and every incremental depends on the stored change data being right. The bitmap is never persisted, so losing it costs a full read of the disk and never affects correctness.

The two-site pattern

The standard arrangement is a backup server at each site. Guests back up to the local PBS and a sync job copies the backup snapshots between the two, in either direction. A pull job runs on the receiving side and needs only read access to the source. It can re-fetch snapshots that fail verification. The receiving server holds the only credentials and can sit behind a firewall. The source never sees a credential for the receiving side. A push job runs on the sending side, for sources the receiver cannot reach. A disaster at site A leaves site B holding restorable copies of every guest as of their last synced backup.

PBS 4.2 adds several pieces relevant here. S3-compatible datastores are now a supported way to keep the off-site copy in object storage without a second server. A sync job can process backup groups in parallel when its worker-threads setting is raised above the default of one. A push job can encrypt the contents with a server-side encryption key before they are sent to the remote.

┌────────────┐        ┌────────────┐        ┌────────────┐        ┌────────────┐
│   GUESTS   │        │    PBS     │        │    PBS     │        │ RECOVERED  │
│  [SITE A]  │        │  [SITE A]  │        │  [SITE B]  │        │   GUESTS   │
│            ┼────────►            ┼────────►            ┼────────►            │
└────────────┘        └────────────┘        └────────────┘        └────────────┘
               BACKUP                 SYNC                RESTORE
                                    PULL/PUSH

Note: Proxmox Backup Server has no high availability of its own. Redundancy comes from running a second server and syncing between the two, which the two-site pattern already does. A restore needs a working PBS at the recovery site, so the backup server is part of the recovery path. An off-site copy in an S3 datastore still needs a server at recovery time. The instance can be installed in advance, but the datastore cannot be attached in advance, because only one PBS instance can operate on an S3 datastore at a time. The runbook step is to recreate the datastore on the recovery instance, under its original name, with the reuse-datastore and overwrite-in-use flags.

Restore, and restore time

RTO is the main cost of backup-based recovery: a full restore moves the entire guest image before it runs. Live restore splits that cost. The virtual machine starts immediately and runs while its disks stream in from the backup in the background, with reads of not-yet-restored blocks fetched on demand. Time to first service drops from the transfer time to roughly a boot. Time to full performance is still the transfer.

Workloads that read heavily from disk during the restore window run degraded until the restore completes. Expect the first hours of a recovered database service to run slower.

Watching the recovery point

Backup and sync jobs report status and fire notifications on failure. Each datastore shows the last backup time per guest. The recovery point at site B is the age of the last synced backup, which no built-in check compares against a target. As in prior sections, we recommend creating a small monitoring job to perform this function.

What does not map

Restores are per guest, started by an administrator, with no ordering, no grouping, and no recovery-time reconfiguration. Nothing rehearses a site recovery end to end. The nearest practice is scheduled test restores, which double as backup verification and belong in any runbook regardless of platform.

What PBS provides is complete, storage-agnostic, off-site copies of every guest. Everything built on top of such copies, the part Site Recovery Manager automated, remains manual.

vSphere HA, Fault Tolerance, and the Proxmox HA Manager

The Proxmox HA manager offers comparable functionality to vSphere HA: when a node fails, guests configured for HA restart on surviving nodes of the same cluster. Node health is tracked through the cluster quorum.

A node that loses quorum while running HA guests fences itself. A watchdog timer stops being reset and reboots the node, after which the cluster starts its guests elsewhere, so a guest cannot run twice. The default watchdog is the Linux kernel’s software watchdog (softdog); a hardware watchdog can be configured instead.

The design differs from vSphere HA in how a dead host is told apart from an unreachable one, and in what prevents a virtual machine from running twice. vSphere HA judges host health over two channels, network heartbeats and datastore heartbeats. An isolated host applies its configured isolation response itself. The guarantee against a guest running twice is the file lock on the datastore, which a restarted copy cannot take while the original holds it. Proxmox judges host health over a single channel, cluster quorum. The guarantee against a guest running twice is timing. The watchdog reboots the lost node before the cluster starts its guests elsewhere.

Placement is controlled through affinity rules. Node affinity rules pin or prefer nodes for a guest, and resource affinity rules keep guests together or apart. Failover placement is handled by the cluster resource scheduler in one of three modes:

the default mode counts HA services per node,
a static mode weighs the guests’ configured CPU and memory,
and a dynamic mode.

The dynamic mode uses measured utilization and can continuously live-migrate HA-managed guests to correct imbalance, within the affinity rules. Introduced in 9.2, the dynamic mode overlaps with what DRS did after a failover.

Two vSphere HA controls have no counterpart. Missing are admission control, which reserved failover capacity in advance so a site of survivors was guaranteed to fit the load, and restart priority tiers, which ordered recovery across virtual machines. In Proxmox, capacity after a failover is whatever the surviving nodes have, and guests restart without ordering.

For storage, vSphere HA assumed shared datastores. The Proxmox HA manager works with shared storage the same way, and can also restart guests whose disks are replicated with pvesr, with the data-loss consequence covered earlier.

vSphere Fault Tolerance has no Proxmox counterpart. There is no lockstep execution of a shadow virtual machine, and no configuration that survives a host failure with zero downtime. Workloads that used FT need an application-level answer on Proxmox, such as clustering inside the guests.

Note: As in the terminology section: HA on either platform restarts guests inside one cluster. It defines the boundary where disaster recovery begins, and nothing in this section protects against losing the site.

vCenter, Cross-Site Visibility, and Proxmox Datacenter Manager

In vSphere, cluster management lived in vCenter, a separate server the hosts depended on. Proxmox builds cluster management into the nodes themselves. The remaining question is what fills the vCenter role across clusters and sites. A DR design has a production cluster at one site, a recovery cluster at another, and a need for tooling with a view of both.

The answer is Proxmox Datacenter Manager (PDM). PDM 1.1 connects to any number of clusters and standalone nodes as remotes, and to Proxmox Backup Server instances. It provides a consolidated dashboard that includes cross-remote guest lists with snapshot management, Ceph cluster monitoring, subscription management, and automated installation of new nodes.

PDM can also migrate a guest between clusters. The clusters need no prior configuration linking them. PDM authenticates to both clusters and coordinates the transfer, although the source and destination nodes must still reach each other over the network to move the data. In SRM terms, a PDM migration is a planned migration of one guest at a time, with no grouping and no ordering. A migration needs an intact source to copy from, so a healthy guest can move to another site and a lost guest cannot.

For disaster recovery specifically, PDM today is a visibility and operations layer, not a replication or recovery layer. It does not replicate guests, does not hold recovery configuration, and takes no role in a failover. The public roadmap lists “off-site replication copies of virtual guests for manual recovery on a datacenter failure (not HA)”. As of this writing the item is planned, with no shipped functionality and no committed timeline.

Tip: A DR runbook should not assume the management layer survives the disaster. PDM runs where you install it; if that is the failed site, recovery proceeds without it, directly against the surviving cluster. The same consideration applied to vCenter and SRM server placement.

vCenter was required infrastructure and a dependency for SRM, DRS, and much else. PDM is optional and the clusters do not depend on it. Nothing breaks when PDM is absent, and nothing PDM offers today changes what the preceding sections said about replication and recovery.

Stretched Clusters

A vSAN stretched cluster puts two sites in one cluster. Writes commit to both sites synchronously, a witness at a third location arbitrates quorum, and HA handles a site failure with zero data loss. The price is strict inter-site latency, 5 ms round trip between the data sites and 200 ms to the witness.

Proxmox can be arranged the same way, with the same physics and a difference in packaging.

The cluster itself stretches first. The documentation requires latencies under 5 milliseconds between all nodes for stable operation, the same figure vSAN sets between its data sites. Two sites within the limit can form one cluster, with quorum protected by a QDevice at a third location. What a stretched cluster buys depends on the storage underneath.

With local ZFS on each node, pvesr replicates between the sites, and the HA manager restarts guests on the surviving site with loss bounded by the sync schedule, provided the replication targets and the HA placement rules both point across the site boundary, creating an asynchronous arrangement inside one cluster. For recovery point zero, the storage itself must span both sites, and the native option is Ceph in stretch mode; pvesr plays no part there, since Ceph is shared storage.

The minimum requirements for stretch mode are:

OSDs at exactly two sites,
two monitors per site plus a tiebreaker monitor at a third location (five in total),
the connectivity election strategy,
and a CRUSH rule keeping two replicas per site for four copies of everything.

Erasure-coded pools are not supported. When one site is lost, the cluster continues on the surviving site with min_size reduced to one.

       SITE [A] ◄────────────────── 5 MS RTT ──────────────────► SITE [B]
┌──────────────────────┐                                ┌──────────────────────┐
│ PVE NODES            │            COROSYNC            │ PVE NODES            │
│ CEPH MON X2          │          SYNCHRONOUS           │ CEPH MON X2          │
│ OSDS, 2 COPIES       ◄════════════════════════════════► OSDS, 2 COPIES       │
└──────────┬───────────┘          CEPH WRITES           └──────────┬───────────┘
           │                                                       │
           └───────────────────────────┬───────────────────────────┘
                                       │
                       ┌───────────────┴──────────────┐
                       │ SITE [C]: TIEBREAKER MON,    │
                       │ COROSYNC QDEVICE             │
                       └──────────────────────────────┘

Note: Proxmox installs and manages Ceph, but does not wrap stretch mode in its own interface. Enabling it involves manual configuration as described in the Ceph documentation.

Warning: While a stretch cluster runs degraded on one site, a single further failure can mean data loss, since min_size is one. The exposure ends only when the returned site resynchronizes, and that window has two bounds: at least all the data changed during the outage must cross the inter-site link (Ceph recovers at object granularity, so small writes move whole objects), and the OSDs must absorb recovery traffic while serving clients. Upstream guidance recommends all-flash OSDs for the second bound. The first bound is set by the link and the length of the outage.

What maps and what does not

The storage semantics map: synchronous writes to both sites, recovery point zero, continued operation through a site loss, guests restarted by HA, with a third location arbitrating.

The packaging does not map. Stretched vSAN was a cluster configuration type. The witness was shipped as an appliance, sites existed as fault domains, DRS rules were site aware, and read locality kept reads on the local site.

In contrast, the Proxmox arrangement is assembled from parts. Stretch mode is configured with Ceph tooling, site preference is approximated with node affinity rules, and no component of the platform has a concept of a site. Reads default to each object’s primary OSD, which can sit at either site, so read latency crosses the link routinely. Client-side options for preferring the local replica exist, but are their own tuning exercise.

If you ran vSAN stretched across a metro link, the constraints are familiar. There’s a third site for the tiebreaker, strict latency between the data sites, and double the storage. vSAN shipped this as a supported configuration. On Proxmox, it’s something you build yourself.

Array-Based Replication, the Storage Layer, and Doing Site Recovery Manager’s Job by Hand

For many VMware shops, DR never ran through vSphere Replication at all. The array replicated the LUNs, synchronously at metro distance for recovery point zero or asynchronously beyond it, with consistency groups preserving write order across related LUNs. SRM drove the array through a vendor Storage Replication Adapter (SRA). On failover it told the array to promote the replica, mounted the datastores, and registered and started the VMs in plan order.

On Proxmox, the storage half of that arrangement exists and the orchestration half does not.

A SAN that replicated LUNs for ESXi can replicate them for Proxmox hosts, and that path is the direct analog: synchronous or asynchronous as the array provides, with the array’s consistency groups. For guests on Proxmox-native storage, the same layer has software equivalents, both asynchronous. ZFS can send incremental snapshots to any receiver, and Ceph RBD mirroring can replicate images between clusters, in a journal mode or a snapshot mode.

Tip: On ZFS, each guest volume is its own dataset, and datasets sit in a tree. A snapshot taken at a parent dataset covers everything beneath it in one atomic operation. No Proxmox tool uses the capability. pvesr and pve-zsync snapshot volumes one at a time. For an administrator replicating by hand with zfs send, placing the volumes of related guests under one parent lets a single recursive snapshot capture every volume at the same instant. An array consistency group does the same job at the LUN level. For guests on plain ZFS, the hand-run recursive snapshot is the only substitute.

The array path comes with two constraints. The first is granularity, the storage’s rather than the guest’s. Array replication moves LUNs and consistency groups, so every guest on a replicated volume group fails over together or not at all. The second is that the recovery side is undocumented. The replica arrives at the recovery site as an LVM volume group. An operator must activate it and present it under the storage ID the guest configurations expect. Neither the array vendor’s documentation nor Proxmox’s covers the workflow.

Proxmox has no equivalent of the SRA interface and no awareness that the storage underneath it is replicated. Promoting replicas, presenting them to recovery hosts, moving configurations, re-addressing guests, keeping identities from colliding, starting everything in dependency order, and checking that all of it would still work today is operator work.

Note: Broadcom’s developer program lists Storage Replication Adapter certification as no longer available as of August 2025, with the program in enablement-only mode. Existing adapters continue to work but new array certifications are not being added.

What a recovery plan replaces, item by item

What an SRA-driven recovery plan automated is a list any administrator can execute, and scripted versions of it are the working DR plan of production Proxmox sites. Here is the list:

Data. Replicated by any of the mechanisms above, or by pve-zsync.

Configurations. /etc/pve is per cluster; nothing carries guest configurations to a second cluster. They travel by scheduled copy or a configuration-only vzdump. Because storage and configurations replicate on independent schedules, one is always older than the other. A configuration older than the data silently omits a recently added disk. A configuration newer than the data references a volume the replica does not yet hold, and the guest fails to start. The fix is to capture the configuration with each storage recovery point and recover the pair together. pve-zsync does this on every run, and a backup restore is immune because vzdump embeds the configuration. qm rescan reports volumes no configuration references.

  PRIMARY SITE                                          RECOVERY SITE
┌──────────────────────┐                                ┌──────────────────────┐
│ GUEST VOLUMES        ┼────────────────────────────────► REPLICAS             │
└──────────────────────┘      STORAGE, SCHEDULE 1       └──────────────────────┘
┌──────────────────────┐                                ┌──────────────────────┐
│ CONFIG [100.CONF]    ┼────────────────────────────────► CONFIG [100.CONF]    │
└──────────────────────┘     FILE COPY, SCHEDULE 2      └──────────────────────┘

Namespaces. Guest IDs must not collide at the recovery site, storage IDs in the configurations must exist there mapped to the promoted replicas, and bridge and vnet names must exist on the recovery hosts. Each is a naming convention held across two clusters, or an edit at recovery time.

Cluster-scoped configuration. The guest file is not the whole guest. Firewall rules live per guest in /etc/pve/firewall/, and storage definitions (storage.cfg) and SDN configuration are cluster level. A copy that carries only the qemu-server/ directory recovers guests with no firewall policy onto storage and networks that must have been pre-created by other means.

Addressing. The one item on this list SRM automated outright, with address mappings stored in the recovery plan. A layer 2 network stretched across sites keeps guest addresses but makes the network into one failure domain shared by both sites where an accidental double-start conflicts instantly. Separate networks isolate failures and tests, but at the cost of re-addressing at recovery. cloud-init covers prepared Linux guests, while Cloudbase-Init for Windows is documented but not officially supported. In a migration from VMware, unprepared guests can be the majority, and they must be re-addressed by hand.

Identity. The SMBIOS UUID and MAC addresses live in the configuration file. A copied configuration keeps the licensing identity. A guest rebuilt by hand with the replica disks attached gets new ones. The VM generation ID behaves in reverse. Backup restore, clone, and snapshot rollback regenerate it by design. A guest started from a replicated disk with a copied configuration keeps it, and nothing tells the guest it was recovered.

Warning: Preserved identity is what you want when the primary site is gone. It’s a hazard when it is still there. Two copies with the same MACs and addresses on connected networks conflict immediately, and services keyed to machine identity, especially Active Directory, can be damaged when a second machine shows up claiming to be the first. Recovered guests start only when the primary is confirmed down or isolated. Tests run on an isolated network.

Hardware and capacity. cpu: host presents the recovery host’s CPU to the guest, which licensed and pinned software notices. Custom CPU models and PCI or USB passthrough mappings are cluster local and travel separately or not at all. A smaller recovery site fits the load only if per-guest reductions were decided in advance. No admission control checks the sum.

The recovery itself: promote the replicas with the storage’s tools, place the configurations into /etc/pve, apply the prepared overrides, and start guests in dependency order. The list above decides how much of that is execution and how much is improvisation. Each unkept item becomes a failed start under disaster conditions. Failback reverses the replication or moves guests back individually with cross-cluster migration (qm remote-migrate, experimental, the mechanism under PDM).

What does not map

Consistency across guests comes from an array consistency group or from a hand-run recursive ZFS snapshot; no Proxmox tool provides either. Beyond consistency, SRM did four jobs with no Proxmox counterpart. Each gets done only if an administrator builds it and keeps it running.

Readiness. SRM showed a recovery plan’s health continuously: replication in compliance, placeholder machines registered, adapters reachable, errors visible before the plan was needed. The manually assembled implementation drifts silently. Whether replicas are current, configurations are paired, and namespaces are aligned is known exactly as often as a script checks.

Evidence. Recovery plans produced test histories and reports that satisfied auditors. Here the record is whatever the scripts log and whatever the operator writes down.

Reversal. A recovery plan that failed partway kept per-step state and could be cleaned up or re-run. A manual failover that fails partway leaves guest ownership split across two sites, promoted replicas that no longer replicate, and a return path that begins with resynchronization.

Day two. After a failover, SRM’s reprotect reversed the replication, and protection resumed in the new direction. A guest recovered at site B from promoted replicas and copied configurations exists in no backup job, no replication job, and no HA configuration. Recovered guests run unprotected from the moment failover completes until replication, backup, and HA are rebuilt in the other direction.

Recovery Plans, Testing, and What Site Recovery Manager Actually Was

An SRM recovery plan held protection groups in start order, per-machine priorities, address mappings, and scripts attached to defined steps. A button started it, and a report came out when it finished. Proxmox has nothing that holds a recovery plan. The plan is the runbook and scripts the administrator maintains outside the platform.

Of everything SRM automated, testing is the hardest to reproduce by hand. SRM’s test mode brought replicas up on an isolated network without interrupting replication. Cleanup put everything back, and recovery could be rehearsed without production noticing. Proxmox has no test mode. The rehearsal is built from ordinary operations. Clone the replicas or restore backups onto an isolated bridge. Verify what boots and what talks. Then destroy the test. Two rules keep it safe:

Never promote a real replica for a test, because promotion ends the replication relationship and re-establishing it means resynchronization.
Never let test guests reach a production network. A test guest carries the same MACs, addresses, and machine identity as the production guest it was cloned from.

Tip: Scheduled test restores from PBS onto an isolated bridge are the cheapest rehearsal available. They verify the backups, time the restore, and exercise the runbook, per guest, without touching replication.

Recovery plans, test mode, and reprotect were never part of vSphere itself. SRM was a separate product, licensed per protected machine and bought by the shops whose requirements justified it. It had troubles of its own. The SRA layer tied array firmware, adapter, SRM, and vCenter versions together in lockstep. Plenty of recovery plans existed for auditors and were never run.

Proxmox today is where vSphere was before SRM existed. It provides backup for every guest, HA within a cluster, and replication for guests on local ZFS. A recovery procedure can be built wherever the storage replicates. Moving the data is the easy part. Configuration management, identity, addressing, start order, testing, and reprotection remain the operator’s responsibility. Whether the answer is a runbook, scripts, or a purchased product, the recovery that works is the one that was rehearsed.

Feature Mapping in One Table

Native tooling only. Versions: Proxmox VE 9.2, Proxmox Backup Server 4.2, Proxmox Datacenter Manager 1.1, July 2026.

VMware capability	Proxmox equivalent	Status	Notes
vSphere Replication, within a site	`pvesr`	Limited, ZFS only	Local ZFS between nodes of one cluster. Takes a schedule, not an RPO.
vSphere Replication, cross-site	`pve-zsync`	Limited, ZFS only	Technology preview. ZFS to ZFS over SSH, crash-consistent snapshots, manual recovery.
CBT incremental backups	PBS with dirty bitmaps	Functionally equivalent	Same outcome. CBT’s tracking persists across power cycles and the bitmap’s does not. A lost bitmap costs a full read, not a full transfer.
Backup copies at a DR site	PBS sync jobs, pull or push	Equivalent	Recovery is restore-based on both platforms, a different RTO class than replication.
vSphere HA	HA manager	Functionally equivalent	Core behavior matches. vSphere HA is more full featured (admission control, restart priority tiers).
vSphere Fault Tolerance	None	None	No lockstep execution.
vCenter, multi-cluster management	Proxmox Datacenter Manager	Partial	Dashboards, guest views, and cross-cluster migration. Optional, and clusters do not depend on it.
vSAN stretched cluster	Ceph stretch mode	Limited, self-managed	Same 5 ms limit between data sites, same third site. A Ceph capability, with no site concept in the platform.
Array-based replication	SAN-native replication	Direct analog, SAN only	LUN granularity, with the array’s consistency groups. Proxmox is unaware of any of it.
SRA orchestration	None	None	Operator scripts. SRA certification itself ended in 2025.
SRM recovery plans	None	None	Runbook and scripts, maintained outside the platform.
SRM non-disruptive testing	None	None	Clones or restores on an isolated bridge. Never promote a replica for a test.
SRM reprotect and failback	None	None	Replication reversed by hand. `qm remote-migrate` for individual guests.
Recovery-time IP customization	cloud-init	Limited, Linux only	Prepared guests only. Cloudbase-Init for Windows not officially supported.

What This Document Did Not Cover

Third-party backup and DR products support Proxmox and were out of scope. The comparison covers only the tools that ship with Proxmox VE and vSphere. Application-level replication is a subject of its own. Databases and directory services that replicate themselves are often the right answer for the tightest recovery tiers.

We left one gap open on purpose. We have not operated Ceph RBD mirroring failover under sustained production load. Public operational reports are scarce. If you have run it through a real or rehearsed site failure, we would like to hear about it.

Mapping VMware DR Features to Proxmox VE: SRM, vSphere Replication, and Site Recovery

Scope and Method

Terminology: Reading VMware DR Concepts in Proxmox Terms

vSphere Replication and Storage Replication (pvesr)

Recovery after a node failure

Watching the recovery point

What does not map

Cross-Site Replication with pve-zsync

Recovery at the remote site

Watching the recovery point

What does not map

Off-Site Recovery with Proxmox Backup Server

The two-site pattern

Restore, and restore time

Watching the recovery point

What does not map

vSphere HA, Fault Tolerance, and the Proxmox HA Manager

vCenter, Cross-Site Visibility, and Proxmox Datacenter Manager

Stretched Clusters

What maps and what does not

Array-Based Replication, the Storage Layer, and Doing Site Recovery Manager’s Job by Hand

What a recovery plan replaces, item by item

What does not map

Recovery Plans, Testing, and What Site Recovery Manager Actually Was

Feature Mapping in One Table

What This Document Did Not Cover

Additional Resources

vSphere Replication and Storage Replication (`pvesr`)

Cross-Site Replication with `pve-zsync`