Reading Time: 2 minutes

A usual way to backup the VMware vCenter Server Appliance (VCSA) is to manage as a common VM and use a backup solution to backup (and restore) the entire VM.

But it’s approach does not always work and cannot guarantee a restore in some cases, for example in the case of a database corruption.

Starting with vSphere 6.5 and the new VCSA 6.5 was possible to use also a native backup solution integrated with the vCenter Server Appliance Management Interface (VAMI). But it was a manual operation (some scripts are available to automate and schedule it).

Finally, with vSphere 6.7 it’s now possible to schedule the backup of the VCSA directly from the VAMI as descripted in a previous post (Backup VCSA 6.7 with VAMI).

But there is an issue if you want to use the retention option: it may not work and will keep all the previous backup.

Backup retention could be easily set from the VAMI in the backup schedule:

On some destination it works, but if you schedule backups on SMB or NFS shared storage by using the vCenter Server Appliance Management Interface, old backups might not be removed according to the set retention policy.

SMB and NFS destinations are quite new, and this is probably the reason of this bug.

Anyway this issue has been just fixed with vSphere 6.7 Update 3b release!

Note that the vCenter update will require a lot of time, because it includes also the database upgrade to a new version (VMware Postgres is updated to version 9.6.15) with all the data conversion.

Note that you cannot yet restore the vCenter from SMB, you have to enable FTP or HTTP during the restore procedure.