Protecting the Recovery Control Plane: A VCF 9.1 Management-Component Backup and Fleet DR Runbook

TL;DR

Protecting workload virtual machines does not automatically protect the VMware Cloud Foundation services needed to discover, authorize, network, orchestrate, and validate their recovery.

A complete VCF 9.1 recovery strategy needs several distinct mechanisms: native file-based backups for components such as SDDC Manager, vCenter Server, and NSX Manager; image-based protection for VCF Operations; backup and restore procedures for VCF Automation and management services; VCF instance reconstruction for a failed instance in the same site; and VCF fleet disaster recovery for a site or regional failure.

The operational objective is not simply to restore appliances. It is to rebuild a trustworthy recovery control plane in dependency order:

The runbook must also preserve the credentials, encryption material, DNS records, certificates, software binaries, network reachability, and offline documentation required to execute that sequence when the primary platform is unavailable.

Introduction

A VMware Cloud Foundation recovery plan can look mature while still containing a serious architectural gap.

The organization may replicate business-critical virtual machines, maintain application recovery plans, protect databases, and test workload failover. Those controls are necessary, but they do not answer a more fundamental question:

What platform will coordinate the recovery when the primary VCF management plane is unavailable?

Application recovery commonly depends on services that are themselves hosted inside the affected environment. Recovery operators may need vCenter Server to inventory and power on virtual machines, NSX to restore network state, VCF Operations to access fleet workflows, identity services to authenticate administrators, DNS to resolve recovered components, and certificate trust to connect the entire chain.

If those services fail together, workload protection can remain technically intact while the organization loses the control plane required to use it.

Broadcom publishes separate VCF 9.1 procedures for component backup and restore, VCF instance reconstruction, and VCF fleet disaster recovery. That separation is operationally important. These are different failure models, with different prerequisites, dependencies, and recovery methods.

This article turns those models into a dependency-aware operational runbook.

The Workloads Are Protected but the Platform Is Not

Consider a regional outage affecting the VCF management domain.

The protected application virtual machines have recent recovery points. Replication has met its target RPO. The application team expects recovery to begin immediately.

The platform team discovers several additional problems:

• The backup console was hosted in the failed management domain.
• The authoritative DNS update process requires an identity service that is unavailable.
• The latest NSX backup is encrypted with a passphrase stored in an inaccessible password vault.
• The recovery site cannot reach the SFTP backup destination.
• The correct vCenter installation media is not available locally.
• The only copy of the recovery runbook is stored in a document platform that uses the failed identity provider.
• The application recovery plan assumes that vCenter, NSX, and the protection appliances are already healthy.

The workload data may still be recoverable, but the organization is not operationally ready to recover it.

This is the difference between protecting applications and protecting the recovery control plane.

Choose the Correct VCF Recovery Model

The first decision during an incident is not which appliance to restore. It is which VCF recovery model matches the failure.

These models are related, but they are not interchangeable.

A failed vCenter appliance should not automatically trigger a complete VCF instance reconstruction. A regional outage should not be treated as a collection of unrelated appliance restores. An application failover should not begin merely because the workload recovery points are available.

The incident commander must classify the failure boundary before authorizing recovery execution.

The Recovery Control Plane Dependency Chain

The most useful recovery model is a dependency chain rather than an appliance list.

The following diagram shows what the reader should notice: workload recovery services sit near the bottom of the chain. They depend on management services that, in turn, depend on infrastructure outside the VCF software stack.

The exact product task order remains governed by the applicable Broadcom recovery procedure. The architectural point is that each layer needs a verified foundation before the next layer is allowed to become authoritative.

Define the Minimum Viable Recovery Control Plane

The recovery team does not need every dashboard and optional integration online before beginning workload recovery. It does need a minimum viable control plane.

This definition prevents two common errors.

The first is waiting for every nonessential management service before recovering urgent workloads. The second is moving too quickly and starting application recovery while the platform control plane is still inconsistent.

Build a Backup Design That Survives the Incident

A management-component backup is useful only when the organization can locate, decrypt, transport, and restore it during the failure it was designed to address.

Component Protection Matrix

A green backup status is not sufficient evidence. The runbook needs to prove that the backup is recoverable from the intended recovery location.

Isolate Backup Destinations

