The vCenter Server Appliance (VCSA) had several exclusive features introduced in vSphere 6.5. One of those features was the built-in file-based backup and restore. This native backup solution is available within the VMware Appliance Management Interface on port 5480. It supports backing up both the vCenter Server Appliance and Platform Services Controller (PSC). There is no need for any type of backup agents, nor is any quiescing or downtime of the VCSA or PSC required. The backup files are then streamed to a backup target using one of the supported protocols: FTP(s), HTTP(s), and SCP. These are all the files that make-up the VCSA, including the database.
Restoring the VCSA or PSC only requires mounting the VCSA ISO used during its deployment. Select the restore option and point to the backup protocol used. The restore workflow first deploys a new appliance, retaining its original identity. This is key since other solutions communicating to the VCSA will continue to do so as its UUID remains the same. Then it imports the backup files from the selected backup bringing the VCSA back online. Now with the release of vSphere 6.7 comes new enhancements for file-based backup and restore.
File-Based Backup 6.7
File-Based Backup has moved from under the summary tab and to its own backup tab. Front and center are several noticeable changes when going into the new backup tab. At the top, there is now an informational banner about the supported backup protocols. One of these protocols must be set up and accessible to the VCSA before taking a backup. Right below is the new built-in backup scheduling option. Here we can configure the backup schedule including location, frequency, and time. The backup location format has changed from vSphere 6.5. Now the backup protocol is part of the backup location, using the following format: Protocol://Server Address: Port/Backup Folder/Subfolder. The backup folder and subfolder do not need to be created before running the backup schedule wizard. A default backup folder called vCenter will be created during the backup if one is not supplied. Subfolders with the corresponding VCSA FQDN will also be created.
Also included in the backup schedule configuration is a new retention option. The retention option allows the selection of the number of backups to keep. Two options are available, keep all backups or specify the number of backups to keep. When the backup location reaches the retention number, the oldest backup gets removed. After completing the backup schedule configuration, its information is available by expanding the backup schedule status. The backup schedule also includes options to edit, delete, or disable as needed. Right below the backup schedule section is another new section named activities. The activities section logs detailed information about each backup job.
File-Based Restore 6.7
The restore workflow in vSphere 6.7 has also improved. Now included is a backup archive browser. After entering the backup location details, the backup archive browser will launch. This is a great improvement over having to remember the entire backup location path. There is also a search option, handy if the same backup server is being used for several VCSAs within your environment. The backup archive browser displays the following information for each backup directory:
If the backup was done manually (M) or scheduled (S).
Version information found in the VAMI summary tab 6.7.0.10000 (6.7 GA), 6.7.0.11000 (6.7.0a).
Timestamp of when the backup was taken
Description, if one was provided during backup. It’s base64 and not human readable.
During the restore of VCSA, the vSphere SSO credentials are required for reconciliation. In the past, a restore script was required after restoring a vCenter Server registered to a PSC for reconciliation. This is no longer the case or required for either embedded and external deployments. Restoring an external PSC while other replication partners are available is no longer allowed. Since the PSCs are multi-master the same data is being replicated in the vSphere SSO domain. Now simply decommission the external failed PSC from the vSphere SSO domain using the cmsso-util unregister command. Then deploy a new external PSC which will get its data from the existing replication partners. This ensures that all external PSC have the most current data within the vSphere SSO domain.
Walkthroughs
vCenter Server Appliance 6.7 File-Based Backup Walkthrough is available here.
vCenter Server Appliance 6.7 File-Based Restore Walkthrough is available here.
vCenter Server Appliance 6.7 File-Base Backup & Restore Overview Video
More information about the vCenter Server Appliance 6.7 File-Based Backup and Restore can be found in the vSphere 6.7 documentation.
Check out the new vCenter Server Appliance 6.7 file-based backup and restore walkthroughs and provide feedback in the comments below. You can also reach out to me on Twitter via @emad_younis.
