Recently I had a partner/customer who was migrating a lot of SAP data from one VMAX to another VMAX and they ran into an issue they weren’t sure how to solve, well at least what the best way to solve it was. This person had a ton of data on the VMAX and more than a few TimeFinder/VP Snap point-in-time copies of each SAP volume that they used for testing/recovery or backup.
For those of you unfamiliar with VP Snap it is a rather new (introduced with 5876) method of local replication on the VMAX that leverages the space-efficiency benefits of TimeFinder/Snap but also offers the flexibility of configuration provided by TimeFinder/Clone.
Anyways, this person wanted to migrate all of the VP Snap copies from one VMAX to the other so those point-in-time copies could continue to be used as needed. There are a couple different ways to do this but most of them either required software they didn’t have or the target copy would become “thick” once moved to the new array. In other words a source VP Snap copy that only stored differences between the production data and its point-in-time that was only in the 100s of MB or a few GB would be come possibly TBs on the target array. Due to the vast number of VP Snap copies they didn’t have adequate storage to store these full copies. They needed them to remain space efficient on the target.
After thinking about this and discussing it with a colleague in engineering we came up with the following solution that met their needs. It seems somewhat obvious after looking at it, but I thought I’d share it in case it might save someone a bit of time:
- A production device with the activated VP Snaps
- Create/establish an RDF session from that device to a device on the new VMAX
- Create, but don’t activate, the VP snap sessions off of the R2 device–the same number that the R1 has plus one.
- Wait for RDF session to become “Synchronized” and then activate VP Snap session 1 on R2 for gold copy. This will provide a latest version of the production volume to be restored to after the migration process. Let’s call this the Gold Copy VP Snap.
- Restore from VP Snap 1 to the R1 (requires –force). This will make the R1 the point-in-time that the first VP Snap copy stores. This will in turn make the R2 device that same point-in-time.
- Wait for RDF session to become “Synchronized” and then activate VP Snap 2 on R2. This will then make the VP Snap 2 on the new array the same point-in-time as the VP Snap just was just restored from. Most importantly it is still space-efficient.
- Terminate restore session the VP Snap 1 on the R1 (symclone terminate –restored)
- OPTIONAL: Terminate the entire VP Snap session on the R1 by then running symclone terminate. If you no longer want the VP Snap copy on the R1 you can terminate it completely, but I would recommend waiting to do this until the entire process is complete and the R2 data and copies are verified.
- Keep repeating steps 5-7 for each VP Snap copy on the R1 side until each point-in-time is on the R2 side.
- Perform RDF failover and then restore the R2 device from the Gold Copy VP Snap.
- Deletepair for RDF devices, delete R1 devices etc.
This process worked rather well for them, but there are a couple of things to note:
- If you are using SRDF/A you will need to enable and arm device write pacing on the R1 device.
- THIS IS AN OFFLINE PROCESS. Since the R1 will be changed and restored multiple times, it cannot have a host accessing it for the duration. Conceivably this could be changed to be online in some way, but it will be more difficult to do–it would require some second copy of the data at the R1 site. So depending on your migration needs this might need to be altered.
- The amount of data stored by the new VP Snap copies on the new array might be more than the old array. Due to the multiple restores some copies might need to store more data than its respective copy on the R1 site. You might want to look at the change rates on each copy and decide upon the order they should be restored and migrated to give you the best results.
- This process should work with standard Snap too, but I haven’t personally tested it. Might be a good way to migrate from Snap to VP Snap (if desired) if moving to a new array as well.