- How to configure VMware vSAN Direct on vSphere 7 U1 - Wed, Nov 25 2020
- Configure and manage SMB shares on vSAN 7 U1 - Wed, Nov 18 2020
- VMware vSAN 7 U1: Configure vSAN File Service - Wed, Nov 11 2020
VMware vCSA holds a large amount of configuration information about your environment and has dependencies to other backup and monitoring products, with many third-party plugins installed. It is quite crucial to perform regular backups of vCSA and its configuration. The best practice is to separate the backup of the configuration from the backup of vCSA.
You can do an image-level backup or a file-level backup. However, there are other considerations. The image-level backup can be perfectly done via third-party backup software such as Veeam, Nakivo, or others, as long as the vendor supports the backup and restoration of vSphere 7.0. Not all vendors have confirmed support for vSphere 7.0 as of yet.
The vCSA has to use the fully qualified domain name (FQDN) with correct DNS resolution. Your forward and reverse DNS static records must exist at your DNS server, and the resolution must work both ways.
The VMware vSphere Storage APIs – Data Protection framework is used by those backup software products to do a backup of all your virtual machines (VMs), including the VMware vCSA.
So basically, the software product is able to back up a vCSA VM and do a restore. In order to restore the vCenter itself, you must connect directly to an ESXi host to initiate the restore operation because vCenter is unavailable during the restore.
Limitations and considerations ^
VMware vSphere Distributed Switch: If you're using a VMware vSphere Distributed Switch (vDS) in your environment, VMware recommends backing up the vDS separately. What you need to do, in fact, is an export of the vDS configuration before performing the backup.
In this way, you can reimport the configuration after a restore if you see some inconsistency within your network configuration. In this case, it is possible to have a separated backup of the specific vCenter networking component, which is configured via vCenter and deployed to each ESXi host.
Content Libraries: Yes, content libraries are vCenter-dependent objects. If, for example, you delete some items or templates within the content library after you make a backup, the library item is missing when you want to restore. It's a dependency that you might want to take into consideration.
vCenter Server HA: You'll need to reconfigure vCenter High Availability if you know vCenter HA is a system where a second and third node of vCSA are used to ensure failover and failback, in case vCenter becomes unavailable.
Restoring a vCenter Server requires reconfiguring vCenter HA. If you know that you'll be restoring vCenter server, VMware recommends destroying the configuration prior to restoring, and then restoring and reconfiguring vCenter HA again.
VMware file-level backup ^
The file-level backup, introduced in vSphere 6.0, is a convenient way to have an up-to-date, granular backup of your full configuration if you don't do regular image-level backups or your software vendor does not support vSphere 7.0 just yet if you have already upgraded your vCenter Server to version 7.0.
File-level backup can be configured by connecting to the vCSA admin user interface (UI) via https://IP_of_appliance:5480.
There, you can configure scheduled backups of different files, including the vPostgres DB. One interesting feature of the file-level backup is that the process verifies the DB before making the backup.
Also, if you want to restore the whole vCSA, you must use the same installer ISO, because the installer and backup versions must match.
Many options and storage protocols are supported for configuring the destination of a scheduled backup. The protocols supported for backup are FTPS, HTTPS, SFTP, FTP, NFS, SMB, and HTTP. In my lab, I simply used SMB for my file server.
Various options can be configured or disabled. For example, the DB health check and the stats, events, and tasks do not need to be backed up in some environments.
These are the supported backups of vCSA.
If your DB is larger and its size is greater than 300 GB, your backup will most likely fail.
Quote from VMware release notes:
If the vCenter database size is 300 GB or greater, the file-based backup will fail with a timeout. The following error message is displayed: Timeout! Failed to complete in 72000 seconds.
And the bad news is that currently there is no workaround.
In this post, I explained the complexity of the vCSA backup, with its limitations and dependencies. When done right, the restore is not problematic. However, when dealing with many dependencies and a complex vSphere environment, you'd better be sure that your backups are done properly, in a way that is supported.
It is a good practice to try to run some test restores from time to time. If you can isolate part of your network, you can perform a full restore. See how it goes, whether your backup is consistent and the vCenter Postgres DB remains in a consistent state as well.
The restore operations of vCenter Server should be well documented and be part of a disaster recovery plan.
In one of our future posts, we'll perform a detailed restore of vCSA to show you the whole process for the file-level backup.