Reproduce TimeFinder/Clone functionality on VMAX3

I don't think the copy feature of SYMSNAPVX is there to support the legacy CLONE COPY feature. I would be interested to know if there is a technology reason to use COPY (outside cascade operations) with snapvx in your environment.

As I understand it, when using cascade SYMSNAPVX, you have a dependency on terminating the the cascading snaps in reverse order typically (can't terminate the original source>tgt if there are cascades). If the original source>tgt snapvx is set to copy (and all tracks copied), this relationship may be terminated, even if the TGT is a source for a cascaded snapvx.

Edit: relink -copy should provide the function you are after. I see that there are 2 instances of snapshot name "snap" in your output. Let me look at this in more detail....

The relink command is the recreate from my experience since it will incrementally re-sync from the source to the linked target. You would likely create a new snapshot form the prod volume for the updated PiT image and then issue a relink from that snapshot to your existing linked target and it will be an incremental refresh, so your #4/#5 above is the way that I am aware of.There is no recreate that I am aware of with snapvx.....I think your procedure above is correct and the intended process.

Jasonc,

reason i am doing -copy is because target devices  needs to be an R1, according to timefinder docs it requires -copy.

As you can see in step 5 i am using relink -copy but how do i "refresh" my snapshot so that it's an incremental copy. I don't see a recreate command for the snapshotvx, i only see establish. When i run establish with the same name as my previous snapshot ..it creates a new one.

I have done both, but tend to do with the manual deletion or script it as cleanup upon creation of a new one just because of preference/control versus anything else really.

Thank you Keith. How do you deal with "old" snapshots, do you set TTL when you create them or manually/script delete them ?

hmm...you have the -copy which is what makes it incremental so I wouldn't expect a full push. Does the -summary listing show anything different?

something is not right. Everytime i run this command:

symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap relink -copy -lnsg sg_snaptarget

even if i did not create a new snapshot, output from "symsnapvx -sid 123   -sg sg_oracle list   -linked -detail -gb" shows that it's performing a full copy. Same snapshot, nothing changing, i am simply re-running the same relink command. Any thoughts ?

same thing, shows how much is remaining to copy

symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap list -summary -gb


Storage Group (SG) Name : sg_oracle


  Snapshot  State               Count
  -----------------------      ------
  Restored                          0
  RestoreInProg                     0
  Established                       2
  EstablishInProg                   0
  Linked                            0
  CopyInProg                        1
  Copied                            0
  NoSnapshot                        0
  Failed                            0
  -----------------------      ------
  Total                             3


                              GB(s)
                              -------
Total Remaining                 157.3 

I tested this on a VMAX 3 running SE v8.0.3 and 5877.790 (EMC lab box) using the following:

symsnapvx -sid 89 -name jason establish -dev cd8

symsnapvx -sid 89 -snapshot_name jason link -lndev cd9  -dev cd8 -copy

symsnapvx -sid 89 list -dev cd8:cd9 -summary -gb  << This shows non-zero value in GB to copy field

symsnapvx -sid 89 -snapshot_name jason relink -lndev cd9  -dev cd8 -copy

symsnapvx -sid 89 list -dev cd8:cd9 -summary -gb  << This shows zero value in GB to copy field

Repeat last two commands numerous times and consistently get zero value in GB to copy. My test appears to be working as designed. What code levels are you running?

You will see in my example there is just a single establish. The relink will obtain a new PIT and produce a copy delta. So I think in your case, the second establish isn't required and this is causing another full copy. From the TF CLI prouct guide:

RELINK:

Remove the link to target device and present a different snapshot from the same source device, or relink to

the same snapshot. Refreshes the point-in-time copy on the link target when it's been modified by host

writes.

I think when it says "...when it's been modified by host writes" actually means when the source or target has been updated. In other words the relink will make the target device the same as the source. The wording is a little unclear.

From previous testing (don't have a box right now), I was seeing incrementals I believe with new establishes on the source volume to create the new PiTs (like ProtectPoint) like dynamox is doing so I think I would expect it to work incrementally as long as the relink is used and the source stays the same. that snippet above seems to state both will be incremental:

RELINK:

Remove the link to target device and present a different snapshot from the same source device, or relink to

the same snapshot. Refreshes the point-in-time copy on the link target when it's been modified by host

writes.

It's odd that you are seeing a full copy, If you re-run a test and use the -detail at the end on the list, does it show you a number of shared and non-shared tracks between your generations since I am assuming you will have 2 generations if you are using the same source and snapshot name. Just curious if that gives any insight.....

Let me redo my test using the same query format you use and see what i get.... Next week most likely.

I have rerun the same test i did before using a device file and also using storage groups as in your jobs Dymox. The initial link performs a copy operation. Subsequent relink operations produce no data to copy since I havent updated the source.

I had non RDF and RDF1 type devices in the lnsg.

I note that the RDF1 devices that are the linked target need to be suspended before the relink -copy can work. As an added check, doing an  RDF query after the relink showed no RDF invalids.In other words, i cant recreate your scenario unfortunately. Everything I do seems to be in alignment with what is documented.  You many need an SR...