- 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
VCSA, like other VMs within a virtual infrastructure, can have problems. These can range from internal VM corruption or a problem with one of the VMDKs located on a datastore. Anything can happen.
With a new version of VMware vCenter Server Appliance (VCSA), the operating system (OS) has been updated to Photon OS 3.0. Some underlying services have changed, were phased out, or were upgraded to new versions.
If you've been running VCSA for several years, most probably you have upgraded to vCSA 7.0 from a previous release. It's entirely possible that your VCSA 7.0 might run into different sorts of problems.
vCenter Server is the heart of the system, where many external monitoring and backup solutions are "hooked" up. The Primary Network ID (PNID) is usually configured and assigned with each new vCenter server installation. To ensure those external applications can continue to function, you must restore your vCenter with the exact same settings, including the PNID; otherwise, you'll have to reconfigure you backup solution again along with your monitoring solutions. The dependencies on vCenter Server might be numerous.
The best practice is usually to keep separate backups of your VCSA, with the configuration backup (file level) done via the VAMI user interface on one side, and an image-level backup of the full virtual appliance (VA) with all its settings on the other.
With the file-level backup, you back up the stats, events, and tasks as well as inventory and configuration. All these elements can be restored to a freshly deployed VCSA if the restore from image-level backup fails for some reason.
In this post, we'll show you the steps for restoring vCenter Server via the built-in wizard. The restore process is not really difficult, but there is some information you should know.
Before we start, I'd like to point out that the VMware file-level backup/restore utility needs to have the same versions on both ends. Let me explain. If, for example, you have file-level backups that were created on a certain version number of VCSA, they can only be used on the same version. (The installation ISO for restores must be identical.)
What happens is that if the file-level backup was taken on a different version of VCSA, you'll get an error message:
You should make sure that each time you upgrade your VCSA, you immediately make a backup (if not scheduled periodically). Even better: before upgrading your VCSA, be sure to make a new file-level backup.
Another backup option to point out is an option that allows you to enable DB Health Check before the periodic execution of the backup. It might take a little longer, but you'll have more insurance that your backup is actually a non-corrupted backup. I strongly recommend leaving this option on.
Make sure to enable DB Health Check
Steps to restore VCSA from backup
First, let's mount the VMware vCSA ISO file on your system (Windows, Linux, or Mac OSX). Then, within the file structure, find the installer and execute it.
From the menu, choose the Restore icon and click on it.
Restore VCSA from backup
What is happening here is that you have to actually redeploy a clean VCSA first. As you can see in the image below, there is an assistant similar to the one you see during a green field deployment.
You might think the steps are identical, but no. The second step, as you'll see, will ask you for a backup location.
Deploy a clean VCSA first
Then you'll need to specify the backup location. We assume here that you have that backup location on your network already set up, and you have also set up a periodic backup. In the case of my lab, it is a file server in my domain.
Specify the backup location
So it is absolutely vital that for every VCSA you deploy, you automatically create and configure a file-level backup location. Only in this case, when needed, can you use this for restores and use the VMware assistant provided on the VCSA ISO.
Let's continue with the next step. You need to specify the vCSA deployment target. This can be an ESXi host or a vCenter Server.
Specify the vCenter Server deployment target
Then we have to set a meaningful name for this VM. This is the name that will appear in the virtual infrastructure user interface console, not a fully qualified domain name (FQDN) or VMware calling it PNID.
Set the target VM name
Regarding the size of your environment, it depends on your particular installation. In our test lab, we'll keep the default, which is the "tiny" option.
We keep the default sizing information
Then we can select the Enable Thin Disk Mode option to save some space on the destination datastore. However, in our case, we have specified a vSAN datastore as the destination, which, by default, makes all objects thin-provisioned.
Enable Thin Disk mode
Once done, the next step is to configure the network settings. Enter the settings that reflect your environment.
Configure your network settings
Then the wizard will initialize the restore job and deploy a clean VCSA with the information you specified, including the restore location.
The wizard will initialize the job
Once restored, you'll find your initial vCenter Server to be the same as it was during the period when the backup was made.
Note: I have received a notification to increase the memory of the VM, as the "Tiny" option deploys a VM with only 12 Gb of RAM and the wizard asked for 16 Gb of RAM.
I think that with 12 Gb of RAM you'll hit some limits. Some services might not be able to start in a timely way and will most likely trigger errors like this one.
Conclusion
The assistant is good and provides an easy way of restoring from file-level backups. However, this method might take a bit longer than a restore via the traditional backup/restore tools everybody uses within their backup infrastructure to protect their production VMs.
Subscribe to 4sysops newsletter!
However, you have that granularity. You only need to deploy a clean VCSA and restore some files. From my experience, I'd keep using both backup methods in case one of them fails. It is always good to have an alternative.
Good post, my environment has VSAN and distributed switch, Would there be any issues to restore using this method?
Distributed switch configuration is stored in vCenter DB as far as I know. So you should be fine.
its worth mentioning that you can ONLY to a restore from the VCSA setup iso if its on the same version otherwise error: The installer and the backup must be the same version.
VMware does not keep old VCSA appliances on their download site. So if you have a failed upgrade and you made a backup, you are SOL because the VCSA installer is on 6.7U3 and you need to do the restore from 6.7U2 which no longer exists.
disregard. I found old version
Yeah, true that Dan, better keep the same version original ISO somewhere on USB or LAN that you installed from -:). ++