Deep Dive of the Day Protection and Recovery in VCF 9.1: what replaced Live Recovery, and the traps in moving to it
If your disaster recovery runbooks still say "Live Recovery", it's worth catching up on the name change first. Per the 9.1 release notes, VMware Live Recovery "has been renamed and integrated into VMware Cloud Foundation (VCF) as Protection and Recovery", and it now covers operational recovery, disaster recovery, cyber recovery and multi-tenant DR through VCF Automation. Version 9.1 went GA on 12 May 2026 (build 25367487), and the newest patch is 9.1.1.0100 from 12 October (build 25753785), which the notes describe only as security enhancements.
The moving parts will look familiar. There's a Protection and Recovery appliance, a scale-out appliance and a proxy, plus a VCF Operations management pack and a REST API gateway. Underneath, you choose a replication engine: vSphere Replication (host-based, and able to protect VMs on vSAN without a storage replication adapter), vSAN snapshots with local and replicated retention, or array-based replication through SRAs. New in 9.1, vSAN replication works from any source storage as long as the target is vSAN ESA, snapshot schedules get daily, weekly and monthly retention, protection groups can pick up members by tag, and you can seed from an existing replica so only the changes cross the wire.
The headline feature is cyber recovery. Instead of failing over to whatever the last replica holds, you recover from vSAN snapshots into an isolated clean room, with push-button network isolation through vDefend and integrated EDR to check what you're bringing back. Several vCenter sites can replicate to a single cyber recovery site. Duncan Epping's short demo on Yellow Bricks walks through a ransomware recovery and notes the Carbon Black and CrowdStrike integrations, which is the quickest way to see the workflow end to end.
Upgrades are where people get caught. Both sites need vSphere 8.0 Update 3 or later. Coming from Live Site Recovery 9.0.2.3, vSphere Replication 9.0.2.3 or vSAN Data Protection 8.0 U3, you deploy the 9.1 appliance on both sites first, and moving vSphere Replication to 9.1 means reconfiguring every replication as enhanced replication, so budget for that rather than treating it as an in-place bump. Two things are also on their way out: 9.1 is the last release that supports vSphere Virtual Volumes and the last with the VCF Operations orchestrator plug-in. Broadcom recommends moving vVols replications to array-based replication, and moving orchestrator workflows to the REST API gateway or the DR REST plug-in.
Check the limits before you design around it. 4Kn datastores and PMem aren't supported, NFS 4.1 datastores work with vSphere Replication but not array-based replication, the largest disk is 62 TB, one management server handles up to 5,000 replicated VMs, and VMs with IOFilter storage policies can't be replicated. A few known issues matter in labs as much as production: if you switch a cluster's vSphere Lifecycle Manager image to 9.1 without remediating, then back to 9.0.x, the next remediation can remove the hbr-agent VIB and leave hosts unable to replicate (restart the hms service from the appliance management interface to recover), so don't flip images back and forth; pairing several services at once can fail, so pair them one at a time; and staging many VMs at once in a cyber recovery can hit ESX kernel memory limits, so stage in smaller batches. If a ransomware failover fails, the notes say to run revertCurentImage on that replication before you retry.
Based on Protection and Recovery 9.1 Release Notes (Broadcom TechDocs) Official Protection and Recovery 9.1.1.0100 Release Notes (Broadcom TechDocs) Official VCF 9.1 Protection and Recovery demo: recovering from a ransomware attack (Yellow Bricks)
