5.5

Running a Recovery with Forced Recovery
If the protected site is offline and SRM cannot perform its usual tasks, you can run the recovery with the
forced recovery option. Forced recovery starts the virtual machines on the recovery site without performing
any operations on the protected site.
Forced recovery is for use in cases where storage arrays fail at the protected site and, as a result, protected
virtual machines are unmanageable and cannot be shut down, powered off, or unregistered. In such a case,
the system state cannot be changed for extended periods. To resolve this situation, you can force recovery.
Forcing recovery does not complete the process of shutting down the virtual machines at the protected site.
As a result, a split-brain scenario occurs, but the recovery might complete more quickly.
CAUTION Only use forced recovery in cases where the recovery time objective (RTO) is severely affected by
a lack of connectivity to the protection site.
Running forced recovery with array-based replication can affect the mirroring between the protected and
the recovery storage arrays. After you run forced recovery, you must check that mirroring is set up correctly
between the protected array and the recovery array before you can perform further replication operations. If
mirroring is not set up correctly, you must repair the mirroring by using the storage array software.
When you enable forced recovery, any outstanding changes on the protection site are not replicated to the
recovery site before the sequence begins. Replication of the changes occurs according to the recovery point
objective (RPO) period of the storage array. If a new virtual machine or template is added on the protection
site and recovery is initiated before the storage RPO period has elapsed, the new virtual machine or
template does not appear on the replicated datastore and is lost. To avoid losing the new virtual machine or
template, wait until the end of the RPO period before running the recovery plan with forced recovery.
After the forced recovery completes and you have verified the mirroring of the storage arrays, you can
resolve the issue that necessitated the forced recovery. After you resolve the underlying issue, run planned
migration on the recovery plan again, resolve any problems that occur, and rerun the plan until it finishes
successfully. Running the recovery plan again does not affect the recovered virtual machines at the recovery
site.
Differences Between Testing and Running a Recovery Plan
Testing a recovery plan has no lasting effects on either the protected site or the recovery site, but running a
recovery plan has significant effects on both sites.
You need different privileges when testing and running a recovery plan.
Table 4‑1. How Testing a Recovery Plan Differs from Running a Recovery Plan
Area of Difference Test a Recovery Plan Run a Recovery Plan
Required privileges Requires Site Recovery
Manager.Recovery Plans.Test
permission.
Requires Site Recovery
Manager.Recovery Plans.Recovery.
Effect on virtual machines at
protected site
None SRM shuts down virtual machines in
reverse priority order.
Effect on virtual machines at
recovery site
SRM suspends local virtual machines
if the recovery plan requires this.
SRM restarts suspended virtual
machines after cleaning up the test.
SRM suspends local virtual machines if
the recovery plan requires this.
Site Recovery Manager Administration
38 VMware, Inc.