The backup target should not share the same administrative and infrastructure failure domain as the component it protects.

For a production design, validate the following:

• The SFTP destination is outside the management-domain storage failure boundary.
• The image-based backup repository is reachable if the primary vCenter is unavailable.
• A regional recovery site can reach the required backup copies without routing through the failed region.
• Backup administration uses credentials separate from normal VCF administration.
• A compromised VCF administrator cannot silently delete every usable recovery point.
• Retention includes multiple points in case the most recent backup contains corruption or malicious changes.
• Recovery operators can access the backup catalog through a break-glass method.
• The backup platform itself has a documented recovery procedure.

Immutability, isolated credentials, delayed deletion, and offline copies are not replacements for product-native backup procedures. They are additional controls that protect those backups from infrastructure failure and cyber compromise.

Preserve Software Binaries and Version Records

A file-based backup often contains configuration and state, not a complete executable recovery environment.

The recovery package should therefore include:

• The exact VCF 9.1 component versions in use.
• Required OVAs, ISOs, installers, patches, and upgrade bundles.
• Checksums for preserved binaries.
• A component-to-binary mapping.
• Current appliance sizing.
• Network, DNS, and certificate requirements.
• Restore compatibility notes.
• The date each binary was downloaded and validated.
• A documented process for retrieving replacement binaries in disconnected environments.

Do not assume that internet access, support portal access, software-depot services, or the original download token will be available during a regional outage.

Protect Dependencies Outside VCF

Many of the most important recovery dependencies are not VCF appliances.

DNS and NTP

DNS should be treated as part of the recovery architecture, not as a convenience service.

The runbook should include:

• Forward and reverse records for every management component.
• Recovery-site DNS server addresses.
• Required TTL changes for planned testing.
• The owner authorized to change production records.
• A rollback record for every DNS modification.
• Resolution tests from the recovery management network.
• The expected FQDN and IP identity for same-site VCF instance recovery.
• The process for preventing stale or conflicting records.

NTP is equally important. Time skew can break authentication, certificate validation, distributed databases, log correlation, and service registration.

Validate both name resolution and time before diagnosing higher-level platform failures.

The following commands provide non-destructive checks from a trusted recovery workstation. Replace the example names and addresses with the production values.

dig +short vcsa01.example.com
dig -x 192.0.2.10 +short

chronyc tracking
chronyc sources -v

nc -vz backup01.example.com 22

Successful execution should return the expected forward and reverse records, a synchronized clock source, and reachable SFTP service. Unexpected records, significant time offset, or failed connectivity are stop conditions for the next recovery stage.

Identity and Break-Glass Access

A federated sign-on design can simplify normal operations while creating a recovery dependency on external identity infrastructure.

The recovery package should include:

• Local administrative accounts for components that support them.
• Break-glass account ownership and approval procedures.
• Current password-vault recovery instructions.
• Offline access to required passwords or recovery shares.
• Multifactor recovery methods that do not depend solely on the failed site.
• Service account inventories and rotation history.
• Emergency access logging and post-incident credential rotation requirements.

Break-glass credentials should be tested, monitored, and governed. An emergency account that has never been used is an assumption, not a control.

Encryption Keys, Passphrases, and Certificates

Backups can be present and still unusable because the recovery team cannot decrypt them or recreate the expected trust relationships.

Preserve and test access to:

• NSX backup passphrases.
• Backup-repository credentials.
• Certificate authority chains.
• Private keys where export is required and permitted.
• Certificate signing procedures.
• Appliance certificate subject names and subject alternative names.
• Service-account secrets.
• Recovery codes and hardware-token procedures.
• The approvers required to release protected material.

Use an external workstation to inspect the certificate presented by a recovered service:

openssl s_client 
  -connect vcsa01.example.com:443 
  -servername vcsa01.example.com 
  </dev/null 2>/dev/null |
openssl x509 
  -noout 
  -subject 
  -issuer 
  -serial 
  -dates 
  -fingerprint 
  -sha256

Change the FQDN to the component being tested. Success means the subject identity, issuer, validity dates, and fingerprint match the approved recovery record. A service responding on port 443 is not sufficient if the certificate identity is wrong.

Management Networking

The network recovery plan should identify what remains available without vCenter and NSX management.

Document:

