, ,

How to Protect Workloads with VMware Live Recovery in VCF 9.1 (VCF 9.1 Day-2 Operations Step by Step Guide, Part 11)

Set up workload protection in VCF 9.1 with vSAN Protection and Recovery snapshots and VMware Live Site Recovery, from protection groups to a tested recovery plan.

VCF 9.1 Day-2 Operations · Part 11 of 20
Task type: OPTIONAL capability. Run this only when you need running virtual machines to survive a storage failure, a site outage, or a ransomware event, not on every fleet. It configures VM level snapshot protection and orchestrated site recovery for your workloads. It depends on a healthy fleet, a vSAN ESA recovery target, and VMware Live Recovery licensed and deployed.
Before you begin. Confirm a healthy, fully backed up fleet before you change any protection settings. Work through the VCF 9.x pre-installation checklist so vCenter, NSX and vSAN report green and your component backups are current.
TL;DR
  • Workload protection in VCF 9.1 has two layers: local vSAN snapshots through vSAN Protection and Recovery, and orchestrated site to site failover through VMware Live Site Recovery.
  • Deploy one Protection and Recovery appliance per vCenter, and size the recovery cluster as vSAN ESA, since ESA is the required replication target.
  • Group VMs by static name, wildcard name pattern, or vSphere tag, then attach a retention schedule (the Default template keeps about 26 snapshots at a 1 hour RPO).
  • Pair the protected and recovery instances, replicate the VMs, then build a recovery plan that sets priority groups, startup order and network mappings.
  • Test the plan in an isolated network before you trust it, then run planned migration or disaster recovery when a real event hits.
  • Component backup and restore live in Parts 8, 9 and 10; this part covers workload recovery only.

Workload protection answers a different question than fleet backup. Backup captures the state of your management components so you can rebuild them; workload protection keeps your running virtual machines recoverable after a storage failure, a site outage, or a ransomware event. VCF 9.1 gives you two layers to work with. Local snapshots through vSAN Protection and Recovery guard against accidental change and give fast rollback, while VMware Live Site Recovery replicates VMs to a second instance and runs an orchestrated failover when you need it.

This part sets up both layers. You will deploy the Protection and Recovery components, protect a set of VMs locally, pair a protected instance with a recovery instance, replicate the VMs, and build a recovery plan you can test. Component backup is covered in the guide to back up vCenter and NSX Manager, and full restore is covered in restore VCF 9.1 components from backup, so this part stays on workloads. For the operating model behind all of this, see the Day-2 operations overview.

Prerequisites

Confirm the items below on both instances before you configure anything. If you have not stood up the fleet yet, follow the VCF 9.1 Deployment Step by Step Guide first.

RequirementDetail
VCF versionVCF 9.1.0.0 or later on both the protected and recovery instances
Recovery storageA vSAN ESA cluster at the recovery site, which is the required replication target
LicensingVMware Live Recovery entitlement applied, plus the Advanced Cyber Compliance add-on for cyber recovery
AppliancesOne Protection and Recovery appliance per vCenter Server
NetworkRouted connectivity between sites for replication, with firewall rules for replication and management ports
AccessAdministrator rights in VCF Operations, vCenter and Live Site Recovery
Protected siteSource cluster (vSAN, VMFS, NFS)Protection and Recovery applianceLocal vSAN snapshotsRecovery siteRecovery cluster (vSAN ESA)Protection and Recovery applianceRecovered virtual machinesReplicationSites joined by site pairing
Figure 1. Two layers of workload protection in VCF 9.1: local snapshots on the source, and replication to a vSAN ESA recovery cluster.

Design the protection topology

Decide where recovered VMs will land before you replicate anything. VCF 9.1 supports multi-source replication, so a single vSAN ESA cluster at the recovery site can receive VMs from vSAN, VMFS and NFS sources. That fan-in pattern lets several source clusters protect into one shared recovery site, which keeps the recovery footprint small and consistent.

Map out three things. First, list the source clusters and the datastore type behind each set of VMs, since only the recovery target must be ESA. Second, size the recovery cluster for the combined snapshot and replica load of every source that fans into it. Third, decide which VMs need only local snapshots and which need cross site replication, because local protection alone does not survive a full site loss. Record these decisions so the protection groups and recovery plans you build later match the topology rather than drifting from it.

