Michael Schmidt 
The question arrives late in most exit projects, usually from somebody who was not in the room for the platform decision. We have the migration plan, we have the storage plan, and we have a recovery plan that runs twice a year and has an auditor attached to it. What replaces Site Recovery Manager?
It is a harder question than it sounds, and the reason is a detail that gets lost because the product was so well integrated. Site Recovery Manager, renamed VMware® Live Site Recovery under Broadcom, never replicated anything. It moved no bytes of its own. It was an orchestrator with a console, and everything it orchestrated it did by calling somebody else: vSphere Replication for host-based per-VM copies, or the array, through a storage replication adapter, for array-based replication of whole consistency groups.
So the thing that disappears when vCenter leaves is not a console. It is a contract, between an orchestrator and a storage system, that had a certification programme behind it and a well-understood set of verbs. And a contract with two parties needs two owners once the party that defined it is gone.
We have written the suite-level answers already. What replaces vSphere HA, DRS and Fault Tolerance covers availability translation, and Day 2 storage operations after the VMware exit covers snapshots, replication and observability as a group. Both touch this subject in passing and neither takes it apart. This article is the narrower one: the storage side of the orchestration contract, what it was actually promising, and which parts of it you get back for free.
What Site Recovery Manager actually owned
Strip the interface away and the product held four things, none of which were data.
The first was the protection group: the set of things that fail over together. In an array-based configuration this was not a list of VMs, it was a list of replicated devices, because the array was replicating at the LUN or consistency-group level and the group was the smallest unit it could promote atomically. The second was the recovery plan: dependency order, boot sequencing, IP re-addressing at the recovery site, callouts and pauses, and the scripts that ran between steps. The third was the test recovery, which brought the protected workloads up at the recovery site on an isolated network, let you prove the plan, and then discarded the result without ever interrupting replication. The fourth was reprotect, the operation that reversed the direction of the relationship after a failover so that the recovery site became the protected one.
Underneath all four sat the storage replication adapter. The adapter was a per-array plug-in that implemented a fixed vocabulary: discover the arrays that are paired, discover which devices are replicated and in which direction, prepare a failover, execute it, create a writable test copy without breaking the ongoing replication, and reverse the relationship. That vocabulary is worth reading twice, because it is a complete specification of what a storage system has to do to participate in orchestrated disaster recovery, written by somebody who had to make it work across dozens of arrays.
The important structural point is that the orchestrator and the storage system were separate products with a defined interface between them, and the interface was the valuable part. Most estates never saw the seam, because one vendor sold the orchestration, the array vendor certified against it, and the whole thing arrived as a single operational surface. Take the orchestrator out and the seam is all that is left.
After vCenter, the contract has two halves
Both halves still exist after the exit. They just no longer live in the same place, and neither of them ships under a product category called disaster recovery.
The storage half answers four questions: which volumes travel together, how often a recovery point is taken, which site currently serves each volume, and who is allowed to say go. That half belongs to the storage layer, and it is the half that a storage product can genuinely own end to end.
The platform half answers the rest: what starts before what, what network identity a workload has at the recovery site, what validates that the thing came up correctly, and what a human is expected to do while it happens. In a Kubernetes estate that half is manifests, an operator, or a runbook. It is not storage, and a storage vendor that implies otherwise is selling you the easy half and calling it the whole thing.
Here is where each construct lands.
| Site Recovery Manager construct | Where it lands after vCenter | Who owns it | Exposure if nobody does |
|---|---|---|---|
| Protection group, the set that fails over together | A replication policy that volumes are enrolled into, plus group-scoped snapshots where one instant matters | Storage layer | Volumes fail over individually and the recovery point differs per volume |
| Recovery plan, dependency order and boot sequencing | Declarative manifests applied at the recovery site, with an operator or pipeline enforcing order | Platform team, in Git | Everything starts at once and the dependent tier restarts until the tier below it is ready |
| IP customisation and re-addressing | Service discovery and cluster networking at the recovery site | Platform team | Workloads come up healthy and unreachable |
| Test recovery into an isolated network | Assembled from a clone of a replicated snapshot in an isolated namespace | Shared, and nobody by default | The plan is never rehearsed, which is the same as not having one |
| Reprotect, reversing direction after failover | An explicit failback operation that reverses replication and commits | Storage layer | The estate runs indefinitely from the recovery site with no protection |
Table 1: The four things Site Recovery Manager owned, where each one goes after the hypervisor leaves, and what it costs you to leave the row unassigned.
In simplyblock the storage half is a small set of declared objects rather than a console, and it is worth being concrete because the shape maps closely onto the adapter vocabulary. A replication pair names the source cluster and the target cluster and provisions the relationship between them. A replication policy hangs off that pair and carries the cadence, the retention, and whether the target is a read-only standby for failover or the destination of a planned cutover. A volume is enrolled by naming the policy in an annotation, either on a single PersistentVolumeClaim or on the StorageClass so that everything provisioned from it is protected. Each enrolled volume then has its own slot holding the live state, the direction, and the timestamp of its last replicated snapshot, which is the closest thing to the adapter’s device discovery call.
Failover is a one-shot request, scoped to a single volume, to every volume on a policy, or to every volume replicating to a target cluster, and failback is the same mechanism in reverse. The scopes matter here more than they look: policy scope is the protection group, and it is what lets you move a service rather than a disk.
One design decision in that list deserves calling out, because teams arriving from a product with a big red button sometimes read it as a missing feature. Failover is never triggered automatically. That is deliberate, and the reasoning is the same reasoning that makes split-brain hard: cluster state on its own cannot distinguish a lost site from a transient network problem, and a storage layer that guesses wrong promotes a stale copy while the original is still taking writes. The decision to fail over a site is a human decision with a business consequence attached, and the honest engineering answer is to make it explicit rather than clever. Automatically restarting a workload on another node is a different problem with a different answer.
Rebuilding a recovery plan that used to live in a Site Recovery Manager console? If you have an audited failover procedure and an exit deadline in the same year, the storage half of it is worth designing before the migration rather than after the first failed drill. Talk to a storage architect
Consistency groups do not translate for free
This is the part that catches people, and it catches them late, which is the worst time.
In the array-based model the consistency group was not an organisational convenience. It was a guarantee about write ordering. A database with data on one device, write-ahead log on a second and index on a third is only recoverable if the three are captured at one instant relative to each other. Put them in one consistency group and the array promised exactly that. Put them in three groups and the promise is gone, even though every individual device replicated perfectly.
Kubernetes does not give you this by default. A VolumeSnapshot captures one persistent volume, and a replication schedule takes its recovery points per volume on its own interval. Group everything under one policy and the failover request covers the whole group, which is genuinely useful, but group scope and group consistency are two different properties. Scope answers “what moves together.” Consistency answers “do the copies represent the same moment.” You can have the first without the second, and a recovery plan built on the first alone will restore a database whose log is a few seconds ahead of its data files.
There are three levels here and they are worth naming separately, because the cost and the mechanism differ at each one.
| Level | What it guarantees | How you get it | When you actually need it |
|---|---|---|---|
| Per-volume crash consistency | Each volume is individually recoverable, like a clean power loss | Any volume snapshot, taken per volume | Single-volume workloads, and anything that reconstructs its own state on start |
| Group crash consistency | One write-order-consistent instant across several volumes | A group snapshot taken across the set, not several snapshots taken quickly | Multi-volume databases, and any VM whose disks reference each other |
| Application consistency | The application has flushed and quiesced before the capture | Application hooks or a freeze, layered on top of a group snapshot | Anything with an in-memory write buffer you cannot afford to replay |
Table 2: Three levels of consistency, the mechanism that delivers each one, and the workloads that make the next level up worth its cost.
The middle row is the one that used to arrive with the array and now has to be asked for. In Kubernetes the mechanism is VolumeGroupSnapshot, which exists precisely to capture one coherent moment across a set of claims, and we have written about how to define protection boundaries with it by business service rather than by convenience. The practical instruction for a recovery plan is short: work out which of your services live on more than one volume, and check that each of those sets is one group rather than several volumes that happen to share a schedule. On the top row, application consistency is not a storage feature at all and never was, which is why application-consistent backups are a separate discipline with database-specific hooks.
Do not extend this into a replication-factor argument while you are here. How many local copies a volume keeps is a different decision, made for a different reason, and the double replication tax on database storage works through it properly.
The rehearsal is the feature you have to assemble
Ask a team that has run Site Recovery Manager for five years which part of it they valued and the answer is rarely the failover. It is the test. A non-disruptive recovery test, into a bubble network, on the real replicated data, discarded afterwards, with replication never interrupted, is what turned a documented procedure into an audited capability. It is also the single hardest part to replace, and it is worth saying plainly that there is no equivalent one-button operation waiting for you on the other side.
In simplyblock the two operations are failover and failback. There is no test-failover verb, and pretending otherwise would be the kind of claim that fails at the worst moment. What does exist are the primitives it is built from. The target cluster holds an incremental chain of replicated snapshots rather than a single opaque mirror, and a clone is a writable, independent copy created from a snapshot without copying the data. That is the shape of a rehearsal: clone the most recent replicated snapshot at the recovery site, bring the workload up from the clone in a namespace whose networking cannot reach production, run the validation you would run for real, then delete the clone. The replication relationship is untouched throughout because nothing was promoted.
That gets you the storage half of the rehearsal. The other half, the part the recovery plan used to hold, is the order things start in and the identity they have when they do, and nobody inherits that automatically. If your dependency order exists only as institutional memory held by two people, the migration is the moment it has to become a manifest, a pipeline, or at minimum a written runbook with a date on it. This is the same conclusion that storage disaster recovery on Red Hat® OpenShift® reaches from the platform side, and DR volume workflows reaches from the volume side. For the rehearsal itself, step by step, with the verification gate and rollback for each stage, see disaster recovery testing after the vSphere exit.
Two more honest notes before you plan around any of this.
Failback is not free of disruption. It runs in two phases for a good reason: the bulk of the delta accumulated at the recovery site is transferred while that site is still serving traffic, and only the remainder is transferred during a short freeze at the commit. That keeps the freeze small, but it is still a freeze, and production failbacks want a maintenance window rather than optimism. And if the original site is genuinely gone rather than temporarily down, what you are doing is not a failback at all. It is a new replication relationship to a new cluster, seeded from scratch, and it should be planned with the timeline of a full copy rather than the timeline of a delta.
What simplyblock brings to the storage half beyond the mechanics is mostly about not narrowing your options while a multi-year exit is still running. The same product runs hyperconverged, with storage and compute on the same nodes, or with the two separated so each scales on its own axis, and that is a deployment choice rather than a purchase you have to get right on day one. It does not pick your platform: the same storage layer serves KubeVirt, OpenShift Virtualization, and bare-metal Kubernetes, which matters more than usual in a DR design because the recovery site is frequently the place where an estate is standardising on the new platform first. And enrolment being an annotation on a StorageClass means protection tiers are expressed the same way every other storage property is expressed, so a workload’s recovery posture is a property of the class it asks for rather than a ticket somebody files.
The takeaway is smaller than a product recommendation. Open your existing recovery plan, find the steps that the orchestrator was performing on your behalf, and put a name next to each one. Most of them have a good answer. The two that usually do not are the group boundary and the rehearsal, and both are much cheaper to fix now, on a whiteboard, than during the first drill after the console is gone.
Questions and Answers
What replaces VMware Site Recovery Manager after a migration to Kubernetes?
Two things, because Site Recovery Manager was two things. The replication and promotion half belongs in the storage layer: a replication relationship between two clusters, a policy that sets the cadence and the retention, volumes enrolled into that policy, and an explicit failover request that promotes every volume in scope at the recovery site. With simplyblock that is a small set of declared resources rather than a console, and failback reverses the same relationship. The orchestration half, meaning dependency order, boot sequencing, network identity and validation, becomes declarative configuration held in Git and applied at the recovery site, enforced by an operator or a pipeline. Do not look for a single product that replaces both halves. Look for a clear owner for each, and write both into the same recovery document.
Does simplyblock support consistency groups like an array-based SRM configuration did?
Partly, and the distinction matters enough to be precise about. A replication policy is the group for the purposes of failover: every volume enrolled in a policy can be failed over or failed back in one request, which is the protection-group behaviour you want. What a policy does not on its own guarantee is that the recovery points across those volumes represent a single write-ordered instant, because replication takes its snapshots per volume on the policy interval. Where a service spans several volumes and the ordering between them matters, use a group snapshot across that set so the capture is one coherent moment, and layer application quiescing on top if the workload buffers writes in memory. Identify the multi-volume services in your estate first, then check each one is a group rather than a coincidence of schedule.
How do we run a non-disruptive DR test without Site Recovery Manager’s test failover?
Build it from a clone rather than from a promotion. The recovery site holds an incremental chain of replicated snapshots, and a clone is a writable independent copy created from a snapshot without copying data, so cloning the latest replicated snapshot gives you real production data to test against while the replication relationship continues untouched. Bring the workload up from that clone in an isolated namespace whose networking cannot reach production, run your validation, then delete the clone. There is no single test-failover operation in simplyblock, so this is assembled rather than bought, and it should be scripted and scheduled like any other drill. Rehearse the order and the network identity at the same time, since that is the half the old recovery plan was holding for you.
Is failover automatic, and should it be?
It is not automatic in simplyblock, and that is a design decision rather than a gap. Cluster state alone cannot tell a lost site from a transient network partition, and a layer that guesses wrong promotes a stale copy at the recovery site while the original is still accepting writes, which is a worse outcome than a few minutes of downtime. Site failover is requested explicitly, scoped to one volume, one policy, or every volume replicating to a target cluster. Automatic recovery is the right answer one level down, where a workload restarting on a healthy node after a node failure needs no human at all, and that is a separate mechanism from site failover. Keep the two apart in your design and in your runbook.
What RPO should we expect after replacing vSphere Replication?
Minutes, set by the replication interval you choose, plus any lag when the interval cannot keep up with the write rate. Asynchronous replication between clusters transfers snapshots on a schedule, so the data written since the last successful transfer is not present at the recovery site after a failover, and the gap is at least one interval. Shortening the interval shrinks the gap and raises the transfer load, which is the same trade vSphere Replication asked you to make. If a workload genuinely cannot lose minutes, asynchronous replication is the wrong tool for that tier and you want synchronous writes across two sites instead, which is a different architecture with a latency cost on every write. Two-site synchronous storage after the VMware exit covers when that cost is worth paying.
