Specifications

30
9.2 RESYNCING: PRIMARY STORAGE RECOVERED
Recovering back to an existing primary site, where an outage occurred but the primary array data was not
lost is likely to be the most common scenario, so it is covered here first. If the disaster event that occurred
did not cause the complete loss of data from the primary site, such as an unplanned power outage or
planned failover, then SnapMirror allows replication of only the delta of new data back from the DR site. This
enables very quick resync capability with minimized effect on the WAN link.
1. Recover the virtual infrastructure at the primary site. It is important in this scenario to make sure that the
original ESX hosts do not begin to start outdated virtual machines on a network that might conflict with
the DR site. There are a number of methods to prevent this, a simple one being to boot the storage
appliances first and unmap LUNs from igroups to prevent virtual machines from being found and
starting. Also consider disabling DRS and HA clustering services and any other systems in the primary
environment that might require similar isolation.
2. Recover Active Directory and name resolution services at the primary site. This can be done by
recovering the AD servers at that site and forcing them to resynchronize with the newer AD servers at
the recovery site or by establishing new AD servers to synchronize.
Note: The AD servers at the original primary site that formerly serviced the FSMO roles that were
seized must not be brought back online. Because those servers were down at the time the FSMO roles
were seized, that server will be unaware that it is no longer responsible for providing those services.
This server must be retired or re-commissioned as a new AD member server then promoted to a
domain controller.
3. If the virtual machines at the primary site vCenter server still exist in inventory, they must be removed,
or SRM will not be able to create the placeholder virtual machines when the reverse protection group is
created.
4. After removing the old virtual machines from inventory, remove all LUNs or datastores from the ESX
hosts at the primary site.
a. For iSCSI or FC datastores remove all LUNs of datastores to be failed back from the
igroups on the NetApp arrays. After removing the LUNs from the igroups issue a storage
rescan on each ESX host or cluster at the primary site.
b. For NFS datastores disconnect each datastore. In vSphere you can right click on a
datastore and select Unmount. In the wizard that appears select every ESX host you wish
to unmount the datastore.
5. When the VMs have been removed from inventory at the primary site and there is no risk of them
coming online on the public network re-establish network connectivity between the sites to allow
SnapMirror relationships to be established.
6. Reverse the SnapMirror relationships. The above steps above should be performed prior to reversing
the SnapMirror relationships due to the fact that any datastores still connected to the ESX hosts will be
made read-only by the resync, this could cause issues if done while the datastores are still connected.
On the console of the primary site storage system, enter the snapmirror resync command to
specify the DR site volume as the source with the –S switch.