I wanted to understand how Supervisor backup and restore behaves in practice—what vCenter brings back, how the environment behaves during recovery, and where the gaps are.

In my VCF 9.1 lab, I configured scheduled Supervisor backups, completed a manual backup, and restored the Supervisor from a fresh recovery point. I followed an existing VKS cluster in VCF Automation while restoring the Supervisor, then repeated the exercise after introducing different kinds of drift between the recovery point and the restore.

In my tests, vCenter rebuilt the Supervisor management state, but that did not automatically bring every VKS cluster or dependent service back with it.

Why back up the Supervisor control plane

The Supervisor is the management plane for every vSphere Namespace and VKS cluster attached to it. Losing or corrupting its control-plane state can therefore affect multiple tenants and Kubernetes services at once, even when the surrounding vCenter infrastructure is still available.

Including Supervisors Control Plane in the vCenter file-based backup creates a supported recovery point for that state. During recovery, vCenter deploys replacement Supervisor control-plane VMs and reapplies the backed-up Kubernetes and vCenter-managed configuration. Without that recovery point, restoring vCenter alone does not also reconstruct the Supervisor state.

Take the backup from a healthy state

Broadcom recommends creating the recovery point while the Supervisor is healthy and shows Running.

The product documentation advises against taking a Supervisor backup during:

• a Supervisor error
• an active or failed Supervisor upgrade
• a Supervisor Service upgrade
• a VKS upgrade

A backup may still complete during one of those conditions, but Broadcom does not consider that sufficient evidence that the recovery point is suitable for restore.

What the backup protects—and what it does not

According to Broadcom’s VCF 9.1 documentation, the Supervisor option in the vCenter file-based backup captures the state needed to rebuild the Supervisor control plane. This includes etcd, the Kubernetes CA, infrastructure images, vSphere Namespaces, Kubernetes resource state, and the Supervisor configuration managed by vCenter.

During a restore, vCenter does not reuse the existing control-plane VMs. It replaces them with three new VMs and applies the state from the selected recovery point.

The backup does not restore the workloads or persistent data inside VKS clusters. These require separate protection. Data stored by VM Service VMs also requires a compatible backup method.

According to Broadcom’s documentation, VKS cluster node VMs are included in the restore scope, but their presence does not necessarily mean that the cluster is ready to use. Networking, storage, platform services, and external dependencies still need to come back together.

In my lab, the VKS clusters depended on NSX-backed VPC networking and load balancing, along with DNS and identity services. I checked those separately after the restore.

Protect workloads running in VKS clusters separately

Broadcom documents the Velero Plugin for vSphere for backing up and restoring Kubernetes workloads running in VKS clusters. For a usable recovery plan, that means configuring scheduled Velero backups, protecting the required persistent data, storing the backup artifacts independently, and testing recovery before making Supervisor restore part of the plan.

I would not start a planned Supervisor restore without reliable, tested backups of the applications and persistent data inside its VKS clusters.

Configure and run the backup

To include the Supervisor control plane in the vCenter file-based backup, configure the schedule in the vCenter Management Interface:

1. Open https://<vcenter-fqdn>:5480 and select Backup.
2. Create or edit the file-based backup schedule.
3. Select Supervisors Control Plane.
4. Save the schedule and verify that the next backup completes.

This option covers every vSphere Supervisor managed by that vCenter. It is not selected per Supervisor.

After saving the schedule, VAMI showed the activated job, selected backup data, and retention setting.

I then initiated a manual backup to the SFTP target. The job completed in 15 minutes and transferred approximately 4.4 GB.

Broadcom’s VCF 9.1 guidance for file-based backups of SDDC Manager and vCenter Server recommends daily SDDC Manager and vCenter backups with seven days of retention. The appropriate schedule and retention still depend on the RPO, rate of change, and backup capacity available in the environment.

Prepare for restore

Supervisor restore replaces all three control-plane VMs and has no in-place undo. This makes it a recovery method for control-plane state loss or corruption, rather than a general fix for a failed lifecycle operation.

If vCenter must also be restored, record its exact build and make sure the matching installer is available. VAMI warns that the VCSA installer and backup versions must be identical; broad release compatibility is not sufficient for a vCenter file-based restore.

Before starting, I checked:

• the target Supervisor and intended recovery point
• compatibility between the current and backed-up Kubernetes versions
• changes made since the recovery point, such as new VKS clusters, service upgrades, node volumes, or vSphere Pods
• whether vCenter must also be restored to recover the required Supervisor configuration
• availability of compute, storage, management networking, DNS, NTP, identity, and other services on which the Supervisor depends
• that any workload backups needed for recovery are available and have been tested

I also planned how to validate the Supervisor, VKS clusters, networking, storage, and applications after the restore. A completed vCenter task is only the first checkpoint.

Start the Supervisor restore

Restore is initiated from Supervisor Management → Supervisors → Restore. The wizard has four steps.

1. Backup details

I selected Browse backup server folder, enabled Use backup location and username from vCenter backup schedule, and entered the SFTP server credentials.

2. Select backup

I selected the recovery point that corresponded to the manual backup created earlier. The timestamp and version shown here are important because the restore must use a compatible recovery point.

3. Select Supervisor

I selected the target Supervisor, eu-north-1-s1. The wizard validated the target, backup version, timestamp, and Namespace count.

