Timefinder/Mirror clone emulation vs Timefinder/Clone

We are a mainframe shop, and some time ago, when we converted from DMX2 to DMX3 hardware EMC informed us that we would need to convert to Timefinder/Clone since our target devices would be RAID5.

We have recently learned that when performing a Clone1 to R2 that a full push of all tracks will always be invoked … which is not acceptable .. we need to be able to fallback with incremental restores (Clone1 to R2, R2 to R1, R1 to Standard should all be incremental if source site is still intact as in a power outage). EMC is now telling us that we will need to convert to Timefinder/Mirror clone emulation in order to have this capability … and that a full push of all data will be necessary to perform this conversion.

1. Does this sound correct?

2. With Timefinder/Mirror clone emulation can we be IPLed from a Clone1 image and concurrently invoke a restore from Clone1 to R2? (The manual seems to indicate that the volumes will be ‘not ready’ in this situation). If so, will the resulting R2 image be ‘consistent’?

3. Currently with Timefinder/Clone we do not invoke R2 to Clone1 remotely from the source site LPAR but instead invoke this process from an LPAR at the DR site (where the R2 and Clone1 images reside) since execution time is three times longer if invoked ‘over the wire’ from the production DMX3 site (EMC claims it has something to do with passing all of the commands back and forth). Should we expect to experience the same elongated elapsed times for Timefinder/Mirror clone emulation R2 to Clone1 if we try and invoke it from the production DMX3 site?

4. Any other considerations we should be aware of if we convert from Timefinder/Clone to Timefinder/Mirror clone emulation?

Thanks!

4 comments

Skip to comment form

  1. Larry – I am going to couch this with a disclaimer that I’m not a mainframe person so i can only answer this question from an Open Systems standpoint. (From my experience, conventional timefinder operates the same way with both Mainframe and Open Systems)

    In response to your first question, yes, this sounds correct, but unfortunately I can’t explain exactly why. When cloning from a Standard device to a Clone/R1 device the track table (that keeps tabs on changed tracks) is tracked differently than with a BCV. This forces the R1–>R2 sync to be a full rather than a standard incremental.

    What you’re basically looking for is SRDF/AR functionality. It used to be that using SRDF/AR you would create a BCV/R1 of your primary devices, when when the BCV/R1 is split, the R1–>R2 sync would occur. When that sync was finished, if provisioned, a second set of BCV’s (Called BRBCVs) would be invoked to give you your “golden” copy.

    I’m fairly certain that implementing TimeFinder Emulation Mode will solve your problem, but officially supported details are going to have to come from the good folks at the Software Assistance Center.

    • on July 16, 2008 at 1:49 pm
    • Reply

    Huh? I thought TF was local replication only, within an array, and you need to use SRDF or SanCopy to replicate to another site. How is he using TF to copy to a DR site? Anyway, I think SanCopy or SRDF, set up properly, would solve his problem.

  2. Timefinder is local replication only, but when used in conjunction with SRDF you can do an automatic, staged replication. If you have a powerlink account you can look up: SRDF/AR.

    Staging replication allows you to keep multiple copies of your data, isolated and protected from each other as well as from your production copy.

    • on July 22, 2008 at 7:00 pm
    • Reply

    OIC, ok thanks.

Leave a Reply

Your email address will not be published.