- 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
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.
Export VMware vDS Configuration prior to backup
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.
DB health check prior to backup
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.
Backup options and ability to disable DB health check
These are the supported backups of vCSA.
Note:
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.
Conclusion
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.
Subscribe to 4sysops newsletter!
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.
Unfortunately it still seems only to work with SMBv1 enabled. If it's disabled (for security reasons), VCSA is not able to backup via SMB :-((
SMB2 support was (finally) fixed in VCSA 6.7 U3f or U3g (can't remember exactly when). SMB2 based backups work fine since then (also works well in VCSA 7.x)