- 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
One also has to think that VCSA and the vCenter Server have dependencies. Other products you might be using in your environment might be using vCenter as a base. All backup and replication software and monitoring and reporting solutions use vCenter Server.
In the past, VCSA had several problems where patching did not go smoothly, and the results were not as expected. I always check that I have some kind of backup of VCSA before starting to patch.
In larger environments, you could probably set up VCSA HA, but while it is VMware's native solution for protecting VCSA, it uses quite a lot of resources. Your VCSA cluster will run three instances at the same time (active, passive, and witness), and each will consume CPU cycles, storage, and memory. So, for small environments running on vSphere Essentials (three hosts), this is quite a lot.
For such a small environment with a single copy of VCSA, you have several solutions for protection. Each of those solutions will depend on the products you're using in your environment. You can use your backup solution to create a backup of the VCSA virtual machine (VM) itself; as long as it is not running in linked mode, it's fine.
During the restore (if needed), as the VCSA VM won't be available, you'll have to point your backup software to an ESXi host where you want to restore.
Native VMware protection—a file-level backup
VmWare’s native protection is one simple solution that allows you to back up inventory, configuration, stats, events, and tasks. However, if your VCSA dies for some reason and you would like to restore, you'd have to proceed with two phases:
Note: You will need to use the same ISO (the same build) that is used for a new installation, and you will need to select the "Restore" option. Then, continue as you would with a new installation.
1st phase—Deploy a fresh new VCSA appliance.
2nd phase—Restore the inventory and configuration from the file-level backup.
If the vCenter was in Enhanced Linked Mode configuration, you will receive a prompt to point to a PSC with an existing SSO domain; you can safely restore to the working one. This method obviously makes the restore process longer as you first have to deploy fresh VCSA and then restore the inventory.
Below is a screenshot from the vSphere Appliance Management Interface (VAMI), where you can set up the file-level backup.
VCSA file level backup schedule
Use your usual backup software to create a replica (stand-by) VM
You can use the backup software that you use to back up your production VMs and create a replication job for your VCSA. This scenario is perfect because your replication job can run, let's say, twice a day and keep a copy of your VCSA in "sleep mode" on another ESXi host within the same datacenter.
If you don't know how replication works, here's what happens. The backup and replication software will do a first-time full copy of the VM to another ESXi host, and then, each time the replication job runs, only increments are sent to the remote site. The increments are merged at the remote site, so once the replication job finishes, the VM is up-to-date. In this way, the replica VM is up to date each time the replication job runs. You can set up a replication job to run every couple of hours or just once a day.
Below is an example of a replication job with Veeam Backup and Replication software. (Note: Many backup vendors that support the vSphere platform can probably do the same.)
Veeam replication job for a VCSA
If I wanted to simplify the restore operation and not use the Veeam software for the steps, I'd simply start the stand-by VCSA VM.
When your VCSA isn't available and you want to be up and running fast, simply start the replica VM by connecting directly to the ESXi host via the ESXi host client. That's all. You're back online with your vCenter.
Start your replica of VCSA directly from the ESXi host
Once you have the vCenter Server up and running, you can connect to your vCenter via the same IP address or FQDN. What has changed is only the VM's name. In my case, the VM's name is now "vcsaphoton_replica".
Running vCenter Replica VM
What is happening is that this VM now needs to be protected again. So you'd have to delete the old VCSA, which was corrupted. You'd also have to delete the replication job and create a new replication job to protect the new VM.
In this solution, you're not losing any time. If your initial replication job runs every hour, you're losing only one hour of changes. If you wanted to use the traditional backup of the VCSA VM, you would lose time when you restored the VM because the backup software would have to do a full restore, and the VM's size is about 55 Gigs.
Simple snapshot of VCSA
There is nothing wrong with creating a snapshot of VCSA before patching, as long as you don't keep the snapshot after patching is complete and you verify that everything works (including your backup and monitoring software) as expected.
Take a snapshot of VCSA before patching
You have a snapshot, so you can revert to the previous state before you patched. This is fine, but this solution won't save you when your VCSA crashes, if the VCSA DB has some problems, if some services start failing, etc. You need to have regular backups or replication.
You cannot run your VCSA VM with snapshots. It's not recommended for any VM. Snapshots are not backups; however, they can be used for short-term saves if you're willing to patch.
Final words
Usually, the best strategies are the simplest. I'd recommend having backups of your VCSA, and as many as you can. If you can, create a file-level backup in VAMI, and also use your backup software to create replicas on a regular basis.
Subscribe to 4sysops newsletter!
The replication method saves time when you need to restore. You can also have two replication jobs, where each job replicates to different remote ESXis and different datastores according to different schedules. You can never be overprotected.