4. Ready to complete

The final page showed the target, version, backup timestamp, and Namespace count. This was the last point where I could stop without changing the environment.

What happens during restore

The restore shuts down and replaces the existing Supervisor control-plane VMs. Shortly after I started it, the Supervisor entered Configuring and the vCenter task Restore Supervisor Control Plane state from Backup became active.

As the restore continued, vCenter deployed three replacement control-plane VMs and configured their management and workload networking. It then restored the core Supervisor services and brought the Kubernetes API load balancer back into service.

Near the end of the restore, Kubernetes showed READY and all three replacement control-plane VMs were Running, although the restore had not yet completed.

What VCF Automation showed during restore

The effect of the first restore was also visible in VCF Automation. While the Supervisor control plane was being reconstructed, VCF Automation could no longer retrieve the services associated with the Namespace.

The VKS cluster object remained visible, including its cluster class, Kubernetes release, VM class, and storage class, but its status changed from Available to Not Available.

The cluster object had not disappeared, but VCF Automation could not manage it while the Supervisor was being rebuilt. This management view did not prove whether applications inside the cluster remained reachable.

Restore completion and validation

In my first test, the vCenter task Restore Supervisor Control Plane state from Backup completed after about 43 minutes. The Supervisor and dependent services continued reconciling afterward, so a completed task did not mean that everything was ready yet.

Once the Supervisor had finished reconciling, VCF Automation again reported the unchanged VKS cluster as Available. I also connected to the cluster with kubectl and received responses from its Kubernetes API, confirming that the cluster was operational after the restore.

The VKS node VMs were not redeployed during this restore. Their creation timestamps remained from before the restore, while all three replacement Supervisor control-plane VMs had new timestamps.

Together, those checks confirmed that the cluster had recovered in both VCF Automation and through its Kubernetes API. They did not by themselves validate every workload, volume, or application transaction. The later node-volume test demonstrated why those checks still matter.

These are the checks I would run after a restore:

• the Supervisor reaches Running and its Kubernetes API responds
• the expected Namespaces and Kubernetes objects match the intended recovery point
• VKS control-plane and worker nodes have valid addresses, report Ready, and the workload-cluster API is reachable
• networking, load-balancer endpoints, DNS, identity, and other external services function as expected
• volumes attach and mount, and application data passes integrity checks
• representative workloads and application transactions succeed

Later restore tests

After the first restore, I ran two more tests to see what would happen when the environment no longer matched the selected recovery point. These were separate restore exercises, each with a different change made after the recovery point.

A deleted Namespace was not offered for restore

For the first test, I deleted the Namespace containing the VKS cluster. The recovery point had been created before the deletion.

The restore wizard still showed seven Namespaces in the recovery point, but selected only the six that remained in the environment. When I opened the details, the deleted Namespace was not listed. In this test, the wizard did not offer to recreate it.

A node volume added after backup disappeared from the cluster configuration

For the next test, I started from scratch with a new VKS cluster. Before taking the backup, I confirmed that VCF Automation showed it as Available and that I could connect with kubectl. Both nodes were Ready, and the platform pods were running.

kubectl get nodes
NAME                                                              STATUS   ROLES           AGE     VERSION
kubernetes-cluster-fl6k-7hfb4-j2lv2                               Ready    control-plane   6m31s   v1.35.5+vmware.1
kubernetes-cluster-fl6k-kubernetes-cluster-fl6k-np-k5ky-2tk6fsj   Ready    <none>          4m21s   v1.35.5+vmware.1

I took a fresh Supervisor backup, attached a node volume to the cluster, and then restored the Supervisor from the earlier recovery point.

After the restore, the node volume was no longer present in the VCF Automation configuration. This showed that the post-backup configuration change had been rolled back, although I did not establish what happened to the backing storage object or any data it contained.

The Supervisor eventually returned to Running, but the VKS cluster did not recover to an operational state. Its node VMs were powered on and VMware Tools was running, but they had only link-local IPv6 addresses and no usable IPv4 address. The workload-cluster API was unreachable.

I could not establish whether the networking failure resulted from the restore or from a condition specific to my lab. I therefore treat the two results separately: the node-volume configuration was rolled back, but the VKS cluster did not recover successfully.

Conclusion

In my lab, vCenter successfully rebuilt the Supervisor control plane from backup. The later tests showed that this was only part of the recovery. A deleted Namespace was not offered for restore, a node-volume change made after the backup disappeared, and one VKS cluster did not regain working network connectivity.

I could not establish the cause of that networking failure, so I would not treat it as the expected result of every Supervisor restore. It did show why I would check the VKS clusters, networking, storage, and workloads even after the restore task has completed and the Supervisor shows Running.

Most importantly, the Supervisor backup does not include the applications or persistent data inside VKS clusters. Before relying on Supervisor restore, I would configure scheduled Velero backups and test that I could restore the workloads and data that matter.

References

• Backup and Restore the Supervisor Control Plane, VMware Cloud Foundation 9.1
• When to Back Up and Restore the vSphere Supervisor Control Plane, VMware Cloud Foundation 9.1
• Backing Up and Restoring VKS Clusters and Workloads, VMware Cloud Foundation 9.1
• File-Based Backups for SDDC Manager, NSX Manager, and vCenter, VMware Cloud Foundation 9.1