• Management VLANs and subnets.
• Physical switch configuration.
• ESXi management access paths.
• Standard-switch fallback requirements.
• Distributed-switch dependencies.
• Routing and firewall rules between recovery networks.
• Backup network reachability.
• DNS and NTP paths.
• Replication connectivity.
• IP mobility requirements for the selected fleet DR design.
• Network ownership and escalation contacts.
• The method used to prevent duplicate active instances.

A management network that depends entirely on the control plane being recovered creates a circular dependency.

Account for the VCF 9.1 Fleet Architecture

VCF 9.1 changes an important part of the recovery model.

The standalone VCF Operations Fleet Management appliance used in VCF 9.0 is no longer a separate VCF 9.1 appliance. Its lifecycle functions move into VCF Management Services, including Fleet Lifecycle and SDDC Lifecycle services running on the VCF Services Runtime.

VCF Management Services also hosts or supports other important platform capabilities, including the software depot and license services.

This has several runbook consequences:

• Do not copy a VCF 9.0 fleet recovery plan into a 9.1 environment without modification.
• Replace legacy Fleet Management Appliance recovery steps with the current VCF Management Services recovery tasks.
• Inventory the services running at the fleet level and the instance level.
• Document which VCF instance hosts the fleet-level services.
• Protect the Services Runtime infrastructure and its dependencies.
• Preserve the binaries needed to reconstruct management services.
• Validate the VCF License Server recovery or redeployment path.
• Ensure software-depot availability is considered a recovery dependency.
• Verify fleet and SDDC lifecycle inventory after restoration.

The user interface may present a unified operating experience, but the recovery plan must still understand the underlying service placement.

Recovery Entry Criteria and Safety Checks

Before restoring any management component, the incident commander should require a documented entry decision.

At minimum, confirm:

• The failure scope is classified.
• The protected site is isolated or confirmed unavailable.
• Dual-active operation has been prevented.
• The intended recovery model has been selected.
• The selected backup point is known.
• The backup has passed integrity and accessibility checks.
• The correct credentials and passphrases are available.
• Required binaries match the backup version.
• DNS and network changes have an assigned owner.
• Recovery infrastructure has sufficient compute, memory, storage, and network capacity.
• The team knows which component becomes authoritative at each stage.
• Application recovery has not started prematurely.
• Vendor support escalation information is available.
• The incident log is recording every action and timestamp.

For a cyber incident, add an explicit security approval before selecting a recovery point. The newest backup may not be the safest backup.

Restore-Order Decision Tree

The following decision tree separates the three platform-recovery paths. The reader should notice that each path eventually converges on the same requirement: a healthy management and recovery control plane before application recovery begins.

Do not choose VCF instance recovery as a shortcut for a single-component problem. Do not choose component restore as a substitute for a coordinated site-recovery plan.

Execute the Recovery Runbook

The following stages describe the operational dependency order. They do not replace the exact, version-specific Broadcom procedure for each component.

Declare the Incident and Select the Recovery Model

Record:

• Incident start time.
• Affected site, region, VCF instance, domains, and services.
• Current replication state.
• Last known healthy management state.
• Suspected failure cause.
• Cybersecurity involvement.
• Recovery model selected.
• Recovery point selected.
• Incident commander.
• Technical leads for compute, storage, network, security, backup, and applications.

Freeze unrelated changes. Do not allow parallel teams to restore different copies of the same control-plane component.

Establish External Dependencies and Break-Glass Control

Before deploying or restoring appliances:

• Validate recovery-site DNS.
• Validate time synchronization.
• Validate operator authentication.
• Retrieve the approved credential set.
• Confirm certificate authority availability.
• Confirm SFTP and image-backup repository reachability.
• Confirm access to software binaries.
• Establish out-of-band communications.
• Record the network and DNS state before modification.

If operators cannot authenticate without the failed identity service, stop and execute the identity break-glass plan.

Restore the Management Landing Zone

A complete management-domain failure may require temporary or replacement management infrastructure before the original components can be restored.

Validate:

• ESXi management access.
• Recovery compute capacity.
• Required datastores.
• Management port groups.
• Routing and firewall policy.
• DNS registration.
• Installation workstation access.
• Binary availability.
• Temporary management resources required by the VCF instance recovery workflow.

