By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
The worst DR runbook for a ransomware event is the one you are proudest of. You press the failover button, your recovery plan powers on the estate at the second site in the order you rehearsed, and forty minutes later the same encryption is spreading through the recovered virtual machines. Replication did its job. It faithfully copied the ransomware to your DR site along with everything else, and your last replicated state is the state the attacker wanted you to keep.
Disaster recovery and cyber recovery are not the same problem, and in VCF 9 they are not the same product. Site to site DR runs on VMware Live Site Recovery, the engine that used to be Site Recovery Manager and vSphere Replication. Ransomware recovery runs on VMware Live Cyber Recovery, the cloud service that used to be VMware Cloud DR. Both live under the VMware Live Recovery umbrella, and the difference between them is the whole point of this part.
Why replication is not a recovery point
Replication has one job: make the copy look exactly like the source. That is precisely what you want for a power failure or a flooded data center, and precisely what you do not want after an intruder has been living in your environment for three weeks. By the time anyone notices the encryption, your continuous replication has already shipped the encrypted blocks to the DR site, and your most recent recovery points are the least trustworthy ones you own.
Ransomware recovery inverts the assumption behind DR. Instead of the newest copy, you want the newest copy that predates the compromise, and you cannot know which one that is until you have inspected several of them. That inspection cannot happen in production, because powering on an infected virtual machine to look at it is how lateral movement spreads. It needs a separate, network restricted place to work. That place is the Isolated Recovery Environment.
What the Isolated Recovery Environment actually is
The IRE, which the documentation also calls a clean room, is a recovery SDDC that VMware Live Cyber Recovery stands up on demand with predefined network isolation levels. You do not build it from scratch or stitch together spare hardware and forensic tooling. It is a dedicated, network restricted environment where you can safely power on infected virtual machines, watch how they behave, and decide whether a given recovery point is worth keeping.
Immutable snapshots in the SCFS
The recovery points themselves live off site in the Scale-Out Cloud File System, kept immutable so the attacker cannot reach back and tamper with your history. A protection group can accumulate hundreds of these points. When you launch a ransomware recovery plan, the SCFS presents the snapshots you select directly to the recovery SDDC. They are mounted for inspection, not copied into a running production estate, which is the structural reason the clean room stays clean.
Isolation levels, and the one that surprises people
Each virtual machine powers on inside the IRE attached to a network isolation level. The default is Quarantine plus Analysis, and here is the part that catches teams out: it is not a total air gap. That default deliberately allows a few basic services so analysis can run, including DNS, DHCP and NTP, plus outbound access to the Carbon Black Cloud endpoint that scores the machine. If you assumed clean room meant zero packets in or out, the default will not match your mental model. You can drop a machine to a stricter Isolated level, or build a custom isolation level, but you choose that on purpose.
Finding the last clean snapshot
VMware Live Cyber Recovery exposes a snapshot timeline with change rate, entropy rate and other metrics for each recovery point. The workflow is iterative by design. You pick a candidate, power it into the IRE under quarantine, let the integrated Carbon Black analysis look for suspicious operating system behavior, malware file signatures and known vulnerabilities, and if it is dirty you try an older snapshot. You repeat until a snapshot comes back clean. The entropy line is what tells you roughly where to start so you are not blindly walking backward one point at a time.
Retention schedule, in numbers
| Tier | Frequency | Kept for | Points | Candidates after 21 day dwell |
|---|---|---|---|---|
| Short | Every 4 hours | 3 days | 18 | 0 |
| Medium | Daily | 30 days | 30 | 9 |
| Long | Weekly | 12 weeks | 12 | 12 |
| Total | ~84 days reach | 60 | 21 |
The recovery loop, step by step
Guided recovery is a loop, not a single button. You select a snapshot, validate it in isolation, and either promote it or reach for an older one. The mechanics of the loop matter because the pressure to skip a step is highest exactly when skipping is most dangerous.
Ransomware recovery versus DR failover
These two workflows share vocabulary, recovery plans and protection groups, which is exactly why teams reach for the wrong one under pressure. The table lays out where they diverge.
| Dimension | DR failover (Live Site Recovery) | Ransomware recovery (Live Cyber Recovery) |
|---|---|---|
| Recovery source | Latest replicated state | Chosen point from deep immutable history |
| Goal | Restore newest, minimize data loss | Restore newest point that predates the compromise |
| Validation | Boot and service checks | Behavioral and vulnerability analysis in isolation |
| Network posture | Recovered VMs join the recovery network | Quarantine isolation until proven clean |
| Iteration | Run the plan once | Try multiple snapshots until one is clean |
| Right call when | Hardware, power or site loss | Encryption or intrusion suspected |
- Your snapshot retention reaches past a realistic dwell window measured in weeks, not just your RPO window of hours or days.
- The recovery SDDC region has the capacity to host your protection group when you actually call for it. On demand does not mean unlimited.
- No private connectivity exists between production and the IRE. No VPN, no Direct Connect, no stretched L2, no shared SDDC group.
- Carbon Black sensors are deployed where you expect analysis. Without them you lose the integrated behavioral scoring inside the clean room.
- You have rehearsed a full IRE recovery, not only a DR failover. The two are different muscles.
Questions I actually get
Is ransomware recovery just failing over to my DR site?
No, and treating it that way is how people reinfect themselves. Replication copies whatever is on the source, encryption included, so your latest replicated state is often the compromised one. Live Cyber Recovery instead keeps a deep immutable history and validates candidate points in isolation before you commit.
How far back should my snapshots reach?
Past a realistic attacker dwell window, which is usually weeks rather than hours. If your history only covers your RPO window, every recovery point may already carry the implant. Tier your retention so a few sparse points reach back months.
Does the clean room really have no network at all?
Not by default. The default Quarantine plus Analysis level still allows DNS, DHCP, NTP and outbound access to Carbon Black Cloud so analysis can run. Use the stricter Isolated level or a custom level if you need a tighter posture, and never wire a VPN or Direct Connect from production into the IRE.
Can I do any of this on premises in VCF 9 without the cloud?
Partly. The isolated clean room with integrated analysis runs on a cloud recovery SDDC. On premises you can use vSAN local immutable snapshots for a fast restore of clearly clean points, and Live Site Recovery handles site to site DR, but the forensic isolation and behavioral scoring are the cloud service.
Where you recover to, and why it is not always the cloud
Once a snapshot passes analysis, you have a choice about the destination, and the choice changes your recovery time far more than most people expect. VMware Live Cyber Recovery lets you recover a validated virtual machine directly onto the original protected site, onto a different protected site, or onto the recovery SDDC itself, and later fail back from the recovery SDDC to on premises once the primary is rebuilt and trusted. Each path has a different cost. Landing back on the original site is fastest if that site is clean and rebuilt, but it is also the site that just got hit, so you rarely trust it first. Running on the recovery SDDC keeps you off the compromised estate while forensics finishes, at the price of egress and cloud runtime until you fail back.
The trap is treating the recovery SDDC as a permanent home. It is metered, and a recovered estate left running there for weeks while the security team argues about root cause turns into a bill nobody budgeted. Decide the destination as part of the plan, not in the middle of the incident.
Where this leaves you
The failover button and the clean room solve different failures. Keep DR for the outages that kill hardware, and build a separate cyber recovery plan for the day someone gets inside and stays. Go look at your current snapshot retention today and ask one question: if the intruder had been present for three weeks, how many of these points could you actually trust. If the honest answer is none, that is the gap to close before anything else. Ransomware recovery is a rehearsal you run on a quiet afternoon so that the loud morning is boring.
Next we take the recovery estate off premises entirely and look at DR to the cloud: what changes when your recovery site is a cloud SDDC rather than a second data center you own.
« Previous: Part 9 | VMware Live Recovery Complete Guide | Next: Part 11 »
References
- The Isolated Recovery Environment (IRE), Broadcom TechDocs
- Using Ransomware Recovery, Broadcom TechDocs
- VMware Live Recovery FAQ, January 2026
About The Author
DrJha