In the previous post a VM has been protected by VMware Replication software. The VM can be recovered using vSphere Web Client (Monitor -> vSphere Replication -> Incoming):
Select Action -> Recover:
There are two options:
- Recover with recent changes: a new sync will be done before starting the recovery process. Source VM must be accessible and powered off. This option is good to start a copy of the VM with consistent data (relocating VMs between sites).
- Recover with latest available data: if previous option cannot be used, this option will recover the VM using the latest sync point. This option is good when source VM is lost, or cannot be powered off.
The second option will be used. Next step asks for a destination:
Because source VM is stored in the root of the data center, a folder is needed or an error will occur (The selected folder already contains an entity with the same name.).
Select the destination host:
And complete the restore process.
A new VM will be registered to the vCenter:
As we can see, VMware Replication snapshots are available.
Until the VM is in “Recovered” state, replication is stopped:
Resume replication after a recover (reprotect)
Replication can be resumed after a recover stopping the replication itself:
Remove the destination VM from the inventory and recreate the replication as seen in the previous post. In the “Target location” menu, select “Advanced disk configuration” and select the destination folder previously created:
The replication will use the previous file as a source seeds and won’t do an initial full sync. Mind that:
- existing directory will be used as seed source only;
- replicated VM will be stored into a different directory (after first sync, old directory can be deleted);
- Initial full sync still happens, but data will be copied from existing directory to the new one (network traffic will be minimum);
- network traffic will be minimized.
The following graphs show an Initial (network) full sync (from 14:55 to 15:00) and an Initial (disk) full sync (from 15:20 to 15:25):
Failback (or Reverse Replication)
Now let’s suppose:
- the first site becomes unavailable, data are sage but VM cannot be powered on;
- the replicated VM becomes active;
- after a few days primary site VM can be started again and we want to fail back (sync the primary site from the secondary site, and start the primary site).
From the official documentation:
After performing a successful recovery from the source site to the target site, you can perform failback. You manually configure a new replication in the reverse direction, that is, from the target site to the source site. The disks on the source site are used as replication seeds, so that vSphere Replication only synchronizes the changes made to the .vmdk files. Before you configure the reverse replication, you must manually unregister the virtual machine from the inventory on the source site.
So failback is similar to reprotect: just delete and configure a reversed replica using existing VMDK as seed source.
VMware Replication requires a vCenter to replicate and restore; in other words VMware Replication cannot be used to protect the vCenter. Sometimes can be useful know how to recover a VM without the vCenter. It’s not a supported way but it works.
After the Initial full sync, the destination datastore contains lot of files (SSH to the destination host):
~ # find /vmfs/volumes/esxi2_datastore/dc1/ /vmfs/volumes/esxi2_datastore/dc1 /vmfs/volumes/esxi2_datastore/dc1/dc1-flat.vmdk /vmfs/volumes/esxi2_datastore/dc1/dc1.vmdk /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.vmx.46 /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.vmxf.47 /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.nvram.48 /vmfs/volumes/esxi2_datastore/dc1/hbrdisk.RDID-eb01c086-8e46-45b5-91be-7292497c3409.29.143787460225397-delta.vmdk /vmfs/volumes/esxi2_datastore/dc1/hbrdisk.RDID-eb01c086-8e46-45b5-91be-7292497c3409.29.143787460225397.vmdk /vmfs/volumes/esxi2_datastore/dc1/hbrgrp.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.txt /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.17.vmx.49 /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.17.vmxf.50 /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.17.nvram.51 /vmfs/volumes/esxi2_datastore/dc1/hbrdisk.RDID-eb01c086-8e46-45b5-91be-7292497c3409.30.190983086717119-delta.vmdk /vmfs/volumes/esxi2_datastore/dc1/hbrdisk.RDID-eb01c086-8e46-45b5-91be-7292497c3409.30.190983086717119.vmdk
Let’s pause the replication and copy the latest snapshot to a single consolidated disk:
~ # mkdir /vmfs/volumes/esxi2_datastore/dc1_recover ~ # vmkfstools -i /vmfs/volumes/esxi2_datastore/dc1/hbrdisk.RDID-eb01c086-8e46-45b5-91be-7292497c3409.30.190983086717119.vmdk -d thin /vmfs/volumes/esxi2_datastore/dc1_reco ver/dc1.vmdk
Then copy and rename vmx, vmxf and nvram files:
~ # cp -a /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.vmx.46 /vmfs/volumes/esxi2_datastore/dc1_recover/dc1.vmx ~ # cp -a /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.vmxf.47 /vmfs/volumes/esxi2_datastore/dc1_recover/dc1.vmxf ~ # cp -a /vmfs/volumes/esxi2_datastore/dc1/hbrcfg.GID-66f80b00-1723-4c92-93b4-8f3660553ac2.16.nvram.48 /vmfs/volumes/esxi2_datastore/dc1_recover/dc1.nvram
Finally register the recovered VM:
~ # vim-cmd solo/registervm /vmfs/volumes/esxi2_datastore/dc1_recover/dc1.vmx
And that’s it.