- How to use vRealize Log Insight to retrieve logs from your Windows and Linux servers - Fri, Jul 23 2021
- Analyze basic log output from VMware vSphere 7 products - Wed, Jul 21 2021
- Analyze drmdump files with VMware DRS Dump Insight - Fri, Jul 9 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.
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.
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.
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.
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.
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.
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.
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.
Once done, the next step is to configure the network settings. Enter the settings that reflect your environment.
Then the wizard will initialize the restore job and deploy a clean VCSA with the information you specified, including the restore location.
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.
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.