vCenter Server Appliance backup and protection

• Author
• Recent Posts

Vladan Seget

Vladan Seget is an independent consultant, professional blogger, vExpert 2009-2021, VCAP-DCA/DCD and MCSA. He has been working for over 20 years as a system engineer.

Latest posts by Vladan Seget (see all)

• How to use VMware vSAN ReadyNode Configurator - Fri, Dec 17 2021
• VMware Tanzu Kubernetes Toolkit version 1.3 new features - Fri, Dec 10 2021
• Disaster recovery strategies for vCenter Server appliance VM - Fri, Nov 26 2021

If you lose vCenter Server, you basically lose a central point of management. But not only that—your backup and replication software will stop working because it's hooked up to vCenter. In addition, your monitoring or diagnostics software will stop working if you're using one.

However, by losing VCSA you're not losing high availability (HA). There is no impact to running VMs or failover of the host. HA will function without any problems, but you won't be able to make any configuration changes.

In this post, we'll look at few simple ways to protect your VCSA.

Option 1: Back up the VCSA VM with backup software

This option will simply do a daily backup of your vCenter and store the backups in a backup repository along with other VMs you're usually backing up daily.

If your VCSA gets corrupted, becomes unbootable, or the data store where VCSA is running becomes unavailable, you can restore from a backup. Your backup server should be a physical server separate from your virtual infrastructure. It would not really be a good practice to use one of your infrastructure VMs as a backup server.

What would happen if anything were to go wrong within your virtual infrastructure? You'd lose access to your backup server and your backups. How would you restore then? Follow the best practices for physically separating your backup server from your virtual infrastructure. Store your backups elsewhere then at a repository located on your production storage where all your VMs are running.

One thing to remember: You must register at least one standalone ESXi host in your backup console. This is because when your VCSA becomes unavailable, you'll need to point back to some target. And this target will be a standalone ESXi where you'll restore your backup.

This will vary from vendor to vendor. As an example, I can show you a Veeam Backup console where I have registered such a host.

Register at least one standalone ESXi host

By backing up your VCSA daily, you not only have a daily backup, but you also have a history that depends on the retention policy. It can be the last two weeks or one month of backups.

Option 2: Built-in file-level backup of VCSA

This option will back up the configuration, performance, and historical data. You can store this information on another system. However, when you need to restore it, you must first deploy a clean VCSA from an .ova file. And it takes some time.

You can find the file-level backup option when you connect to the management user interface (UI) of the appliance at https://IP_or_FQDN:5480.

Go to the Backup menu and create your schedule. Depending on which protocol you chose, your screen details may vary. In an example below, you can see a simple FTP server setup.

The supported protocols for backup are FTPS, HTTPS, SCP, FTP, and HTTP.

Create a backup schedule

As you can see, you have some choice when it comes to which date you'll back up. You can uncheck the Stats, Events, and Tasks checkbox, which in my case saves only 1,866 MB, but in larger environments, this number will be higher.

Option 3: Set up VCSA HA

This is not really a backup option, but it lets you maintain a standby copy of the VCSA which is ready to be powered on when the primary appliance becomes unavailable.

So how does this work? It clones VCSA to create passive and witness nodes. It replicates up-to-date data between the active and passive nodes. If there's an outage on the active vCenter Server VM, the passive vCenter VM automatically takes over the active role and identity, including networking.

This feature is only available for VCSA, not for vCenter on Windows. However, you'll need at least three hosts in your environment, managed by vCenter Server, to spread the different nodes. Remember we have passive VCSA as well as witness nodes that must run on a separate ESXi host.

Before starting the workflow, make sure you create a new VM network on a different subnet or different virtual LAN (VLAN) than the management network. In my case, I have created a new VM network called VCSA_HA.

Now let's start by going to vCenter > Configure > vCenter HA > SET UP VCENTER HA.

Configure vCenter Server HA

vCenter HA protects not only against host and hardware failures but also against vCenter Server application failures. Using automated failover from active to passive, vCenter HA supports high availability with minimal downtime.

On the next screen, you should at first select the VCSA_HA network previously created on each host and then select the placement of the nodes on a separate ESXi (best practices).

Scroll down to the vCenter HA resource settings and review the network and resource settings of the active node of the vCenter Server. Then scroll down to the passive node and click Edit. Follow the on-screen prompts to select a folder location, compute, and storage resources.

Select the management and HA networks for the passive node, review the settings once complete, and click Next.

Place the nodes on separate hosts and data stores

Note: In my lab case, I only used a single ESXi host for testing.

On the next page, we'll see the networking option. Remember you must be on different subnet. If not, the wizard will fail at the end.

Enter the networking details for VCSA HA

Then click the Finish button.

The system will automatically clone the VCSA. It will take some time depending on the performance of your infrastructure and the underlying storage. You can click the Recent tasks link to follow up on the cloning process and wait until all three nodes are up.

Wait until all three nodes are up

After like 10 minutes of waiting, at the end, you should see all the nodes with green checkboxes.

All nodes are up and running

However, you should know that the passive and witness nodes keep running, so they consume resources such as CPU and storage.

Thus, if you're in a really small environment, do not use this method, but rather take a regular backup with your backup software or set up a file-level backup only.