VCF 9.1 Disaster Recovery, Backup, and Restore: An Architect’s Field Guide

This is Part 18 of an architect’s read of VCF 9.1, and the operational protection field guide. Part 17 closed the Design Topology mini-series with cyber recovery, Advanced Cyber Compliance, and the Isolated Recovery Environment — the architecture for ransomware and cyber-incident response. This part is the adjacent (and often confused) discipline: operational disaster recovery, backup, and restore for the everyday risks — site outages, hardware failures, accidental deletions, application-level data loss.

These two disciplines are often run by the same team and conflated in design conversations. They’re structurally different. Cyber recovery assumes the primary environment is compromised — every action requires forensic isolation, immutability, and an air-gap mentality. Operational DR assumes the primary environment is healthy but unreachable or impaired — the priority is RTO, automation, and minimal data loss. Both matter. Neither substitutes for the other.

The most important update to be aware of in VCF 9.1: VMware Live Recovery has been renamed and integrated into VCF as VCF Protection and Recovery. This isn’t cosmetic — it signals that protection and recovery are now first-class platform capabilities, surfaced through VCF Operations rather than through a separate product console. The product behaviours are largely continuous with VMware Live Recovery in 9.0, but the new branding will appear across documentation, customer engagements, and licensing conversations through 2026.

This article walks through the four-layer protection model: local vSAN Data Protection, site-to-site DR via VCF Protection and Recovery, management plane backup, and workload-specific patterns for VMs and Kubernetes. Then it closes with RPO/RTO decision framing and the most common HLD anti-patterns I see in design reviews.

The four-layer protection taxonomy in VCF 9.1

Before any specific tooling decisions, agree on the taxonomy. In every protection design review I lead, this is where time goes — making sure architects, operations, and the business agree on which layer addresses which risk class.

Layer 1: Local snapshots and protection groups. Fast, frequent, low-cost protection against operational issues — accidental deletion, application-level corruption, failed change windows. vSAN Data Protection (included with VCF) provides this for vSAN-resident workloads. Local snapshots are not backups — they live on the same storage as the protected VM — but they’re the first-line response.

Layer 2: Site-to-site disaster recovery. Replication-based protection against site-level events — power loss, fire, flood, regional WAN outages. VCF Protection and Recovery (formerly VMware Live Recovery) provides orchestrated DR. Array-based replication via NetApp, Pure, Dell, HPE provides storage-native alternatives. Stretched clusters provide transparent DR for metro-scale sites.

Layer 3: Backup to immutable target. Independent point-in-time copies on a separate storage system. Used for compliance retention, longer-RTO recovery, and recovery from data corruption that has propagated through replication. Veeam, Cohesity, Rubrik, Commvault, or vSAN-to-vSAN remote snapshots provide this layer.

Layer 4: Cyber recovery. Covered in Part 17 — the Isolated Recovery Environment, Advanced Cyber Compliance, and Cyber Recovery ReadyNodes. Designed for cyber-incident scenarios where the primary environment is assumed compromised. Layered air-gap, immutability, controlled ingress/egress.

These four layers stack. A well-designed VCF 9.1 protection architecture uses all four, with each layer addressing a different risk class. The most common architectural error I see is conflating layers — expecting local snapshots to deliver site DR, or treating site DR as a substitute for cyber recovery.

Layer 1: vSAN Data Protection — included with VCF

vSAN Data Protection provides local snapshot-based protection for vSAN-resident VMs. It’s part of the core VCF entitlement — no additional licence required for local protection.

The architecture in VCF 9.1:

• Snapshots are native vSAN ESA snapshots — the redesigned snapshot architecture in ESA performs significantly better than legacy VMFS-style snapshots, with minimal performance overhead during snapshot operations

• Protection Groups define which VMs get protected with what frequency and retention. Defined via VM name patterns, tags, or explicit VM lists

• Set-and-forget operational model — once a Protection Group is defined, snapshots happen automatically on the configured schedule

• Recovery from local snapshots is fast — no data movement, no network transfer, sub-second mount times for inspection

• Linked-clone-style VM recovery from snapshots without committing the full restore — useful for forensic inspection or selective file recovery

What vSAN Data Protection is not:

• Not a backup — snapshots live on the same vSAN cluster as the protected VM. A vSAN cluster failure loses both

• Not site protection — a site failure that affects the vSAN cluster loses the snapshots too

• Not cyber-resilient on its own — ransomware that gets ESX-level access can delete snapshots. Combine with immutability features for cyber resilience