Step 1, Deploy and license the protection components

Protection and Recovery runs as a dedicated appliance in each vCenter, so start by deploying and licensing it on both instances. This work uses VCF Operations and vCenter.

  1. In VCF Operations, open the Fleet Management inventory and confirm each vCenter that will take part in recovery is listed and healthy.
  2. In each vCenter, deploy the Protection and Recovery appliance from the OVF deployment wizard, one appliance per vCenter Server.
  3. On the Customize template screen, set a static management IP, DNS and NTP, then click Next.
  4. Click Finish and wait for the appliance to power on and register with vCenter.
  5. Confirm the recovery cluster reports vSAN ESA, because ESA is the required replication target for VCF 9.1.
  6. On the Licensing page, apply your VMware Live Recovery key so replication and recovery features become available.

Step 2, Protect virtual machines locally with vSAN snapshots

Local snapshots give you fast rollback on the source cluster without any second site. This work uses the vSAN Data Protection view in vCenter.

  1. In the vSphere Client, select the vSAN cluster, open Configure, then choose vSAN and Data Protection.
  2. Click Protection Groups, then click Add to start a new group.
  3. Enter a name in the Protection group name field.
  4. Set membership with a static VM list, a Name pattern using wildcards, or a vSphere tag with match any or match all logic.
  5. Click Next to move on to the snapshot schedule, then continue to Step 3.

Step 3, Choose a snapshot retention schedule

A retention schedule decides how many snapshots you keep and for how long. VCF 9.1 supports tiered hourly, daily, weekly and monthly retention, with quick templates to start from.

  1. On the Snapshot schedule screen, pick a starting template from Default, Ransomware recovery, or Short-term retention.
  2. Adjust the RPO and the hourly, daily, weekly and monthly retention counts to match your recovery needs.
  3. Review the estimated snapshot count shown for the schedule.
  4. Click Finish to activate the protection group and begin taking snapshots.
TemplateRPOKeep recentLonger retention
Default1 hourLast 12Daily for 2 weeks, about 26 snapshots total
Ransomware recovery1 hourLast 1Hourly 1 day, daily 1 week, weekly 1 month, monthly 6 months
Short-term retention1 hourLast 1Hourly 1 day, daily 1 week, weekly 1 month

Step 4, Pair the protected and recovery sites

Site pairing links a protected instance to a recovery instance so replication and recovery plans can run across them. This work uses the VMware Live Site Recovery interface.

  1. Open the Live Site Recovery plugin from the vSphere Client shortcuts menu.
  2. Click Site Pair, then click New Site Pair.
  3. Enter the recovery side Platform Services address and administrator credentials, then click Next.
  4. Select the vCenter pair to link and click Next.
  5. Review the summary and click Finish to establish the pairing.
  6. On the Site Pair page, open Configure and set inventory mappings for networks, folders, resource pools and placeholder datastores.

Step 5, Replicate VMs and create a protection group

With a pair in place, replicate the VMs you want to recover, then group them so a plan can act on them together. This work uses the Live Site Recovery interface with vSphere Replication.

  1. Open Replications, then click New to start the configure replication wizard.
  2. Select the source VMs and click Next.
  3. Choose the vSAN ESA recovery datastore as the target, set the Recovery point objective, then click Next.
  4. For a large first sync over a constrained link, choose Manual seeding so vSAN performs a differential sync after the seed lands.
  5. Open Protection Groups, click New Protection Group, and select the replicated VMs.
  6. Click Finish to create the group, keeping it local to the selected site.

Step 6, Build and configure a recovery plan

A recovery plan is the runbook that powers on your VMs at the recovery site in the right order. This work uses the Live Site Recovery interface.

  1. Open Recovery Plans, then click New Recovery Plan.
  2. Name the plan, select the recovery site, then click Next.
  3. Add the protection group you created and click Next.
  4. Set the recovery network for tests, then click Finish.
  5. Open the plan, select Virtual Machines, and assign each VM to a Priority group from 1 to 5 to control startup order.
  6. Set Startup Action and any timeout values so dependent VMs wait for services to come up.
