Back up the vCenter appliance to storage that remains accessible when vCenter is unavailable, then prove that an operator can rebuild the management service. A repository containing files is not enough: the recovery workstation, installer, credentials, DNS, host access and encryption material must also be usable.
This guide is a rehearsal for a standalone lab vCenter and synthetic inventory. Enhanced Linked Mode, vCenter HA and production replacement require different coordinated procedures. No appliance was backed up, stopped or restored for this draft.
1. Separate the protected service from its dependencies
Create a manifest with vCenter version/build, appliance deployment and storage sizes, FQDN, network settings, SSO domain, authentication dependencies and backup location. Record which ESXi hosts and management networks can support recovery without a functioning vCenter.
Keep the manifest outside the appliance. Store access and encryption secrets in the approved recovery vault rather than in the manifest itself. A recovery design that requires logging into a VM controlled only through the missing vCenter has a circular dependency.
vCenter supports file-based and image-based backup approaches. Broadcom recommends the appliance's management interface for its file-based workflow. Do not substitute a long-lived VM snapshot for an independent backup. Backup and restore overview: https://knowledge.broadcom.com/external/article/318731/overview-of-backup-and-restore-options-i.html
2. Prepare the repository and trust path
Use an existing supported repository endpoint with sufficient capacity, controlled access and a retention design. Confirm the backup appliance can reach it and that a recovery workstation can independently retrieve the required material. Record the approved transport and port privately.
Do not equate an encrypted transport with verified server identity. Broadcom documents explicit certificate/host-key validation configuration for appliance backup and restore. Review its exact applicability to the installed build and arrange changes through a separate maintenance plan where service interruption is involved. Secure backup and restore configuration: https://knowledge.broadcom.com/external/article/310399/enabling-secure-backup-and-restore-in-th.html
Avoid copying service-restart or trust-file-edit commands into an ordinary backup runbook. First identify the active trust behaviour, authorised certificate/key source and recovery procedure. The article's source contains older paths and multiple transports; only use the supported procedure for the actual release.
3. Create and inspect one manual backup
Sign in to the appliance management interface on its documented management port, open Backup and review the manual backup form. Select the approved repository, access identity and any configured backup encryption. Record the chosen scope, including whether optional historical statistics/events/tasks are included.
Submit one lab backup. Retain the resulting timestamp, completion status, destination and warnings. Confirm the repository contains the completed backup set rather than a partially written directory. Record backup size and runtime as observations, not acceptance of restore capability.
A successful job does not establish that the repository can survive loss of the appliance's datastore or credentials. Test access from the recovery side separately. If adding a recurring schedule later, give it an owner, monitoring and retention requirements; this guide does not create or authorise a schedule.
4. Build a truly isolated restore environment
Provide an ESXi recovery host accessible directly by the authorised operator, an approved datastore and an isolated management network. Supply lab DNS and time services with the expected names. If reusing the original lab appliance identity, ensure the original and replacement can never be active in the same reachable network.
Test isolation in both directions before restoring. Block access to production ESXi hosts, identity providers, backup integrations and other management endpoints unless an explicit separate design permits it. A restored inventory contains references and credentials that must not accidentally manage the original estate.
Retain the original lab appliance and its evidence until recovery is accepted. Do not delete it to free space for an unproven replacement. Ensure the recovery host has enough capacity for both the protected evidence and the new test appliance.
5. Use the supported two-stage restore path
Obtain the full installer compatible with the backup's recorded version/build and verify its integrity through the official distribution process. Launch its Restore workflow from the recovery workstation. Review backup metadata and the deployment target before accepting any creation step.
Stage 1 deploys a replacement appliance. Stage 2 transfers the backup data and completes recovery. Broadcom's file-based restoration example: https://knowledge.broadcom.com/external/article/437137/error-sqlerror-was-thrown-odbc-error-42p.html describes the installer path; its unrelated direct database-repair option is not part of this guide.
Select the deployment/storage sizing required by the backup and supported restore workflow. Broadcom documents failures where the chosen appliance storage size differs from the original deployment. Do not choose a smaller destination simply because the compressed backup is small. Restore storage-size constraint: https://knowledge.broadcom.com/external/article/367608/restore-of-vcenter-server-may-fail-if-a.html
For the lab, confirm the target host, datastore, network and appliance identity one final time before deployment. Preserve each stage's job record. A completed OVA deployment alone is not a restored vCenter.
6. Diagnose failures before repeating deployment
If Stage 2 cannot start, distinguish workstation-to-appliance management access from appliance-to-repository access. Check DNS, routes, trust, authentication, available space and installer logs for the exact failure boundary.
Also verify that the recovery host can connect the replacement appliance to its intended management port group without the unavailable vCenter. Broadcom documents Stage 2 failures associated with network selection and distributed port binding in restore management connectivity: https://knowledge.broadcom.com/external/article/412440/the-installer-is-unable-to-connect-to-th.html. Design and test the recovery network beforehand; moving a live uplink or restarting services from that troubleshooting article is not an automatic recovery step.
Protocol compatibility can vary by installer patch. Broadcom documents an SFTP-related installer defect resolved in a particular vCenter 8.0 update. Match the error and affected builds before considering that remedy; do not weaken the repository's SSH algorithms as a generic fix. Installer/SFTP restore issue: https://knowledge.broadcom.com/external/article/388432/performing-a-restore-of-vcenter-server-u.html
Repeatedly deploying new appliances can produce duplicate identities and consume capacity. Inventory the partial attempt and obtain a reviewed cleanup decision before restarting. Never edit the backup database or run a schema repair merely to get an installer to finish.
7. Prove management service recovery
After Stage 2 completes, check appliance health and sign in using the intended recovery identity. Confirm inventory objects, permissions, expected configuration and representative historical information for the selected backup scope.
Use only isolated lab hosts for reconnection and management tests. Verify a read-only inventory operation, an authorised disposable-VM operation and a representative integration connection. If a restored integration cannot be tested without contacting production, label that dependency unverified.
Perform an access-denial test for a non-administrative lab identity. Check certificate trust and logging. Then prove that the restored appliance can create a new backup to an approved lab destination. Recovery is incomplete if future protection cannot resume.
Timing, acceptance and cleanup
Define the business RTO as the permitted interruption to the required management service. Measure a drill's execution time separately from a real outage's detection, decision and access delays. Record declaration, operator access, deployment, data import and successful management acceptance as distinct timestamps.
Record the backup's point in time and compare restored configuration with the manifest. A configuration change made after that point should not be expected to appear. A successful VM inventory does not prove every host configuration or encryption key has been independently protected.
Accept the rehearsal when expected data/configuration, authorised access, denial behaviour and test management operations pass. Keep Enhanced Linked Mode, HA and external key-provider recovery explicitly outside the result. Cleanup removes only the identified isolated replacement after evidence is retained. Production replacement and any return to the original appliance need a separate change-of-authority plan.
Related topics: platform hardening, ESXi maintenance and application recovery.
Learning notes
- Recovery access must work without the service being recovered.
- Deployment completion and restored management capability are separate milestones.
- Restore execution time alone does not establish compliance with an outage-based RTO.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.