Where it fits in the design: as the first-line protection layer for vSAN workloads. Use it for:

• Recovery from accidental VM deletion or misconfiguration

• Pre-change-window snapshots before risky operations (patching, schema migrations)

• Application-level corruption recovery

• Short-term recovery point coverage between site-replication intervals

HLD considerations:

• Snapshot retention versus storage overhead — plan capacity headroom for snapshot space

• Protection Group naming patterns — dynamic patterns must not catch snapshot-derived VMs (linked clones) or you create protection loops

• Schedule design — frequent enough to deliver useful RPO, infrequent enough to manage storage cost

• Integration with VCF Operations — Data Protection & Recovery dashboard surfaces snapshot health across the fleet

Layer 2: VCF Protection and Recovery (the renamed VMware Live Recovery)

VCF Protection and Recovery is the site-to-site DR orchestration platform in VCF 9.1. The product was previously branded VMware Live Recovery in 9.0 and earlier; the 9.1 rename reflects its integration into VCF as a first-class platform capability rather than a separate product.

Core components:

vSphere Replication. Per-VM asynchronous replication with RPO from 5 minutes to 24 hours. Storage-agnostic — replicates between any supported storage types. The foundation of most VCF DR designs.

VMware Live Site Recovery (formerly Site Recovery Manager / SRM). Recovery Plan automation. Per-VM recovery customisation — IP customisation, scripting, dependency ordering, recovery validation. Test recovery without production impact. Reverse replication for failback.

vSAN Data Protection with replication. vSAN-to-vSAN replication of protected VMs. Combines local snapshots (Layer 1) with remote target for site-level protection.

VCF Operations integration. The Data Protection & Recovery dashboard surfaces all protection state in one console — vSphere Replication, vSAN replication, Site Recovery, cyber recovery if licensed. Top-level visibility of how many VMs are protected, how many are not, and protected storage capacity. The single-pane-of-glass story for protection.

Licensing model (critical to get right):

• Local vSAN snapshots: included in core VCF entitlement

• Replication and remote snapshots: require Advanced Cyber Compliance (ACC) subscription

• On-premises DR without cyber capabilities: standalone Site Recovery Manager licence for VCF, vSphere Foundation, or legacy vSphere editions

• Multi-tenant cloud DR-as-a-Service: VMware Cloud Director Availability under ACC

Architectural patterns:

Pattern A: vSphere Replication + Site Recovery. Per-VM replication between two VCF Instances with orchestrated recovery. The traditional DR pattern. Works regardless of underlying storage. RPOs of 5 min to 24 hr per VM.

Pattern B: vSAN Data Protection with remote replication. vSAN-to-vSAN replication with integrated local + remote snapshots. Single management plane for both local protection and site DR. Suitable when both source and target are vSAN ESA.

Pattern C: Array-based replication with Site Recovery. Storage vendor replication (NetApp SnapMirror, Pure ActiveCluster async, Dell SRDF, HPE 3PAR/Alletra Remote Copy) for the data movement, with Site Recovery for orchestration. Performance and capacity advantages for large datasets. RPOs as low as zero for synchronous patterns.

Pattern D: Hybrid — vSphere Replication for tier-2/3, array-based for tier-1. Use array replication where the storage is array-based and bandwidth/scale demands it. Use vSphere Replication for cross-storage-vendor scenarios and for VMs where setup simplicity matters more than performance.

New in VCF 9.1: multi-source replication topologies

The major architectural enhancement to protection in VCF 9.1 is multi-source replication. In VCF 9.0, vSAN-to-vSAN replication was point-to-point. In 9.1, vSAN Protection and Recovery introduces multi-source topologies that change what’s possible at fleet scale.

The new topologies:

Fan-in (multi-source to single target). Multiple source clusters — vSAN, VMFS, or NFS — replicate to a single vSAN ESA recovery cluster. Consolidates protection infrastructure: instead of point-to-point pairs for each source-target relationship, multiple sources converge on one recovery target. Reduces recovery infrastructure cost. Useful for service providers and large enterprises consolidating DR.

Fan-out (single source to multiple targets). “Same VM” fan-out by combining vSphere Replication and vSAN Protection Groups — a single VM can be protected to multiple recovery targets simultaneously. Useful for compliance scenarios requiring multiple geographic recovery points, or for tiered DR where different recovery targets serve different RTOs.

