vSphere replication can be used to protect vCenter server by replicating it to another location, it is not the best disaster recovery solution but it works. We can create point-in-time copies (PIT), select RPO, enable compression, etc. But what if vCenter actually breaks down and we want to recover it. And even worse what if we have to recover it to a previous point in time copy (because the latest replicated state is corruped) ? The problem is that the vSphere replication UI is embedded in vCenter UI, so no vCenter UI means no vSphere replication UI.
Well, there is a way to do it and I'm going to explain how it can be done.
First we need to know the datastore where vCenter was replicated:
And to what point-in-time copy (snapshot in reality) we want to recover. In this example we want to go back to the Oct 30, 2019 11:04 PIT.
As the vCenter is no longer available we have to login to the ESXi host as root (via ssh) and change to a directory where the replicated data is stored. The idea is to recreate the vCenter and point it to the files that were created during desired PIT. First we need to get the instance id, .vmx and .nvram files names (from PIT) and use them to create the standard .vmx and .nvram files. All the information is stored in the .txt file in the same directory.
Note: The timestamps are in UTC so in this case one -1 hour.
After that we have to do the same for the vCenter disks (vmdk). Just like on the screenshot below, based on disk id (disk.0) we replace the vc-5-02_2.vmdk with the PIT replica disks (hbrdisk) in vc-5-01.vmx file. This step is not required if we want to recover to the latest state of the vCenter (becasue the .vmx file already points to correct vmkd disks).
We need to repeate that operation with all other disks. Once this is over the .vmx file should look like this:
At this stage the .vmx file is reconfigured and we can register out replicated vCenter as a new VM. This can either be done using vim-cmd command or via ESXi UI.
Last step is to edit the VM settings and connect it to the correct port-group. As the orignal vCenter is down we can only connect the recoverd vCenter VM to a standard vswitch (vSS) port-group or to ephemeral port-group on distributed vswitch (vDS). This is one of the reason why we should always create this kind of port-group on our management vDS.
With this step done the VM can be powered up and after a while the vCenter will be up and running again.
Note: It is important to answer "I moved it" if asked during power-on operation if you do not want to get new uuid.bios and uuid.location values, and a new MAC address.
Last thing to do is to clean-up and remove other snapshots from the vCenter VM (consolidate).