Keep temporary infrastructure clearly labeled. Record which systems are transitional and which systems will remain after recovery.

Recover vCenter Server

Recover the required management vCenter using the supported file-based restore process.

Before making it authoritative, verify:

• The restored FQDN and IP are correct.
• Forward and reverse DNS match.
• The appliance version is compatible with the backup.
• vCenter services are healthy.
• Single sign-on is functioning.
• ESXi hosts reconnect as expected.
• Datastores are visible.
• Distributed switches and port groups are present.
• Permissions and service accounts exist.
• Enhanced Linked Mode relationships are consistent, where used.
• The recovered vCenter is not competing with another active copy.

A functional user interface does not prove that inventory, networking, identity, and dependent service registrations are consistent.

Recover NSX Manager

Choose the NSX procedure that matches the failure:

• Restore a failed node into an otherwise healthy cluster.
• Reconstruct the NSX Manager cluster from backup.
• Recover the management and control plane as part of broader VCF instance recovery.

Validate:

• Cluster health.
• Backup timestamp and configuration state.
• Manager-node identities.
• Compute-manager registration.
• Transport-node status.
• Edge-cluster status.
• Tier-0 and tier-1 gateways.
• BGP and BFD sessions.
• Distributed and gateway firewall policy.
• Segments and transport zones.
• DHCP, DNS forwarding, NAT, and load-balancing dependencies where used.
• Connectivity from the management plane to protected workload networks.

Do not assume that powered-on NSX Edge nodes prove the restored NSX control plane is internally consistent.

Recover SDDC Manager and Reconcile Inventory

Restore SDDC Manager using the applicable VCF recovery procedure after its required vCenter and NSX dependencies are available.

Validate:

• SDDC Manager services.
• Management-domain inventory.
• Workload-domain inventory.
• Host and cluster records.
• vCenter and NSX registrations.
• Password and certificate status.
• Network settings.
• Backup configuration.
• Lifecycle state.
• Task history relevant to the incident.
• Any required inventory or database synchronization.

If vCenter or NSX was reconstructed independently, the SDDC Manager inventory may require reconciliation. Do not start lifecycle operations until the restored systems agree on the managed state.

Recover VCF Operations

Restore VCF Operations from the supported image-based backup.

Treat the VCF Operations cluster as one protected application. Avoid restoring arbitrary nodes from unrelated points in time.

Validate:

• Cluster membership and health.
• Administrative access.
• Data collection.
• vCenter and VCF integrations.
• Cloud proxies and collectors.
• Fleet inventory.
• Certificate trust.
• Credential references.
• License registration state.
• Backup and restore workflows.
• Alerting and notification.
• Historical data consistency required by operations.
• Access to fleet lifecycle and management-service views.

A restored VCF Operations interface is not ready until its integrations and inventory have been reconciled.

Recover VCF Management Services

For VCF 9.1, restore or reconstruct the required services according to the management-domain and fleet recovery plan.

The recovery inventory should include:

• VCF Services Runtime.
• Fleet Lifecycle.
• SDDC Lifecycle.
• VCF License Server.
• Software depot.
• Log Management services.
• Identity-related services.
• Configuration-management services.
• Any additional VCF management component deployed in the environment.

Validate service registration, version, certificates, network identities, and ownership before allowing lifecycle or licensing operations.

Recover Adjacent Fleet Applications

Recover VCF Automation, VCF Operations for Networks, identity components, logging integrations, and other management applications according to their documented method.

For each application, verify:

• Correct recovery site and deployment target.
• Backup path and timestamp.
• Service-account state.
• Certificates.
• External integrations.
• Inventory synchronization.
• Provider and tenant constructs.
• Network and identity mappings.
• Any manual reimport or reconciliation step required after restoration.

Do not recover optional management applications merely because they appear next in an appliance list. Recover them when their capabilities are required by the operational objective.

Recover Protection and Recovery Services

Only after the minimum viable management plane is healthy should the team recover or validate the services that orchestrate workload protection.

Confirm:

• Protection and recovery appliances are healthy.
• Protected and recovery sites are correctly paired.
• Replication appliances are registered.
• Recovery plans are visible.
• Protection groups are complete.
• Inventory mappings are correct.
• Folder, resource, datastore, and network mappings are current.
• Placeholder or shadow objects are valid where applicable.
• Replication RPO status is understood.
• Test networks are available.
• Recovery plans reference the intended vCenter and network objects.
• Certificates are trusted.
• Reprotect is not attempted before the environment is ready.

For a site outage, validate that the recovery design’s IP mobility and inter-instance connectivity assumptions still hold.

Start Application Recovery in Waves

Application recovery should be wave-based, not a mass power-on exercise.

A practical sequence is:

1. Shared infrastructure required by applications.
2. Core identity, database, messaging, and middleware services.
3. Tier-one applications.
4. Tier-two applications.
5. Lower-priority services.
6. Reporting, batch, and nonessential workloads.

Each wave should have entry criteria, technical validation, application-owner approval, and a stop decision.

Post-Restore Consistency Checks

The recovery is not complete when every appliance is powered on. It is complete when the platform has reached a consistent and supportable state.

Do not erase the evidence of a successful recovery test by immediately returning to normal operations. Preserve the logs, timelines, configuration changes, and results.

Common Failure Patterns and Fallback Decisions

The Backup Exists but Cannot Be Used

Symptoms

• The backup catalog is visible, but credentials fail.
• The encryption passphrase is unknown.
• The backup target cannot be reached from the recovery site.
• The required restore version is unavailable.

Response

Stop the restore attempt. Do not repeatedly guess credentials or alter the only available backup copy. Recover the credential, establish controlled connectivity, or retrieve the correct binary through the approved process.

The Recovery Environment Uses Different IP Addresses or FQDNs

VCF instance recovery is not a general-purpose migration workflow. Broadcom requires the target recovery environment to preserve the original IP addresses and FQDNs for the supported instance-recovery process.

Response

Do not improvise address translation inside the reconstruction workflow. Reassess whether the scenario requires fleet disaster recovery, a supported migration, or assistance from Broadcom Support.

The Restored Components Contain Different Points in Time

A recent vCenter backup combined with an older NSX or SDDC Manager backup can create inventory and policy inconsistencies.

Response

Pause before workload recovery. Compare backup timestamps, configuration changes, and product relationships. Use the supported reconciliation and synchronization tasks. Escalate when consistency cannot be proven.

The Backup Platform Failed with the Management Domain

Response

Use the documented backup-platform recovery path or an independently accessible secondary repository. After the incident, redesign backup management so that recovery does not depend exclusively on the protected domain.

Federated Authentication Is Unavailable

Response

Use the approved local or break-glass account. Do not change identity configuration unless the runbook requires it. Record every emergency login and rotate credentials after recovery.

Certificate Validation Blocks Service Registration

Response

Compare the recovered service identity with the certificate record. Check DNS, subject alternative names, issuer trust, validity dates, and time synchronization before replacing certificates.

The Platform Is Partially Healthy but Inconsistent

Response

Do not begin an in-place sequence of ad hoc repairs across multiple distributed control planes. Isolate questionable components, preserve logs, identify the last consistent checkpoint, and use the supported component or instance recovery path.

Rollback and Fallback Principles

Traditional rollback is difficult after distributed management components begin accepting new state.

Use these controls:

• Define a stop point before each recovery stage.
• Prevent restored components from becoming externally authoritative until validated.
• Keep temporary recovery networks isolated where possible.
• Preserve the previous failed or partially restored state for diagnostics.
• Do not allow both protected and recovered management planes to operate simultaneously.
• Record all DNS, routing, certificate, and credential changes.
• Revert DNS and network changes as a controlled transaction.
• Select another known-good backup only after the previous attempt has been isolated.
• Contact Broadcom Support before improvising database-level changes.
• Treat failback as a new controlled change, not as the reverse button for failover.

The safest fallback is often stopping before a questionable component begins changing other systems.

Quarterly Recovery-Test Evidence

A quarterly exercise should prove more than backup-job success.

Use a rotating test plan so that the organization validates different layers over the year.

A mature test should occasionally assume that convenient dependencies are unavailable. For example:

• The primary password vault cannot be reached.
• The backup console is down.
• The primary identity provider is unavailable.
• Internet access is disabled.
• The newest backup is rejected because of suspected compromise.
• The protected site remains partially reachable and must be fenced.
• A critical certificate has expired.
• The designated recovery engineer is unavailable.