Heterogeneous storage protection. Multi-source includes VMFS and NFS as source storage types replicating to vSAN ESA targets. This breaks the silo where only vSAN workloads could use vSAN Data Protection — now mixed-storage environments can converge on a vSAN ESA recovery posture without changing primary storage.

Manual seeding for initial sync. The initial full sync over the WAN can be impractical for large datasets. Manual seeding lets you ship the initial baseline (physical media or local high-bandwidth transfer) and then run incremental replication over the WAN. Operationally important for bandwidth-constrained environments.

Use cases that benefit:

• Large enterprise with multiple regional sites consolidating onto a centralised recovery cluster

• Service providers offering DR-as-a-Service to multiple customers from a single target environment

• Data migration projects — multi-source replication assists with migration off VMFS or NFS to vSAN ESA without disrupting primary workloads

• Compliance-driven multi-geography recovery requirements

HLD considerations:

• Target cluster sizing — fan-in requires the recovery cluster to accommodate aggregate of all sources, with appropriate headroom

• Bandwidth planning — multi-source converges WAN traffic to one target; plan for peak aggregate

• RPO consistency — different sources may have different RPO requirements; design Protection Groups accordingly

• Recovery orchestration — fan-in simplifies infrastructure but creates dependencies; failure of the recovery target affects all sources

Management plane protection — the often-forgotten layer

In every DR design review, the management plane is the layer that gets least attention. Workload DR is well understood. Management plane DR is frequently afterthought. This is dangerous — a disaster that takes out the primary site’s management plane without proper backup means weeks of recovery time even after workloads are running again.

The components requiring backup:

SDDC Manager. Native backup workflow via the SDDC Manager UI. Backups written to SFTP target. Should be scheduled to a backup target outside the protected Workload Domain. Critical for recovering fleet-level lifecycle state.

vCenter Server. File-based backup to FTP / FTPS / HTTP / HTTPS / SCP / NFS / SMB targets. Image-based backup via supported backup software. Native VAMI scheduled backup. For very large vCenter deployments, image-based backup via Veeam or similar is operationally cleaner.

NSX Manager. Cluster-level file-based backup to SFTP target. Backs up cluster configuration, manager configuration, edge node configuration. Restore is to a fresh NSX Manager deployment.

VCF Operations. Embedded Postgres backup. Critical for retaining historical metrics, alerts, capacity history, configuration drift baselines. Loss of VCF Operations data means losing the operational memory of the platform.

VCF Automation. Template, blueprint, and project configuration backup. Identity policy and approval workflow definitions. Losing automation configuration means rebuilding self-service catalogues from scratch.

Management Services Cluster. New in VCF 9.x — the Kubernetes runtime hosting platform services (lifecycle, identity, log management, real-time data). Backup approach is K8s-aware — etcd backups, persistent volume snapshots, manifest export. Treat it as a critical workload requiring its own backup posture.

HLD considerations:

• Backup target placement — must be outside the protected scope. Backing up the primary vCenter to a datastore served by that vCenter is a common but useless pattern

• Backup frequency — configuration changes drive frequency. SDDC Manager backups before every lifecycle operation. vCenter and NSX daily minimum

• Backup retention — longer than you think you need. Configuration drift detection often relies on backup history

• Recovery testing — test restoring SDDC Manager and vCenter at least annually. The first time you try to restore should not be during a real disaster

• Cross-Instance considerations — in multi-Instance Fleets, each Instance’s management plane is backed up independently. Fleet-level services (VCF Operations, Identity Broker if centralised) are backed up at fleet scope

Workload backup — third-party integration

For most enterprises, third-party backup software complements native VCF protection. The major vendors — Veeam, Cohesity, Rubrik, Commvault — all support VCF 9.x with VM-level, application-aware, and file-level recovery.

Architectural considerations:

• Backup proxy placement — backup proxies typically deploy as VMs in the protected Workload Domain. Plan compute, network, and storage footprint

• Backup data path — SAN-direct backup (where supported) bypasses the LAN for backup traffic. Hot-add backup uses VMware’s native data path. Network-based fallback for VMs without SAN access

• Backup target — immutable storage targets are increasingly standard. NetApp ONTAP SnapLock, Pure SafeMode, Dell DataDomain Retention Lock, HPE StoreOnce Catalyst Copy with retention. S3 Object Lock for cloud or on-prem object storage targets

• Native S3 Object Storage on vSAN ESA (tech preview in 9.1) — viable backup target inside the VCF environment, particularly for cloud-aligned data tiering patterns

