One of the primary benefits of Site Recovery Manager is the ability to test recovery plans-coordinating the failover of the replication and recovery of virtual machines without affecting the configuration, state, protection, or connectivity of the original source VMs.
Best Practice: Test recovery and test it often. Do it on a schedule as well as right after any changes are made in the replicated environment.
The workflow is after a recovery plan has been failed over that included datastores in a pod to the asynchronous third site and then reprotected. This is a test of a recovery back to the original site to a pod.
The high-level process of a test recovery is:
-
Power-on the VMs and configure them according to the recovery plan
To initiate a test, click the Test button in SRM.
A wizard will appear, with a default option called Replicate recent changes to recovery site selected.
If this is selected, the SRA will create a new replication point-in-time. If it is de-selected, the SRA will just use the latest point-in-time found for each volume. Note though that during failover, the SRA will always still use the latest available point-in-time. So if the SRA creates a new one for the test, and between the completion of that point-in-time and before creating the recovery volumes a new point-in-time is created, that new one will be used for recovery.
Click Next.
Confirm the test and click Finish.
Note:For a test recovery to succeed, the target pod must be unstretched first. If it is not the synchronization step will fail with the following error.
Unstretch and try again.
The synchronization step will create a new point-in-time snapshot (if "Replicate recent changes" was selected) with a name consisting of a UUID and "-puresra".
The test will create new volumes from the replicated snapshots with the suffix "-puresra-testFailover".
These new volumes will be placed in the pod. Note, as seen in the above screenshot, if the original volumes with the suffix of "-puresra-demoted" exist they will not be re-used for the test--new volumes will still be created. For an actual recovery though these volumes (if present) will be used instead of creating new ones.
To test the environment, re-stretch the pod once the test recovery completes but it is important to un-stretch it prior to the cleanup operation of the test to allow for it to be re-run and for an eventual possible actual recovery operation.
The detastores will be connected to the host/host group(s).
Once complete, SRM will resignature and mount them.
The resignature process will add a name prefix to them of snap-XXXXXXXX. SRM can be configured to automatically remove the suffix through advanced configuration documented SRM User Guide: Site Recovery Manager Advanced Options.