That is how the organization distinguishes a documented procedure from a recoverable platform.

Operator Runbook Summary

Conclusion

A VCF 9.1 disaster-recovery strategy is incomplete when it protects workload virtual machines but leaves the recovery control plane inside the same failure boundary.

The management platform has its own recovery requirements. SDDC Manager, vCenter Server, NSX Manager, VCF Operations, VCF Management Services, identity, licensing, lifecycle services, software depots, protection appliances, and external dependencies do not all use the same backup or recovery method. They must be protected according to their state model and restored according to their dependencies.

The most important operational control is choosing the correct recovery model. Use component restore for an isolated failure, VCF instance reconstruction for a failed instance in the same site, and VCF fleet disaster recovery for an instance or site outage requiring recovery elsewhere.

Then recover in layers: external dependencies, infrastructure foundation, core management, fleet services, workload recovery services, and finally application recovery waves.

A successful quarterly test should leave behind evidence that the platform can be recovered by the assigned team using accessible backups, valid credentials, preserved binaries, working network paths, trustworthy certificates, and an offline runbook.

That is what turns workload protection into platform recoverability.

External References

• Broadcom TechDocs: Component Backup and Restore of VMware Cloud Foundation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation.html
• Broadcom TechDocs: Back Up SDDC Manager
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-backups-for-sddc-manager-and-vcenter-server/back-up-sddc-manager.html
• Broadcom TechDocs: Configure a Backup Schedule for vCenter
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-backups-for-sddc-manager-and-vcenter-server/configure-a-backup-schedule-for-vcenter-server.html
• Broadcom TechDocs: Image-Based Backup for VCF Operations
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/configure-vmware-cloud-foundation-operations-vm-level-backup.html
• Broadcom TechDocs: Configure SFTP Backup Location for VCF Automation and VCF Management Services
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/configure-sftp-backup-target-in-vmware-cloud-foundation-operations.html
• Broadcom TechDocs: File-Based Restore for SDDC Manager, vCenter, and NSX
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-restore-for-sddc-manager-vcenter-server-and-nsx-t-data-center.html
• Broadcom TechDocs: Restore an NSX Manager Cluster Node
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-restore-for-sddc-manager-vcenter-server-and-nsx-t-data-center/restore-nsx-t-manager.html
• Broadcom TechDocs: VCF Instance Backup and Restore
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/-vmware-cloud-foundation-instance-recovery.html
• Broadcom TechDocs: Sequence Optimization for Restore of a VCF Instance
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/-vmware-cloud-foundation-instance-recovery/vmware-cloud-foundation-instance-recovery-plan.html
• Broadcom TechDocs: Management Domain Restore Plan
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/-vmware-cloud-foundation-instance-recovery/management-domain-recovery-plan.html
• Broadcom TechDocs: VCF Fleet Disaster Recovery
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/vcf-fleet-disaster-recovery.html
• Broadcom TechDocs: Prerequisites for VCF Fleet Disaster Recovery
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/vcf-fleet-disaster-recovery/fleet-disaster-recovery-task-library/implementation-of-site-protection-and-disaster-recovery.html
• Broadcom TechDocs: Detailed Design for Site Protection and Disaster Recovery for VMware Cloud Foundation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vvs/9-X/site-protection-and-disaster-recovery-for-vmware-cloud-foundation/detailed-design-for-site-protection-and-disaster-recovery.html
• VMware Cloud Foundation Blog: How to Upgrade to VMware Cloud Foundation 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/06/18/how-to-upgrade-to-vmware-cloud-foundation-9-1/
• Broadcom Knowledge Base: VCF Fleet Manager Binary Missing During VCF 9.1 Download
  Canonical URL: https://knowledge.broadcom.com/external/article/441340/vcf-fleet-manager-binary-missing-during.html
• Broadcom Knowledge Base: VCF Instance Recovery to Environment with Different IP/FQDN Is Not Supported
  Canonical URL: https://knowledge.broadcom.com/external/article/439975/vcf-instance-recovery-to-environment-wit.html

The post Protecting the Recovery Control Plane: A VCF 9.1 Management-Component Backup and Fleet DR Runbook appeared first on Digital Thought Disruption.