• Application-aware backup — SQL Server, Oracle, Exchange, SAP integration via vendor-specific application plug-ins

• File-level recovery — mount-and-browse patterns. Most vendors support direct file extraction from backup without full VM restore

Common HLD anti-patterns to avoid:

• Single backup vendor for everything when application teams have specific needs — sometimes per-app backup tooling (e.g. native Oracle RMAN) is the right answer

• Backup target inside the same fault domain as primary — a flood that takes out the data centre takes out the backups

• No immutability — backups that can be deleted by an attacker who compromises admin credentials are not backups in the cyber-resilience sense

• Untested restore procedures — backups that have never been restored are theoretical

Kubernetes and VKS workload protection

Protecting Kubernetes workloads on VKS is structurally different from VM backup. Kubernetes state isn’t one thing — it’s a combination of cluster configuration (etcd), namespaces and their objects, persistent volumes, and application-level state. Each layer needs a distinct protection approach.

The protection layers for VKS workloads:

Namespace Capture (new in VCF 9.1). Rapid namespace-level snapshotting for VKS. Captures the namespace objects (deployments, services, config maps, secrets) plus the underlying persistent volume state. Useful for backup, replication, troubleshooting (test a change against a captured namespace), and migration between clusters. The first first-party VMware capability for K8s-native protection in VKS.

Velero. The open-source de facto standard for K8s backup. Velero plugin for vSphere CSI backs up persistent volume snapshots alongside Kubernetes object state. Works with VKS via the vSphere CSI driver. Backup target can be S3-compatible object storage (including native S3 on vSAN, MinIO, AWS S3, Azure Blob, GCS).

Persistent volume snapshots via CSI. vSphere CSI supports persistent volume snapshots. Snapshot creation can be triggered by VolumeSnapshot CRDs in Kubernetes. Useful as building block; usually orchestrated by Velero or vendor backup software.

Application-level backup. For stateful applications (databases on K8s), application-level backup (e.g., logical Postgres backup, MySQL dumps) often complements snapshot-based protection. Snapshots give point-in-time consistency; logical backups give portability and finer-grained restore.

etcd backup. Critical for cluster-level recovery. VKS provides cluster-level backup capabilities; for self-managed Kubernetes inside VKS, etcd backup is the customer’s responsibility.

HLD considerations:

• Per-cluster vs per-namespace protection scope — align to your VKS cluster strategy (Part 16 covered cluster-per-team, cluster-per-app, cluster-per-environment patterns)

• Backup-aware deployments — application teams need to know which volumes are protected, at what frequency, and with what RPO. Document explicitly

• Disaster recovery for VKS clusters — typically rebuild the cluster from declarative configuration (IaC) plus restore data via Velero or Namespace Capture. Pure-VM-style DR doesn’t apply

• Multi-cluster patterns — active/active multi-cluster Kubernetes (e.g., via service mesh) reduces dependency on cluster-level restore but doesn’t eliminate persistent volume backup needs

Storage-vendor-aware DR patterns

For environments using external storage — NetApp, Pure, Dell, HPE — the storage vendor’s native replication often plays a central role in DR. Parts 10–13 of this series covered the migration-side considerations; this is the protection side.

Key patterns per vendor (summarised — see vendor docs for current support matrices):

• NetApp ONTAP: SnapMirror Async for cross-site replication, SnapMirror Synchronous and MetroCluster for synchronous DR. SnapCenter integration for application-aware. Trident for K8s persistent volume DR

• Pure Storage: ActiveCluster for synchronous metro DR (VMFS-FC, NVMe-oF), CloudSnap for async, ActiveDR for async with orchestration. Pure Plugin for vCenter integration. Pure-managed disaster recovery for FlashArray

• Dell Technologies: SRDF/Metro for PowerMax synchronous DR, async modes for cross-region. PowerStore replication. PowerFlex async/sync replication. Dell-VMware integration through SRDF/SRM workflows

• HPE: Peer Persistence for synchronous metro DR (VMFS-FC only — critical constraint), HPE 3PAR/Alletra Remote Copy for async, HPE Zerto for any-to-any replication including cloud. HPE Storage Plugin for vCenter

Architectural decisions:

• Where does the orchestration live? Site Recovery Manager (now Live Site Recovery) for VMware-orchestrated workflows, vendor-native (e.g. Zerto) for any-to-any, or a hybrid

