4.0

A typical failback has two phases. In the first phase, the protected and recovery sites switch roles, and the
virtual machines are migrated from the recovery site to the protected site under the control of a recovery plan.
In the second phase, the relationship of the protected and recovery sites is restored, so that future failovers
migrate the protected virtual machines from the protected site to the recovery site. Alternately, the recovery
site can be promoted to a protected site, and the protected site becomes the recovery site.
Configuring and executing a failback is a time-consuming task that requires downtime at the recovery site and
changes to storage replication. After the failback is complete, restoring the protected site to its original role and
enabling failover to the recovery site requires additional downtime and changes to storage replication.
SRM and vCenter
The SRM server operates as an extension to the vCenter server at a site. Because the SRM server depends on
vCenter for a number of services, you must install and configure vCenter at a site before you install SRM.
SRM takes advantage of vCenter services, such as storage management, authentication, authorization, and
guest customization. SRM also uses the standard set of vSphere administrative tools to manage these services.
How Changes to vCenter Inventory Affect SRM
Because SRM protection groups apply to a subset of vCenter inventory, changes to the protected inventory
made by vCenter administrators and users can affect the integrity of SRM protection and recovery.
SRM depends on the availability of certain objects, such as virtual machines, folders, resource pools, and
networks, in the vCenter inventory at the protected and recovery sites. Deletion of resources such as folders
or networks that are referenced by recovery plans can invalidate the plan. Renaming or relocating objects in the
vCenter inventory does not affect SRM, unless it causes resources to become inaccessible during test or
recovery.
SRM can tolerate the following changes at the protected site without disruption:
n
Modifying a protected virtual machine configuration, including adding, modifying, or removing devices.
Changing a virtual machine’s memory size on the protected site is not reflected on the recovery site if the
virtual machine is already in a protection group.
n
Relocating virtual machines.
n
Deleting protected virtual machines.
n
Deleting an object for which an inventory mapping exists.
SRM can tolerate the following changes at the recovery site without disruption:
n
Deleting placeholder virtual machines.
n
Moving placeholder virtual machines to a different folder, resource pool, or network.
n
Deleting an object for which an inventory mapping exists.
SRM and the vCenter Database
If you update the vCenter installation that SRM extends, you must not overwrite the vCenter database during
the update. Overwriting removes information that SRM has stored in that database and invalidates the current
SRM installation.
Chapter 1 Administering VMware vCenter Site Recovery Manager
VMware, Inc. 13