By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
At 3:12 a.m. the storage array in your primary site logs a second drive failure inside the same RAID group, and the datastore drops offline. Forty production VMs stop answering. You have backups, last night’s job finished clean, and that is the trap: a clean backup tells you the data existed at 11 p.m., not how fast the payroll app answers again. The business on the phone is not asking whether you have a backup. It asks how long until the service is back, and whether anything since last night is gone for good.
Those two questions, how long and how much lost, are the whole of disaster recovery. Backup is a copy of data at rest. Disaster recovery is the machinery that brings running services back inside a time you promised, at another site, in the right order, without you hand typing forty sets of network settings while the phone rings. VMware Cloud Foundation 9 folds that machinery into the platform in a way earlier releases did not, and it also renamed most of the parts, which is its own small disaster. This part sorts out what is backup, what is DR, and what genuinely changed.
The short version
Backup protects the bytes. DR protects the service level: the recovery time you can hit and the data loss you can tolerate. In VCF 9 the on-premises DR pieces (the tool once called Site Recovery Manager, vSphere Replication, and vSAN Data Protection) now ship as one appliance, the umbrella product was renamed from VMware Live Recovery to VCF Protection and Recovery in the 9.1 release, and enhanced replication can hold a one minute RPO on a subscription. None of that recovers anything on its own. A tested recovery plan does. If you run VMware infrastructure and someone will call you at 3 a.m. when a site fails, this series is written for you.
Backup answers a different question
A backup is a point in time copy you keep so you can go back to it: a deleted file, a corrupted table, a ransomware event from three weeks ago, a retention rule an auditor cares about. It is measured in versions and retention. Its job is to still have the data. Restore speed is a secondary concern, which is why pulling fifty VMs back from a nightly job can run for hours while everyone waits.
Disaster recovery is measured in time and loss. Two numbers define it. Recovery Time Objective is how long the service can be down before it hurts. Recovery Point Objective is how much recent data you can lose. DR is the replication that keeps a second copy current at another site, plus the orchestration that powers VMs on in dependency order, remaps their networks, and reports whether it worked. Backup can be one input to a DR strategy. It is not, by itself, disaster recovery, and calling a nightly backup your DR plan quietly signs the business up for a 24 hour RPO nobody agreed to.
| Capability | Question it answers | Typical RPO | Typical RTO | Use it for |
|---|---|---|---|---|
| Backup | Do I still have the data | Hours to a day | Hours | Corruption, deletion, retention, long term recovery |
| Disaster recovery (VMware Live Site Recovery) | How fast is the service back, how much is lost | 1 minute to hours | Minutes to under an hour | Site or storage failure, planned site moves |
| Cyber recovery (VMware Live Cyber Recovery) | Can I recover clean after ransomware | Minutes to hours | Hours | Ransomware, using an isolated clean room |
The gap shows up most clearly in recovery time. Restoring fifty VMs from a nightly backup means reading them all back from backup storage before anything boots. An orchestrated recovery plan boots VMs that are already replicated and sitting at the recovery site, in dependency order, in minutes. Same failure, very different clock.
What VCF 9 actually changes
One appliance instead of three
For years a DR build meant three separate things to deploy, patch, and version match: the Site Recovery Manager servers, the vSphere Replication appliances, and whatever handled data protection. Each had its own lifecycle and its own row in the interop matrix. Starting with the 9.0.3 release, the on-premises components ship as a single VMware Live Recovery appliance that carries VMware Live Site Recovery, enhanced vSphere Replication, and vSAN Data Protection together. One deploy, one patch, one version to check against vCenter. That is a real reduction in the work of keeping DR itself alive, which is work that used to get skipped.
The names changed, more than once
Here is the part that trips people up in docs and tickets. Site Recovery Manager became VMware Live Site Recovery. VMware Cloud Disaster Recovery became VMware Live Cyber Recovery. The umbrella that held both, VMware Live Recovery, was itself folded into VMware Cloud Foundation and renamed VCF Protection and Recovery in the 9.1 release, which shipped on 12 May 2026, with a 9.1.0.0100 patch following in June. Search a two year old blog post and you will find three names for the same feature. When a colleague says SRM in 2026, they mean VMware Live Site Recovery. I will use the current names in this series and flag the old ones the first time they matter.
From the field: the one minute RPO is a license, not a checkbox
The marketing says one minute RPO. What bit a team I worked with is that the one minute floor comes with the VMware Live Recovery subscription and its enhanced replication. On legacy Site Recovery Manager licensing the floor is five minutes, and the UI does not shout about why the slider stops where it does. They had scoped a design around a one minute RPO, then discovered at build time that their existing entitlement could not deliver it. Confirm the entitlement before you promise the number, because the slider limit is set by what you bought, not by the appliance.
RPO and RTO decide everything downstream
Every DR design choice traces back to these two numbers, so it is worth being blunt about how they push the design. RPO sets how often data must move, which sets the replication method and the bandwidth. RTO sets how fast services must boot, which sets how much you keep warm at the recovery site and how much you orchestrate. A tight RPO with a loose RTO and a loose RPO with a tight RTO are different builds with different bills.
With vSphere Replication you set the schedule per VM, anywhere from 1 minute to 24 hours. Two limits matter in practice. The 1 minute floor needs the subscription entitlement, as above. And the aggressive end is not free of constraints: the 5 minute RPO is recommended for at most 500 VMs, and both source and target need to sit on vSAN, VMFS, NFS, or vVols. Array based replication can push RPO down toward seconds, but it ties both sites to matched, compatible arrays, and as of August 2025 Broadcom no longer certifies new storage replication adapters even though array based replication stays supported.
| Approach | Best RPO | Data loss on failure | Constraint to watch |
|---|---|---|---|
| Nightly backup | 24 h | Up to a full day | Restore time measured in hours |
| vSphere Replication, standard | 5 min | Up to 5 minutes | 5 min RPO for at most 500 VMs |
| Enhanced vSphere Replication | 1 min | Up to 1 minute | Needs subscription entitlement |
| Array based replication | Seconds | Seconds | Matched arrays, SRAs no longer certified |
| Planned migration | Zero | None, graceful shutdown first | Only for planned moves, not a live disaster |
Sizing the pipe: a worked example
RPO is a promise your bandwidth has to keep. If the link cannot move a replication window of changes inside that window, the RPO slips and the tool starts reporting it, usually right when you stop watching. Here is the arithmetic I run before quoting a number.
Worked example: 2 TB of protected VMs
Say you protect 2 TB of VMs that change about 5 percent a day, so roughly 100 GB of new data daily. To hold any tight RPO you must move that 100 GB across the day as it changes. Averaged out, 100 GB is 800 gigabits, spread over 86,400 seconds, which is about 9.3 Mbps of steady replication traffic. Change is bursty, not flat, so size for a peak of two to three times the average, call it 20 to 28 Mbps, before you count overhead.
Then there is the first sync, which people forget. Seeding the full 2 TB across a 50 Mbps link takes about 91 hours, close to four days, during which you have no protection yet. That is why you seed over a fast local link or ship a seed before you rely on the schedule.
What to validate before you rely on this
- The entitlement, not the brochure. Confirm your license tier actually delivers the RPO floor you designed around before you commit to it.
- Real change rate, measured. The 5 percent daily figure is a starting guess. Pull the actual change rate from your storage or replication reports, because a busy database can change far more.
- Peak, not average, on the link. Average bandwidth passes on paper and fails at the daily backup window. Size for the burst.
- The first sync plan. Know how you will seed the initial full copy and how long you are unprotected while it runs.
- Consistency level. vSphere Replication gives VSS application consistency on Windows and file consistency elsewhere, so confirm a database will come up clean, not just powered on.
Before any real test or failover: a recovery plan test spins up isolated copies, but a real failover or planned migration shuts down or moves production. Run those in a change window, tell the application owners, and never point a first test at a plan you have not read line by line.
Where I disagree with the default
Two common beliefs deserve pushback. First, that immutable backups cover ransomware. They do not, on their own. Modern ransomware can sit dormant inside backups and reinfect after a restore, and fileless attacks slip past traditional file scanning entirely. That is the whole reason cyber recovery adds an isolated clean room and behavioral analysis rather than just another immutable copy. An immutable backup is necessary and not sufficient.
Second, the vendor will happily sell you a one minute RPO for everything. I would not buy it for everything. A one minute RPO on a static file server wastes bandwidth to protect data that barely changes, while the tier that actually needs it, the transactional database, is where you should spend the link. Match RPO to the workload tier. Buying the smallest number across the board is a budget line that impresses an auditor and helps no one at 3 a.m.
What I would actually do
Stand up VMware Live Site Recovery with enhanced vSphere Replication and design in two or three tiers, not one. Put your transactional workloads on a 1 to 5 minute RPO, general server workloads on 15 minutes to an hour, and let the rest ride the nightly backup. Keep a separate backup regardless, because DR replicates your mistakes as fast as your data. Then test the recovery plan on a schedule, because an untested plan is the single most common thing that turns a manageable outage into a bad night.
Questions I actually get
If I have good backups, do I still need DR?
Yes, if the business cannot wait hours for a restore or lose a full day of data. Backup and DR answer different questions. Keep the backup for corruption, deletion, and retention, and add DR for the recovery time and data loss targets the service actually has.
Is Site Recovery Manager gone?
The name is. The product is now VMware Live Site Recovery, and in VCF 9 it lives inside the single VMware Live Recovery appliance, which as of the 9.1 release is branded VCF Protection and Recovery. Your Site Recovery Manager skills carry straight over, and legacy licenses keep working until the term ends.
What RPO can vSphere Replication really hit?
The schedule is configurable per VM from 1 minute to 24 hours. The 1 minute floor needs the subscription with enhanced replication, legacy licensing floors at 5 minutes, and the 5 minute setting is meant for at most 500 VMs on supported datastores. Bandwidth and change rate decide whether you actually hold the number you pick.
Does DR protect me from ransomware?
Not by itself. Replication faithfully copies encrypted data to the recovery site too. Ransomware needs cyber recovery: immutable snapshots, an isolated recovery environment to validate in, and behavioral analysis to catch a dormant payload before you restore it. That is a separate stack, covered later in this series.
Where this goes next
Get the vocabulary right and the rest of DR stops feeling like guesswork. Backup keeps the data. DR keeps the service level. VCF 9 puts the DR machinery into one appliance and renamed it more than once, but the appliance is not the plan. The plan is the recovery plan you write, size for, and test. Part 2 takes the two numbers that ran through this piece, RPO and RTO, and turns them into an actual design: how to tier workloads, and how those targets set every choice that follows.
Start by writing down the RTO and RPO the business assumes it has, then measure what your current setup actually delivers. The gap between those two is your DR project.
VMware Live Recovery for VCF 9 · Part 1 of 14
Series guide: VCF 9 Disaster Recovery: the complete guide
Next: Part 2, RPO and RTO, and how they drive design
Related: the VCF 9 Operations series covers day 2 operations for the same platform.
Continue the series: Part 2 on RPO and RTO turns these ideas into design numbers, Part 3 maps the VMware Live Recovery family, and Part 8 shows how to prove any of it without touching production.
References
- VMware Live Recovery Frequently Asked Questions, January 2026
- Build numbers and versions of VCF Protection and Recovery, formerly VMware Live Recovery
- Operational limits of vSphere Replication, Broadcom TechDocs
About The Author
DrJha