Recover a VM using vSphere Replication

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):

incoming_replica

Select Action -> Recover:

recover_step1

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:

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:

destination_host

And complete the restore process.

A new VM will be registered to the vCenter:

restored_vm

As we can see, VMware Replication snapshots are available.

Until the VM is in “Recovered” state, replication is stopped:

recovered

Resume replication after a recover (reprotect)

Replication can be resumed after a recover stopping the replication itself:

stop_replication

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:

use_seeds

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):

network_traffic

disk_traffic

Failback (or Reverse Replication)

Now let’s suppose:

  1. the first site becomes unavailable, data are sage but VM cannot be powered on;
  2. the replicated VM becomes active;
  3. 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.

Manual recover

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.

References

Posted on 19 Jun 2014 by Andrea.
  • Gmail icon
  • Twitter icon
  • Facebook icon
  • LinkedIN icon
  • Google+ icon