• Per-workload-class storage strategy — mission-critical on synchronous replication, tier-2/3 on async, tier-3+ on backup-only

• Recovery testing cadence — array-based DR allows test failover without production impact via space-efficient clones at the target. Use it regularly

• Cross-stack consistency — ensure application-consistent snapshots via VSS/application quiescing at the right point in the stack

Stretched cluster as a DR layer

Stretched clusters (covered in Part 14) provide transparent metro-scale DR — site failures cause workloads to restart on the surviving site automatically, with no manual recovery orchestration. This is operationally the simplest DR pattern when it fits.

Where stretched cluster fits in the protection layer:

• Provides Layer-2 protection without Layer-2 orchestration. Site failure becomes a vSphere HA event rather than a Site Recovery Plan execution

• RPO = 0 (synchronous), RTO = minutes (HA restart time)

• Requires synchronous replication budget — typically <=5ms RTT between sites

• Requires network stretch — usually the constraining factor

• Does not replace backup or async-replication DR for cross-region scenarios

When stretched cluster is the right answer for DR:

• Two data centres in the same metro region with synchronous replication possible

• Site-level availability required with minimal RTO

• Operations team prefers transparent failover over orchestrated recovery

• Application workloads tolerate vSphere HA restart semantics

When stretched cluster is not the right answer:

• Cross-region distances exceeding synchronous replication budgets

• Network stretch cannot be delivered (the usual blocker)

• Storage vendor doesn’t support active-active stretched (e.g., HPE Peer Persistence works only with VMFS-FC, not vVols)

• Workloads need to remain available even during stretched-cluster partition events (which require careful witness placement and design)

Operational DR vs cyber recovery — why both

Part 17 covered cyber recovery (ACC + IRE). The relationship between operational DR and cyber recovery is one of the most-asked questions in design reviews — “why can’t cyber recovery just be our DR?”

The structural differences:

• RTO assumptions: operational DR optimises for minutes-to-hours RTO. Cyber recovery accepts hours-to-days RTO in exchange for forensic isolation

• Replication trust: operational DR assumes the source is trustworthy. Cyber recovery assumes the source may be compromised — immutability and air-gap controls protect against tainted replication

• Recovery process: operational DR aims for unattended automated recovery. Cyber recovery requires forensic validation before restoring — the workflow is deliberately less automated

• Storage substrate: operational DR uses standard replication storage. Cyber recovery uses Cyber Recovery ReadyNodes with QLC storage optimised for immutable long-retention

• Network topology: operational DR uses standard production networks. Cyber recovery uses isolated networks with controlled ingress/egress

• Operating model: operational DR is run by infrastructure and operations teams. Cyber recovery is run by security and incident-response teams, often with separate access controls

Both are needed. The same backup or replication infrastructure cannot serve both purposes well — the trade-offs are different.

A complete VCF 9.1 protection architecture for a mature enterprise includes: vSAN Data Protection for Layer 1, VCF Protection and Recovery + array-based replication for Layer 2, third-party backup with immutable target for Layer 3, and ACC + IRE for Layer 4 (cyber recovery). Smaller deployments may collapse layers, but should understand which risks remain uncovered when they do.

The RPO / RTO decision framework

Most protection design conversations fail because RPO and RTO targets are set without architectural understanding of what each target costs. A useful frame for design conversations:

Map workloads to recovery tiers based on business impact:

• Tier 0 (Mission-critical): RPO = 0, RTO < 15 minutes. Stretched cluster or synchronous array-based replication. Limited workload candidates due to cost. Examples: trading systems, life-safety systems

• Tier 1 (Business-critical): RPO < 15 min, RTO < 4 hours. Async array-based replication or vSphere Replication with VCF Protection and Recovery orchestration. Most production workloads. Examples: customer-facing applications, financial systems

• Tier 2 (Important): RPO < 4 hours, RTO < 24 hours. Backup-based recovery with rapid restore tooling. Most internal-facing applications, productivity systems

• Tier 3 (Standard): RPO < 24 hours, RTO < 72 hours. Daily backup with standard restore. Development environments, archive data, low-impact services

• Tier 4 (Archive): RPO and RTO measured in weeks. Long-retention immutable backup. Compliance retention, historical data

Then design protection per tier:

• Tier 0: stretched cluster (Part 14) plus async DR backup for the metro disaster scenario

• Tier 1: Operational DR via VCF Protection and Recovery, with backup as belt-and-braces