OperationWhat it doesWhen to run
TestRuns the plan in an isolated network without touching productionRegularly, to validate the runbook
Planned migrationMoves VMs to the recovery site gracefully with no data lossScheduled maintenance or migration
Disaster recoveryRecovers VMs at the recovery site after an unplanned outageA real site or storage failure
ReprotectReverses replication so the recovery site becomes protectedAfter a failover, once the original site returns
FailbackReturns VMs to the original siteWhen the primary site is ready again
Protection groupReplicate VMsRecovery planTest andrecoverReprotect andfailback
Figure 2. Recovery workflow, from grouping and replicating VMs to a tested plan, then reprotect and failback.

Step 7, Test the recovery plan

Testing runs the plan in an isolated network so you can validate it without touching production. Run a test after any change to the plan or the protected VMs.

  1. Open the plan under Recovery Plans and click Test.
  2. Confirm the isolated test network on the wizard, then click Next and Finish.
  3. Watch the Recovery Steps tab as each priority group powers on.
  4. When the test completes, click Cleanup to remove the test VMs and reset the plan.

To read plan state from automation, connect with PowerCLI and list the plans:

Connect-SrmServer -Server vc-protected.example.local -RemoteServer vc-recovery.example.local
$srm = $DefaultSrmServers[0]
$srm.ExtensionData.Recovery.ListPlans()

When a real event occurs, open the plan and run Recovery, then choose planned migration for a graceful move or disaster recovery for an unplanned outage. After the workloads run at the recovery site and the original site returns, run Reprotect to reverse replication, then run the plan again to fail back. Practise this full sequence in a maintenance window at least once so the runbook and your team are ready before you depend on it.

Verify workload protection

Confirm each layer reports a healthy state before you rely on it.

  • In vCenter, open vSAN and Data Protection and confirm the protection group shows recent snapshots at the expected count.
  • In Live Site Recovery, open Replications and confirm each VM reports an OK status with a current recovery point.
  • Open the recovery plan and confirm the last test finished with no errors on the History tab.
  • In VCF Operations, confirm the fleet view shows the protected and recovery instances as healthy.
  • Confirm the retention schedule is producing snapshots at the expected cadence by checking timestamps on the newest and oldest snapshots in the group.

Common errors and fixes

SymptomLikely causeFix
Replication stays inactive or errorsRecovery datastore is not vSAN ESAPoint replication at a vSAN ESA cluster, the required target
Recovery plan test fails at the network stepMissing or wrong inventory mappingSet network, folder and resource pool mappings before testing
VMs never join a protection groupTag or name pattern does not matchRecheck the wildcard pattern or confirm the vSphere tag is assigned
Initial full sync too slowLarge dataset over a constrained linkUse manual replica seeding, then let vSAN run a differential sync

Common questions

Does this replace my component backups? No. Backup and restore of SDDC Manager, vCenter and NSX are covered in Parts 8, 9 and 10. Workload protection runs alongside them.

Do I need vSAN ESA at both sites? Only the recovery target must be vSAN ESA. Source workloads can sit on vSAN, VMFS or NFS in VCF 9.1.

Can I protect VMs without a second site? Yes. Local vSAN snapshots protect against change and give fast rollback without any replication.

How many protection groups can one Live Site Recovery instance hold? Up to 500 protection groups across all types combined.

What enables on-premises cyber recovery? A customer owned isolated recovery environment built with the Advanced Cyber Compliance add-on.

How often should I test a recovery plan? Run a test after any change to the plan, the protected VMs or the site mappings, and on a fixed schedule such as monthly or quarterly so the runbook stays trustworthy.

References

VCF 9.1 Day-2 Operations · Part 11 of 20
« Previous: Part 10  |  Complete Guide  |  Next: Part 12 »

About The Author


Discover more from Journal of Intelligent Infrastructure

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *

Architect’s Toolkit

About the Author

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

Discover more from Journal of Intelligent Infrastructure

Subscribe now to keep reading and get access to the full archive.

Continue reading