TimeFinder Clone Part II

A user posted this as a response to “The Many flavors of EMC TimeFinder“  I felt it rated it’s own post.


Q: “My experience is mostly using IBM Sharks. I’m now working in a very large EMC environment, foucsed on backup. I’m wondering if the TimeFinder/Clone’s cloned volume can be permanently mounted on another host. Specifically, I want to avoid importing a nd exporting DGs from Veritas every time I need to ’split’ the mirror, as I would have to do with TineFinder’/Mirror. “

A: TimeFinder/Clone can in fact be a permanent copy of the data.  As long as the either of the copy options are set, the -precopy option, which copies all data before the session is activated, or the -copy option, which performs a full background copy of the data while the target (clone) device is available to the backup/development host, is used.

The default, (no switches used) will not result in a full clone and as such is only available while the clone session is in the “Active” state.

Q: What I’m looking for a is a point in time copy which is mounted on a backup media server while the production data disk are mounted on the production server. The application on the production server would be paused, then the clone would happen, then the application could be restarted. The cloned data would “magically” appear on the clone volume set mounted on the backup media server.

A: If you’re doing this simply for backup, then copy-on-access is easier and more flexible.  COA allows you to create and activate a session, copy the data, and terminate it immediately.  Truthfully TimeFinder/SNAP is equally up to this task (as it’s largely the same thing) but in my opinion you get more flexibility by purchasing clone instead of snap, though you do spend more money on disks in the process.

Unfortunately, as I’m assuming you’re talking about a Windows environment, there isn’t much “Magical” about it. 

Q: The largest issue I’ve run into is the insistence by a few EMC folks that the clone volume must be mounted on the prod host, then unmounted and mounted on the backup host.

A: Again, assuming you’re talking about Windows, this is incorrect.  You can’t remount the snap or clone of a production volume back to the same host because windows is largely dependant on the Signature of the drive.  Doing so can actually confuse windows into thinking that there are two copies of the disk and cause data corruption.  (I can’t say anything, the same is true of AIX, which, if you’re using LVM and not raw disks, has the same signature (they call it PVID) dependency.)

I’ve worked in several environments where the target volumes are simply unmounted, synched, and remounted.  So long as the target ID and the signature don’t change, this is not usually an issue.

The benefit to using clone is that you can leave the session active, or use one of the ‘copy’ options to produce a full copy.  Then, restoring from the disk in the case of a failure becomes a real option.  You simply reverse the sync, remount the production volumes, and start the application or database from there.  (Ok, it’s not simple, but I’m not sure even I have the drive space to post the full procedure here.  🙂 )



