By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
The failover test was booked for a Saturday morning. The team had bought VMware Live Recovery months earlier, signed the budget, and told the business that the second data center was covered. When they opened the console to run the recovery plan, the plan was not there. What they had licensed and deployed replicated virtual machines into a cloud file system in AWS, not into the racks sitting forty miles down the road. Nobody had lied. They had bought one product with two very different engines inside it, and assumed the name meant one thing.
That is the trap in the current lineup. VMware Live Recovery is a single subscription and a single console, but underneath it sit two independent stacks that recover workloads in almost opposite ways, plus a third mover that most people forget they already own. If you keep services alive through failure, the first job is not configuring replication. It is knowing which engine you are holding, what it does at 3 a.m., and what it will refuse to do.
The short version
VMware Live Recovery is an umbrella over two stacks. VMware Live Site Recovery orchestrates on-prem site to site failover. VMware Live Cyber Recovery is cloud-delivered and built for ransomware. vSphere Replication and vSAN Data Protection do the actual copying. If someone handed you a Live Recovery subscription and told you DR is sorted, read the engine, not the label. This part is written for the admin who has to make it work, not the person who signed the order.
One label, two engines, and a mover you already own
VMware renamed the disaster recovery portfolio and folded it under VMware Live Recovery. The rename tidied the marketing and muddied the field. The word you see on the invoice now covers three technologies that behave nothing alike, and the daily job of an admin is to keep them straight. Get RPO and RTO right first, which is the subject of Part 2, then choose the engine that can actually hit those numbers.
VMware Live Site Recovery, the on-prem orchestrator
This is the renamed Site Recovery Manager. It orchestrates recovery between two of your own vSphere sites, and it does one thing that no backup product does well: it runs a recovery plan in a known order, tests that plan without disrupting production, and reverses it cleanly with reprotect and planned migration. It supports on-prem site to site disaster recovery. It does not fail workloads over to VMware Cloud on AWS. That single sentence would have saved the team in the opening story their Saturday.
Live Site Recovery leans on an underlying replication engine, either vSphere Replication or third-party array-based replication through a storage replication adapter. The documented scale is generous: protection for up to 1500 virtual machines, up to 250 recovery plans, and up to 10 recovery plans running at once. Those are ceilings, not targets. Most real recovery plans are far smaller and far more carefully ordered, because the database tier has to be ready before the application tier starts asking it questions.
VMware Live Cyber Recovery, the cloud engine for ransomware
This is the renamed VMware Cloud Disaster Recovery, and it is a different animal. It is delivered as a service. You deploy a Connector appliance on your source site, and it ships immutable virtual machine backups into a cloud storage layer called the Scale-out Cloud File System, kept in native vSphere format so there is no brittle conversion at recovery time. When you need to recover, a live mount makes the data available over NFS to hosts in a VMware Cloud on AWS software defined data center without a slow rehydration, and pilot light hosts make that even faster. Minimum two pilot light nodes stay subscribed all the time.
What sets this stack apart is ransomware recovery. Recovered snapshots land first in an Isolated Recovery Environment, a clean room where embedded next generation antivirus and behavioral analysis scan the running workload for indicators of compromise, and push-button network isolation stops reinfection while you validate. Compliance checks run every 30 minutes so you find out that a plan is broken on a Tuesday, not during the incident. With VCF 9.0 and VLR 9.0.3 you can also build that clean room on-premises, storing immutable snapshots in a vSAN data vault and using an EDR of your choice, if regulation or data sovereignty keeps you out of the public cloud.
vSphere Replication and vSAN Data Protection, the movers
Neither stack copies data by itself. vSphere Replication is the hypervisor-based, storage-independent engine that tracks changed blocks per virtual machine and ships them on a schedule you choose, from a 1 minute RPO up to 24 hours. It is included in the Live Recovery entitlement and it is the default partner for Live Site Recovery when you do not have array-based replication. vSAN Data Protection is the quiet third option: native snapshots on vSAN ESA storage, managed from the vSphere Client, that give you fast local rollback from a bad change or an accidental delete. Local snapshots need no add-on entitlement; replicating them to a remote vSAN ESA cluster needs the Live Recovery subscription. Treat it as the cheap first line of defense you probably already own.
| Engine | RPO floor | Topology | Where recovery data lives | Best for |
|---|---|---|---|---|
| Live Site Recovery + vSphere Replication | 1 minute | On-prem site to site | Your recovery site storage | Orchestrated site failover and migration |
| Live Site Recovery + array-based replication | Array dependent | On-prem site to site | Recovery array | Large, latency-sensitive datasets |
| Live Cyber Recovery | Snapshot based, coarser | On-prem to VMware Cloud on AWS | Scale-out Cloud File System | Ransomware recovery, no second site |
| vSAN Data Protection | Minutes, local | Same cluster or remote vSAN ESA | vSAN ESA snapshots | Fast local rollback, cheap first line |
Table 1. The engines side by side. RPO floors are the best case each engine permits, not what your license entitles.
Which engine catches which failure
The mistake is to pick an engine because it came in the bundle. Pick it from the failure you are covering. A blown storage array or a flooded room is a site problem, and Live Site Recovery with replication to a second data center answers it. A fat-fingered change or a dropped table is a local problem, and a vSAN Data Protection snapshot rolls it back in seconds without a site failover. A ransomware detonation is a trust problem, because your primary copies may already be poisoned, and that is the clean room job that Live Cyber Recovery was built for.
From the field
Two things bite teams who read only the datasheet. First, the 1 minute RPO on enhanced vSphere Replication is not free with old paper. Legacy Site Recovery Manager licenses cap enhanced replication at 5 minutes. Only the Live Recovery subscription gives you the 1 minute floor and vSAN Data Protection replication. I have watched a team promise a 1 minute RPO to an application owner while running on licenses that could never deliver it.
Second, as of 20 August 2025 Broadcom stopped certifying new Storage Replication Adapters. Array-based replication still works and stays supported, but your storage partner now develops and distributes the adapter on their own site. If your DR design assumes a freshly certified SRA from a vendor matrix, check the partner directly before you commit the architecture.
Here is where I part company with the common advice. The current messaging nudges everyone toward cloud-delivered DR as the modern default. For a large set of shops that is the wrong reflex. If you already own a second site, Live Site Recovery with vSphere Replication is simpler, cheaper to run, and faster to recover than standing up an SDDC in AWS, paying for pilot light nodes month after month, and absorbing egress on failback. Cloud earns its place when the failure is ransomware, or when you genuinely have no second data center. It should not be the automatic answer just because it is the newest box on the slide.
Size the pipe before you promise the RPO
An RPO is a promise about the network as much as the software. vSphere Replication ships changed blocks, so the number that matters is your daily change rate, not the size of your disks. Work it from real data, then add headroom for the resync that follows any outage.
Worked example
Take 40 virtual machines, 8 TB of used capacity, and a measured daily change rate of 4 percent. That is 320 GB of changed data per day. Spread evenly, 320 GB over 86,400 seconds is about 3.7 MB per second, roughly 30 Mbps of steady replication traffic.
Add about 40 percent for protocol overhead, retransmits and the fact that change is never perfectly even, and you land near 42 Mbps. Provision a 50 Mbps committed path and you have room for the burst after a link outage, when the engine has to catch up on everything it missed. Promise a tight RPO on a 20 Mbps pipe and the replication falls behind, silently, until the day you need it.
There is a counterintuitive twist here that the datasheet will not warn you about. A tighter RPO does not always cost the same bandwidth as a looser one. vSphere Replication only sends the net change since the last sync, so a longer RPO can coalesce repeated writes to the same block and ship it once. On a write-heavy virtual machine that overwrites the same blocks all day, a 1 minute RPO can transfer more total bytes than a 15 minute RPO, because it captures every intermediate state instead of the final one. Set the RPO to the business need, then confirm the pipe can carry the churn it actually produces.
| Capability | Legacy SRM license | Live Recovery subscription |
|---|---|---|
| vSphere Replication minimum RPO | 5 minutes | 1 minute |
| vSAN Data Protection replication | No | Yes |
| On-prem ransomware validated solution | No | Yes |
| Cloud DRaaS and IRE via Live Cyber Recovery | No | Yes |
Table 2. What the subscription buys over legacy paper. The 1 minute RPO line is the one that catches teams out.
What to validate before you rely on this
Confirm which stack your subscription actually entitles and which one is deployed, not which one you think you bought. Confirm the RPO floor your license permits, 1 minute or 5 minutes. Confirm Live Site Recovery is on-prem site to site for your case and that cloud recovery is a Live Cyber Recovery job. Confirm your storage vendor still ships the SRA you depend on after the certification change. Confirm your pilot light node count and egress assumptions if you use Live Cyber Recovery. And measure the real change rate on the workloads you are protecting before you commit a bandwidth number to anyone.
Before you touch a live failover
A real failover, reprotect or planned migration changes production. Reprotect reverses the direction of replication, and a mistimed failback resyncs data across your link and can overwrite the wrong side if you get the sequence wrong. Always exercise the recovery plan in test mode first, inside the isolated test network, where nothing touches the running site. Never rehearse a plan for the first time during the incident it was meant to survive.
What I would actually do
If you own two sites, make Live Site Recovery with vSphere Replication the backbone, and keep vSAN Data Protection as the cheap local first line for fast rollback. Reserve Live Cyber Recovery for ransomware or for sites with no DR home of their own. Buy the Live Recovery subscription rather than clinging to legacy SRM paper, specifically for the 1 minute RPO and vSAN Data Protection replication. And do not let one shared console convince anyone that the two stacks are interchangeable, because on a Saturday morning they are not.
Questions I actually get
Is VMware Live Recovery just Site Recovery Manager with a new name?
No. Live Site Recovery is the renamed SRM stack, but Live Recovery also includes the cloud Live Cyber Recovery stack and bundles vSAN Data Protection in the appliance. The name covers three technologies, not one, and they recover in different ways.
Can I fail over to VMware Cloud on AWS with Live Site Recovery?
No. Live Site Recovery is on-prem site to site. Recovering into an AWS software defined data center is Live Cyber Recovery. Confusing the two is the most common and most expensive mistake in this portfolio.
Do I need both stacks?
Usually not for pure disaster recovery. If you have a second data center, Live Site Recovery with vSphere Replication covers site failure. Add Live Cyber Recovery when the threat is ransomware or you lack a recovery site. Dual protecting a single VM needs array-based replication and two entitlements.
What RPO can vSphere Replication actually give me?
From 1 minute to 24 hours per virtual machine, but the 1 minute floor requires the Live Recovery subscription. Legacy SRM licenses cap enhanced replication at 5 minutes. Tight RPOs also cost bandwidth and, on write-heavy VMs, can move more data than a looser one.
Should I still design around vVols replication?
No. In VCF 9.0 and vSphere Foundation 9.0 the vSphere Virtual Volumes capability is deprecated and slated for removal in a future release. Live Site Recovery 9.0.3 still supports it, but the guidance is to migrate your Virtual Volumes replications to array-based replication now rather than build new designs on it.
Know the engine, not just the label
Map your workloads to the failures they face, then to the engine that answers each one. Read Part 1 on why DR is not backup, and Part 2 on the two numbers that drive every design choice.
Open the complete DR guide« Previous: Part 2 | VMware Live Recovery Complete Guide | Next: Part 4 »
References
VMware Live Recovery Frequently Asked Questions, January 2026
Overview of VMware Live Site Recovery, Broadcom TechDocs
vSAN Data Protection in VMware Cloud Foundation, VCF Blog
About The Author
DrJha