As many are probably aware, RecoverPoint 4.0 recently released support for Point-In-Time test recovery and recovery for VMware vCenter Site Recovery Manager. In conjunction with the RP SRA and the Virtual Storage Integrator (VSI) users can select a PiT in the past instead of automatically being forced to use the latest copy.
Since this came out (and many times prior) I have been asked can we do this with the SRDF SRA and TimeFinder along with VMware SRM? The answer is yes! The process though is somewhat different of course. By far this question is mostly targeted for test recovery only, as most conversely prefer up-to-date images when they actually failover. So this post will focus on test recovery.
So first, what do you need to make this work?
- Enginuity 5874+
- License for TimeFinder Snap or Clone (Clone includes VP Snap)
- SRDF SRA version 5.1
- VMware SRM version 5.0.x or 5.1.x
- Solutions Enabler 7.5
- Virtual Storage Integrator Symmetrix SRA Utilities 5.4
Normally, during a test recovery, the SRDF SRA will query the test recovery pairings file (configured previously with TimeFinder pairs) and then add the TimeFinder targets to the device/composite group, create the TimeFinder sessions for each R2 device one by one and then consistently activate all the sessions simultaneously. These TimeFinder targets are then mounted to the recovery environment for the test. In this situation the TimeFinder target data is a copy of the very latest data available at the remote Symmetrix.
In many situations this is perfectly fine, but in others it is less than ideal. Occasionally (for example in certain database environments) the latest data is not desired, but instead a PiT copy of the data from some time in the past is preferred when the databases and/or the applications using them were quiesced during a given maintenance period. In most occasions, a maintenance period does not coincide with when the SRM administrator wants to run a test recovery. For instance there might be a scheduled maintenance period on Friday night, but the test recovery cannot be run until Monday when all of the application stakeholders are actually available and in the office to test their applications.
So how can the SRA achieve this when the SRA behaves in the way described above? Well the answer is to have the SRA check if the TimeFinder sessions are activated before doing any TimeFinder control operations on them.
In the SRDF SRA 5.1 we introduced support for an advanced option called “Ignore Activated Snapshots”. This option is disabled by default. When enabled, the decision workflow for test recovery is slightly different. Instead of just blindly attempting to create a TimeFinder session with the device pairs configured in the pairings file the SRA will check if there is a existing TimeFinder session with each specified pair. If there is, the following lines will be logged for each pair already in an active session:
Performing SymDevShow() on Symm Dev [04D7], Symm  Attempting to create clone session for device pair (04D7, 04c7) within DG [SRDF51] on Symm IgnoreActivatedSnapshots is enabled. So skipping recreate of clone sessions
If the SRA encounters a device pair that does not have a session it will create the session itself and log something similar to the following:
Performing SymDevShow() on Symm Dev [04D7], Symm  Attempting to create clone session for device pair (04D7, 04c7) within DG [SRDF51] on Symm  No clone session exists for the device pair (04D7, 04c7) within DG [SRDF51] on Symm . Creating VSE clone session Performing CLONE [CREATE -VSE] on the device list
Once it has iterated through all of the device pairs required by the recovery plan, the SRA will consistently activate the remaining not-yet-activated TimeFinder sessions. Any sessions previously activated will be unaffected and any sessions that were just created by the SRA will activated and made R/W.
During the cleanup operation, the SRA will recreate the sessions allowing them to be activated at any time afterwards. If you prefer you can enable the advanced option “Terminate Copy Sessions” and the SRA will instead terminate the TimeFinder sessions during test recovery cleanup.
So in this example I will be using TimeFinder/VP Snap which is an especially space efficient mode of TimeFinder/Clone that was introduced in 5876.
In this scenario I will be testing virtual machines that reside on two Symmetrix devices replicating to R2 devices with IDs 4DF and 4D7. These are the R2 devices that will be sources for the TimeFinder/VP Snap operations.
Previously I have created/activated multiple different PiT TimeFinder/VP Snap copies of each these R2s. I want to use the copies that I activated on June 20th at 12:13. The simplest way to find the right one is to run the following command on each R2 device:
symdev show 4D7 -sid 1248
The “4D7” in the command being one of the R2 devices and the “1248” being the end digits (enough to be unique) of the Symmetrix serial number hosting the R2.
This can be printed to a text file or piped to more. In this example I piped it to more and paged down until I saw the “Clone Device Information” sections. For each TimeFinder session there will be one of these sections, and in them it will list the last operation and the time of the command. Looking through the sessions I see on the second one the CopyOnWrite session (which in VP Snap land means it is activated and R/W) from June 20th at 12:13. This can be seen in the below image:
I see that the target device is 4BF. I perform the same steps for the other R2 (device 4DF) and I find that the correct PiT target for it is device 4B7. Now that I know the correct pairs I can configure the pairings file that the SRDF SRA references. Using VSI from within the vSphere Client I can launch the Failover Test configuration screen (from the cluster level or host level in the inventory screen) to configure the file.
You can check the “Only show replicas with sessions” option to filter out any candidate target devices that are not currently in a TimeFinder/VP Snap session with the listed R2s. In the replica device column select the correct target devices you identified in the symdev show printouts. Once selected, the Replica State column will report the TimeFinder state and in this case will be CopyOnWrite. Save the file and start the SRM test.
The SRDF SRA will now use those PiT copies and allow you to test a copy of the data from a previous date!
9 Replies to “Point-in-time test recovery with SRDF and VMware SRM”
Reblogged this on Sutoprise Avenue, A SutoCom Source.
I have all the above required details in my company and client have a sam requirement as you mentioned in the article. Can you please give the steps perform this test to recover vm from srm.
For SRDF? I no longer work for EMC so I can’t give up to date instructions, I would reach out to EMC directly for help with this if that is the case
Yes. In the environment have EMC VMAX20K, SRDF, EMC SRDF SRA adapter 6.0, EMC SE 22.214.171.124, TimeFinder clone license,and VMware SRM 5.8.1.
I would recommend reaching out to EMC support then
Issue- Unable to create Protection group in SRM 5.8.1.
Earlier I was created protection group and recovery plan in SRM. Due to some issue Not Configured and In datastore group list showing not replicated. Hence I was deleted the protection group and recovery plan and try to re-create protection group but unfortunalty not allow me create due to now in datastore group list not showing the datastore.
Nawal–I do not work for EMC any more so I can’t really help you if you are referring to SRDF–it has been too long and my information i probably outdated and inaccurate. I would recommend opening a support case with EMC. Sorry, I wish I could help more.