Backing up Virtual Center with Rapid Recovery (4039947)

For customers that want to use Rapid Recovery to backup their Virtual Center there are a few things to consider:

1. Is the Virtual Center (VC) Windows based? Or is this a VMware virtual appliance (VA)?
2. Is the VC running upon a VM? Or is it installed upon physical hardware?

If the VC is running upon physical hardware (and not on a VM) then you can install a Rapid Recovery (RR) agent upon it and then backup it up. If it is a VM however and you want to back it up agent-lessly, then that is where the nuances come into play. If it is a Windows based VC then you still have the option of using an agent, if it is the VMware VA however, there is not an agent available and that can only be backed up via agent-less protection. Another discussion that comes up is do you want and/or need to backup the VC altogether.

The question of backing up a VC comes up due to the fact that in the vast majority of cases the ESXi hosts are what carry the intelligence/settings, and the VC is just a single pane of glass for the VMware resources. Unless you are running VVOLs, vSAN or distributed switches, it is the hosts that have all your VM/datatsore/network configurations. The exceptions to this are your clusters, SSO, update manager, which are VC specific; however many times when a virtual center goes down, that is when the industry as a whole just chooses to deploy a new updated VC with a fresh/clean DB. Which if you aren't going to restore it, there is little reason to back it up. Also keep in mind that the amount of time it takes to restore the VC might be just as long as it takes to spin up a fresh/updated VC, especially if it was a VM to begin with.

There isn't a recommendation from support as to which path you choose, we just need to illustrate how to best go about protecting your VC should you choose to do so.

Agent Based Backups

With agent based backups you are using the MS VSS writers to snapshot the Windows blocks of the OS and RR is reading those blocks which this process has no impact upon other production machines or VMs. Therefore if you are using a Windows based VC and choose to back it up with an agent, there should be zero impact using such a method.

Agent-less Based Backups

With agent-less backups of your VC the VC will snapshot itself to remove the lock on its own .vmdk to allow the RR core to read the .vmdk that it is running on. The problem here is that this will affect other environmental actions as you run the risk of this happening while the VC is either creating and/or closing the snapshots for other VMs while this is taking place. If that is the case, the end result can be broken snapshot chains (disk consolidation error message) or .vmdk locks not being removed properly (which is remedied by an ESXi host restart). Both of which affect production and/or could incur data loss.

Recommendations

If you have a Windows based VC and you want to back it up, we recommend that you use the agent based backups. Should you choose to do agent-less backups, schedule the VC backup to once a day and do it at a completely different point in time than the rest so that you don't run this risk. For an example create a 2 hour Window from 9pm to 11pm where nothing else backups, and then run the VC backup at 9:30pm (leaving that extra 1/2 hour for other jobs to finish).

For a VMware based VA, since an agent can not be installed upon it, your only option is agent-less protection. Which, same as the Windows based VC, your option will be scheduling. Create a 2 hour Window from 9pm to 11pm where nothing else backups, and then run the VC backup at 9:30pm (leaving that extra 1/2 hour for other jobs to finish).