Skip to comment form

    • on February 27, 2007 at 9:34 pm
    • Reply

    I’m not positive, but I think you may be misinterpreting the first part of the original question.. My interpretation — the person asking the question has a production server and a backup server. Production volumes are mounted to the prod server, and clones are mounted to the backup server. Person needs to refresh the clones periodically, and wants to know if they can just issue the command to refresh the clone (ie., symclone establish), and have the OS magically update itself with the refreshed clone data.

    If that is indeed the question being asked, then the answer is no — You need to unmount/deport the CLONE filesystems/volume groups from the backup host, then do the clone refresh, then import/remount the CLONE filesystems on the backup host. This is necessary with any array/block-based data copy tool, because the server has no way of tracking where data is being moved at the block level.. and the server needs to know this in order to accurately map files to blocks.

    By unmounting the filesystem, you are asking the server to flush the filesystem metadata from memory. Then by remounting the filesystem after the clone refresh, you are asking the server to reread the filesystem metadata from disk — which is actually the metadata that was copied from your production volume, so everything is back in sync. With Windows, you’ll need to use the symntctl command to perform the unmount; otherwise Windows will continue to cache the old metadata even after you’ve unmounted, and your filesystem will appear corrupt after remounting.

    But about that last part of the question — I don’t see any reason that you would need to temporarily mount the clones back to the production server. I would recommend asking for some clarification on this point, since the people telling you have more background information than I do.

    • Jesse on February 28, 2007 at 8:51 am
    • Reply

    You are right, you do have to dismount the volumes or data corruption *WILL* occur. However, the statement that the device group has to be exported and imported is not in MOST circumstances.

    Exporting and importing the device group is only required with the DG metadata has changed. IE, a new disk added to the volume group, disks removed, LV’s changed, and such. If the only thing that’s changed is filesystem information, that is re-read on the mount of the filesystem and as such doesn’t require the full DG export/import.

    That being said, Veritas is about the only way to make Snap/Clone on Windows doable, it provides some of the tools that Windows *STILL* can’t manage to handle a filesystem unmount gracefully, and EMC’s tools (symntctl) are merely a bandaid, they don’t seem to cover all the holes in the OS’s functionality (or lack thereof).

    • on February 28, 2007 at 5:14 pm
    • Reply

    Thanks for the reply. For some clarification, scummins is correct. I have a backup server with the clones mounted and a production server with the prod volumes mounted. I want to use SnapWhatever to move the data between these two volumes without unmounting/remounting filesystems or importing/deporting volumes from VXVM.

    Currently, we use a theee way mirror. The backup looks like this: stop the app on the prod host, break one stripe off the 3-way mirror, deport it, restart the app. On the backup host: import the stripe and start the backup. We’re having issues with automation. The deport or import sometimes fails for odd reasons and needs to be manually fixed (read:3am pager call).

    The environment in question is Solaris (mostly), Windows (some) and Linux (some).

    Also, I’d like to note that the IBM ESS800 (aka Shark) when used wiith FlashCopy permits a replica volume (clone, copy, whatever) to be mounted permanently on the backup host. No unmounting/remounting is needed when the “flash” is executed. The data from the primary volume is sync’ed to the replica in a manner very similar to SnapClone (ie pointers set up then data is copied later) and SnapCopy (full volume initial write, ‘flashes’ are differential writes).

    This is the behaviour I’d like to get my EMC hardware to duplicate. And yeah, we like the DR aspect of having a full copy of the data on the clone volume. Since we already have 3-way mirrors, the cost to make our clone volume redundant (a la RAID-5) is minimal.

    Oh, and I believe you if you tell me that it’s not possible in a Windows environment. 🙂

    My EMC guys are certainly advocating changing the PVID before mounting the clone volume on the prod host… So, they’re not that bad. They’re prolly just miffed I keep saying “IBM can do this. Can’t you guys??”…

    • Jesse on February 28, 2007 at 9:54 pm
    • Reply

    Ok, got to admit I’m not a big van of Veritas in TimeFinder environments, it throws MANY more moving parts into a mix that is necessarily already complicated enough.

    So you’re using Veritas to mirror to the array? (You suggest a 3-way mirror) – isn’t that defeating the purpose of having a cached disk array, whether it be Shark or EMC? The major point of using an Integrated Cached Disk Array is that you let the array do the mirroring, and from the host standpoint you simply have a single drive.

    When you introduce Veritas into this kind of mix, you start running into issues with, “Are the mirrors completely synched when you snap the mirror before you start the snap-copy on the array?” If there is something missing there, (and I do understand that you’ve stopped the app,)have you unmounted the filesystem or considered doing a freeze/thaw on it to quiesce the data?

    It is an interesting configuration at best… I’m not a big fan of Veritas Volume Manager (or DMP for that matter, PowerPath is *MUCH* easier to deal with) for these very reasons, they make your job much harder. For some reason, HP’s and AIX’s LVMs are much easier to work with, and more compatible with timefinder-like applications.

    Of course when given the choice, I’ll choose raw disks anyday.

    The long and the short, it sounds like you’ve got a consistency point

    • on March 1, 2007 at 5:55 am
    • Reply

    Good point about the DG metadata — you’re right, you shouldn’t have to deport/import unless the Veritas metadata changes on the production server.

  1. Yeah – normally it’s only if you add an LV or add a physical disk and expand the LV into it that you have to reimport the VG. (Some OS’s allow for a rescan I believe)

    • on July 24, 2007 at 3:41 am
    • Reply


    I want to use clone to migrate some windows 2003 SAP servers to larger metavolumes and I’m looking for some guidance on this. Here is how I wanted to do it.

    1. creat pair and use the -precopy option
    2. when the target is nearly in sync with the source shutdown both nodes of cluster.
    3. activate the session
    4. verify hosts are shutdown
    5. once they are 100% syncronized terminate the session.
    6. unmask source volumes from cluster
    7. mask target volumes to cluster.
    8. Bring up hosts.

    any comments or help would be appreciated.

  2. You can’t clone to different sized metas – I just tried it and found out the hard way

    The only thing you can really do is expand the metas, but make sure you use the -protect option otherwise you’ll find that you’ve blown the VFAT away and are starting over.

    The syntax of the command (using the usual symconfigure) is simple:

    add dev xxx:yyy to meta zzz, protect_data=true, bcv_meta_head=bbb ;

    xxx:yyy is simply the range of devices you’re adding,
    zzz is the head of the existing metavolume

    IMPORTANT: bbb is a BCV meta device at least the size of the original volume to temporarily hold the structures that are going to change in the new metavolume.

    You can expand a volume using “protect_data=false” but you’re going to get a new, clean metavolume sans data. 🙂

    • on August 9, 2007 at 11:17 pm
    • Reply

    Thanks for the info. Can you give me a sanity check on my procedure to migrate a windows cluster using clone? I talked to EMC and they said it will work but I still have some questions. I have altered my procedure slightly.

    1. creat pair and the use the -precopy option. I was going to kick this off 24 hours ahead of the actual cutover.
    2. Shutdown and power off the hosts.
    3. Activate the session
    4. Terminate the session after verifying the pair is fully syncronized. This will leave the target write enabled and a exact copy of the source correct??
    5. unmask the source from both nodes of cluster.
    6 Mask the target devs to the cluster.
    7. Power up the hosts.

    Do you see any issues with the way I am doing this?

  3. Somewhere between 5 & 6 you may have an issue because depending on the settings in your HBA driver, the new devices may need to be mapped.

    An example, I’m a control freak. The first thing I do when i set up a system is turn Automap off, and turn manual lun masking on. That way, no matter what I know exactly what device is where. It makes my particular brand of OCD much less painful to deal with, but means that any time target or lun#’s change, it’s a manual process.

    It also allows me to map, for instance Fibre lun 312, to lun “0” as far as windows sees it, thus making deciphering cXtXdX numbers in powerpath a lot easier.

    Speaking of which, it might be better, once everything comes back up to run ‘powermt check’ if you’re running powerpath, to clean up the paths that PowerPath think should be there but aren’t any more. (Clears the alarms in ControlCenter as well)

    Hope this helps.

    • on August 22, 2007 at 12:06 am
    • Reply


    Migration went fine using clone. Thanks for the help.

    On a different note, I am considering some positions as a storage admin with some other companies.
    I have never done this type of contract work before so I am kinda lost here.

    What is the going rate for a admin/consultant with heavy EMC experience? I am assuming that they will not provide benefits and therefore I should ask for a much higher rate? Any advice would be appreciated.

  4. It’s different for every person. I know what I am making now, and I settled for a lot less than I could have because I have a one-year contract. (though the one year contract isn’t worth the paper it’s printed on, either party can break it with two-weeks notice)

    Assume right, you’re providing benefits yourself. You’re also handling the paperwork, filing taxes, doing the day-to-day business stuff.

    Long and short is if you were making $100K/year salaried you were probably taking home between 70-80K after taxes, insurance and all that nonsense. The pay scale isn’t that different for consultants, but you want to ask for enough that you’re taking home a bit more, which essentially covers the uncertainty of your position. I’d say that if you were making $100K/year gross as a W2, your gross as a 1099 consultant should be at least $120-130K/year. Remember that there were a number of soft costs that your employer picked up, benefits and such. You may have paid $150 every two weeks for your benefits, but your employer put in about the same, maybe even more. You also have to figure in retirement (what you put away for the rainy day)

    Best bet is to get with NorwinTechnologies (www.norwintechnologies.com) or someone like that and let them do the pimping for you. They find the gigs, they take their cut, and you’re left with what’s left.

    In fact if you want, send me your resume and I’ll put you in front of them. There is *ALWAYS* a demand for EMC people. 🙂

Leave a Reply

Your email address will not be published.