• Tier 2: Backup-as-DR using third-party backup with rapid restore

• Tier 3: Standard daily backup

• Tier 4: Immutable long-retention backup

All tiers should be considered against cyber recovery (Layer 4 / Part 17). A workload’s cyber recovery tier may differ from its operational DR tier — not every Tier 0 workload needs Tier 0 cyber recovery, and vice versa.

HLD anti-patterns I see in design reviews

The same architectural mistakes appear repeatedly. The most common:

• Backup target inside the protected fault domain — backing up vCenter to a datastore served by that vCenter, or backing up production to an array in the same data centre with no off-site copy

• Management plane backup as afterthought — designing comprehensive workload DR and ignoring SDDC Manager, vCenter, NSX, VCF Operations backup until disaster strikes

• Treating snapshots as backups — vSAN Data Protection is local snapshot protection, not backup. Site failure or cyber compromise affects both VM and snapshots

• Cyber recovery as operational DR substitute — the air-gap, immutability, and forensic isolation of cyber recovery make it unsuitable for fast operational recovery

• Operational DR as cyber recovery substitute — if your replication target ingests a compromised source, you’ve replicated the compromise. Operational DR doesn’t survive ransomware

• No recovery testing — backups and DR plans that have never been tested are theoretical. Annual restore validation minimum

• Conflated RPO/RTO across tiers — setting one RPO for all workloads inflates cost on low-tier and under-protects high-tier

• No documented recovery runbook — protection automation handles the technical recovery; humans handle the decision points. Document who decides to invoke recovery, when, and how

• Backup software permissions overlap with operations permissions — a single compromised admin shouldn’t be able to delete both production and backups

• Storage vendor replication assumed compatible with VCF without validation — vendor support matrices change with each VCF release; validate during design, not during outage

Closing

VCF 9.1 brings the protection architecture into the platform in a way previous releases didn’t. The rename to VCF Protection and Recovery signals the strategic direction — protection is a first-class platform capability, surfaced through VCF Operations alongside the rest of the operating model. Multi-source replication topologies (fan-in, fan-out, heterogeneous storage) reshape what’s possible at fleet scale. vSAN Data Protection (free with VCF) provides the local first-line layer. The four-layer protection model — local, site-to-site, backup, cyber recovery — composes into a complete architecture.

In my design reviews, the protection questions I work through every time:

• Which workload classes does this customer run, and what’s the RPO/RTO tier for each?

• Which workloads land where in the four-layer protection model?

• Is the management plane backup target outside the protected fault domain?

• Are SDDC Manager, vCenter, NSX, VCF Operations, and Management Services Cluster all on a backup schedule with tested restore procedures?

• Are local vSAN snapshots configured for fast-recovery scenarios, with retention aligned to operational needs?

• Is site DR using VCF Protection and Recovery (vSphere Replication + Live Site Recovery), vSAN Protection, or array-based replication — and is the choice deliberate?

• Does the design use multi-source replication where it adds value (consolidation, fan-out, heterogeneous storage)?

• Is VKS workload protection a designed-in capability or a Day-2 afterthought?

• Is there a clear differentiation between operational DR and cyber recovery in the design, with both layers present?

• Is recovery testing scheduled, documented, and actually performed?

Get those answered and the protection HLD writes itself.

This article closes the operational-protection thread of the series. With Parts 1–7 (platform architecture), 8 (generic migration), 9 (day-2 operations), 10–13 (storage vendor migrations), 14–17 (Design Topology Field Guide), and now 18 (DR, backup, and restore), the 18-part series gives architects a complete read of VCF 9.1 in 2026 — from foundational architecture through migration, day-2, design topology, and operational protection.

Sources

• Broadcom TechDocs — VCF 9.1 Protection and Recovery Release Notes

• Broadcom Blog — vSAN Protection and Recovery Enhancements for VCF 9.1

• Broadcom Blog — VCF Recovery Improvements with VMware Live Recovery

• Broadcom Blog — Preserve Data Sovereignty and Deepen Protection against Cyberattacks with VCF 9.0

• Broadcom Blog — vSAN Data Protection in VCF: The Solution You Already Own

• Broadcom TechDocs — Welcome to VMware Live Recovery (now VCF Protection and Recovery)

• Broadcom TechDocs — Using vSAN Data Protection

• Broadcom — Announcing VCF 9.1

• Broadcom — Scale, Simplify, and Secure VCF 9.1

Veeam Community — VCF 9 backup and protection patterns