Following on from my last blog post, I thought that it would be worthwhile taking the very good guide created by Kevin Soltow at VMware Blog (https://www.vmwareblog.org/backup-restore-vmware-vcsa-6-7/) and update this for vSphere 7.
Many people may not be aware that image based backups of vCenter servers utilising products such as Veeam are deprecated in vSphere 6.7 Update 3 and are no longer supported in vSphere 7. This means that the supported method of backing up a VCSA is either through the VAMI interface or utilising APIs.
Do not be alarmed, though. The whole process of backing up the VCSA through the VAMI interface has been improved dramatically since vSphere 6.5 and even includes a scheduler function to allow you to perform backups regularly using a schedule. The backups need to be performed to another system using either FTPS, HTTPS, HTTP, FTP and SCP. In my testing and the documentation below, I have been utilising FTP as it is a small test lab with no external access and this was one of the simplest things to configure. Please note that I do not provide the information on how to set up FTP or any of the other capabilities but information on these processes is readily available on the internet.
If you are concerned about having different backup methods for the VCSA compared to the rest of your environment which may use image based backup solutions such as Veeam, then one solution to this is to configure the VCSA backup using the instructions below to send the backup files to a virtual machine which is then backed up, or even replicated, with Veeam.
Creating a Backup using the VCSA VAMI interface
So, the first thing that you will need to do, is to log onto the VAMI interface which is done by browsing to the following location:
You should see a screen similar to below:
On the left hand side of the screen, at the bottom, you can see the ‘Backup’ entry. Click this to enter the backup screen.
As you can see from the screenshot above, I have already performed a manual backup and the history is shown in the ‘Activity’ section of the screen.
If you wish to just perform a single backup, then the simplest thing to do is to click the ‘BACKUP NOW’ button, you’ll then see a screen similar to below:
This should be fairly straightforward to fill in. You need to provide the backup location including the protocol and port number, plus any folders and subfolders. In my test environment, I was using FTP to a Windows IIS root share, so I entered something similar to: ftp://ipaddress:21/
The User Name and Password are the username and password that are required to access the backup location.
You have the opportunity to provide a password to encrypt the backup, if you wish to.
During the backup process, you can perform a DB Health Check – with the help information for this stating: ‘DB Health Check helps to determine the status of your database. Backup will take longer if the DB Health Check is enabled’
Underneath this section is the capability to only backup the Inventory and configuration or the capability to also backup the Stats, Events and Tasks. The backup interface provides you with a rough idea of the size of the data for each of the components. Obviously, if the data size is larger, then the backup will take longer to complete.
Finally on this page, you have the opportunity to provide a description to the backup.
Once everything has been entered correctly, you can click the ‘Start’ button to perform a single backup.
Please note that when the backup is created, it will be located inside additional folders within your destination. This is because similar backup processes may be utilised by different Photon based appliances in the future and each appliance could utilise the same destination for their file based backup methods.
If you browse through the folders created, you should see a number of files similar to below:
If you have been successful with the single backup, then you can utilise the same information to help create a regular scheduled backup.
To create the backup schedule, click the ‘Configure’ button next to Backup Schedule, you should see a screen similar to below:
As you can see the screen is almost exactly the same as the Backup Now screen, except for two differences which will be discussed below.
Difference 1 is that you now have the ‘Schedule’ entry listed. This allows you to configure how frequently you want the vCenter data to be backed up. Please note that the times that the backup will take place are listed as the vCenter server time. You have the option of performing the backups ‘Daily’, ‘Weekly’ or using a ‘Custom’ schedule. What this means, is that you can have the backup performed Daily and Weekly using those options or multiple times within a week utilising the ‘Custom’ option. Unfortunately, there is not an option to perform a monthly scheduled backup.
Difference 2 is a little further down the screen and asks the question of how many backups should be retained. On this, you have the option to retain all backups or only the last x number of backups, where you can enter the number of backups to retain. This may be dependent on your backup retention policy or available storage. Once again, you could retain a weeks worth of backups utilising this method and then have multiple versions of the destination VM backed up utilising an image based backup solution… which could extend your backups to monthly, with limiting the destination VM storage requirements to enough to house a weeks worth of daily backups.
Once you have filled in the rest of the information, you can click the ‘Create’ button and the schedule will appear in the list of backups.
If you are needing to restore the backups, you can utilise my previous post to assist with the restore process.
If Powershell is more your flavour, then you could utilise the excellent function created by Brian Graf and implemented into a great script by Magnus Andersson. The script is available here: http://vcdx56.com/2017/11/backup-vcenter-server-appliance-vcsa-6-5-using-powershell/
I have tried out the script with vSphere 7 and it does work as expected. As my Powershell and PowerCLI environments were newly installed, there were some tweaks I had to make to my settings in Powershell to allow untrusted scripts to be run etc., but these were too lengthy, although I cannot remember all of the steps I went through to get it to work.