The Different Flavors of EMC TimeFinder

I don’t know what most people know about TimeFinder, so I’ll start with a short introduction.

EMC Timefinder was developed to provide customers with a dynamic mirror they could use to try and cut some of the tediousness out of copying data, whether from one host to another or within the same host.

When I was working for EMC, Timefinder was still more or less in it’s infancy, and only came in one flavor.  (Now referred to as “TimeFinder/Mirror”)

A Timefinder volume is a volume that is essentially a dynamic mirror of a production volume.  Called a ‘BCV’ (for Business Continuance Volume) it was a straight 1:1 mirror of your production data.  (If you were running in a 2-Way-Mirrored configuration, the BCV essentially become a third mirror.)  At a point-in-time, you could split the third mirror off it’s production pair and make it available to another host.

The main benefits were obviously discovered in Backup.  You could split a BCV of your production data off, mount it to another host, and back it up to a locally attached tape library with zero network overhead.  Using this you could also use a single backup host to back-up copies of BCV’s from multiple production hosts.

Another good use for BCV’s was in development.  One story I like to tell was from I was an admin several years ago.  Developers liked to “break” their database on a friday afternoon, knowing that the restore from tape would take the better part of a day and in doing so they guaranteed they would make their tee-time.  With the advent of TimeFinder, I was able to tell them “Not a problem, I’ll have it back up in 20 minutes.”   The reason being that I could restore from the mirror almost instantly.

The main negatives for TF/Mirror are that in all cases, the initial synchronization has to complete before the data can be made available to the target system.  Now this is mitigated by the fact that after the initial relationship is established all further mirrors are incremental, meaning that only changed tracks are copied to the BCV volume, but it can still be a time consuming process.

Now EMC has come out with two new forms of TimeFinder in Symmetrix, very similar to the Clariion functionality.


  SNAP uses a process called “Copy On First Write”.   This uses a much smaller volume than the production volume as a “virtual device”  (Called a VDEV)   The VDEV serves as a list of pointers for each track in the volume.  Reads are serviced from the original volume until the track is changed.  When the track is changed the original data is copied to a cache area, and the pointer for this track in the VDEV device is changed to point to the cached original track.  In doing this the VDEV device will contain an exact copy of the production data as it was when the Snap session was activated.  When the data is no longer needed, you terminate the Snap session and the cached changes are discarded.

The data is available the instant the SNAP session is activated.

The downside to this is that all reads touch the production volumes.  In a heavily utilized system there can be a noticible impact.  Another negative is that SNAP sessions are limited to the amount of cache set aside.  A usual configuration is to set aside about 20% of the area used by production as “SnapCache”  This can then be used as needed.  If the SnapCache fills up, the Snap session ends and that is that.


  Clone uses another process, similar to SNAP, called “Copy On Access”.  Clone volumes are identically sized to the production volumes, which of course uses up more space, but provides for a more permanent home.  This provides the data permanance of TimeFinder Mirror, the speed of TimeFinder Snap, and the agility to move data from Standard volume to another standard volume. (Raid-1 production volumes to Raid-5 Development volumes is a good example)

What copy-on-access offers is the unique ability to use the volume before it’s actually finished mirroring.  When a clone session is first started, all the target volume contains are pointers to the source volume.  Every time a track is accessed, (read or write) it is copied to the target volume first.  (prior to any write operations)  If no options are selected this is the only time a track is copied.  If the -copy option is selected when the Clone session is created, a background copy of the production volume is started.  This will eventually result in a copy of the data that will persist after the clone session is terminated.  (when no option is specified, the data will disappear when the session is terminated)  There is also the option to copy (mirror) the entire production volume to the target volume before the session is activated.  This is called “Precopy” and is a close emulation to what is done using TimeFinder mirror without the limitations of having to use BCV’s as targets.

TF/Clone has to be the best of all worlds.  It gives you the flexibility of Snap with the data-resilience of Mirror, and the flexibility of being able to go from one volume to another without restrictions on what type of volume your target is.  (TimeFinder/Mirror requires the use of BCV volumes)

Timefinder is the production that gave me my introduction into EMC.  TimeFinder and SRDF are also the technologies I’ve implemented more often than any others in my work for (and with) EMC.

If you’ve got questions, feel free to post them.  You’re probably not the only ones.


1 ping

Skip to comment form

    • on February 27, 2007 at 8:57 am
    • Reply

    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.

    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.

    Is this possible with EMC?

    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.


  1. Mounting the clone on the production host is a sure-fire way to corrupt data. Your EMC folks are dead wrong on that.

    • on April 23, 2007 at 7:54 pm
    • Reply

    The one issue I’ve always had with TimeFinder (and EMC in general) is that it is exclusive and doesn’t function well with third parties. Has anyone out there developed a product that will allow Tfinder to store it’s BCV’s on inexpensive external storage (like Nexsan, Infortrend, Digidata, etc) or are we always to be stuck paying for expensive EMC disk for a BCV/Snap/Clone?

  2. Funny – this topic gets more responses.

    You might check out “EMC Open Replicator for Symmetrix” It’s essentially SANCopy for Symmetrix, where the Symm FA acts as a host initiator and pushes data to differing storage systems. I’ve seen it used for Symmetrix to Clariion pretty regularly, but it does support IBM, Hitachi, or any disk system that can accept block-level writes from the Symm.

    • on April 28, 2007 at 3:58 am
    • Reply


    Nice and informative blogs i must say…
    I have just started working on EMC symmetrix storage and m in love with them. I hope i can contribute to this informative content with my experiences in future.
    Just looking for an EMC certification ryt now, so wanted an expert advise to whether choose an symmetrix BC path or clarrion. FYI, i along with ma team have just setup a DR site and got to do some stuff with SRDF, great technology i must say.
    Any advise from the experts would be appreciated.

  3. I’m glad you’re liking it.

    When it comes to advice, we’re full of it. 😉

    I would go the Symmetrix path. The clariion really is the lower-end of the products. If you are looking to consult on the really fun projects, the Symm knowledge will get you there.

    Clariion will just get you engagements at small-time shops and (in my experience consulting in Southern California) porn publishers.

    • on May 17, 2007 at 10:45 pm
    • Reply

    We are backing up an Oracle database by placing it into Hot Backup mode and using symclone. Our backups times have taking much longer on BCV than Std devices (Non-BCV). I was told that copy on access may be the cause of this problem. We plan to modify our backu stratedgy and test performance. Do you agree this is a valid process.

    (Put Oracle DB into hot backup mode)
    symclone –sid xxxx –g group create –cycle –precopy
    symclone –sid xxxx –g group activate (This is the backup timestamp on the Oracle Database)
    (Take Oracle DB out of hot backup mode)

    Take TSM backups

    In the past (current method) we ran these commands:

    (Initially ran this command when we setup/established the clones months ago)
    symclone –sid xxxx –g group create –copy -differential

    (We now ran/run these commands every night)
    symclone –sid xxxx –g group recreate
    (Put Oracle DB into hot backup mode)
    symclone –sid xxxx –g group activate
    (Take Oracle DB out of hot backup mode)
    Take TSM backups

  4. My question is why are you doing the precopy? You’re waisting all sorts of time if your only goal is to run a backup.

    Use it without options, (no -precopy or -copy) and it’s essentially a snap (in fact, you can do the same thing with TF/Snap and a far smaller drive investment)

    Use it with the -copy option and the data becomes immediately available for backup, and the target disks sync up with the source in the background as the process goes.

    I recently used the -copy option to migrate almost a terabyte of production data from Raid-1 storage to Raid-5 storage with only a two hour downtime window.

    • on January 23, 2008 at 1:45 pm
    • Reply

    Hello Sangod,

    Compliments for the site and the information
    I have a question related to symmetrix , timefinder snap and Vmware
    I hope you can help me think

    At the moment we have a vmcluster3.02 with 6 hp dl585 4 dualcore AMD , 32 Gb server ( soon to be 9) an don our fallback location we have also 6 esx hosts.
    For shared storage we use netapp filers and we backup up all de Vm with snapshots , which we also replicate to our other location for disastery recovery. We use the vmware snapshot combined with the storage snapshot. I my opinion a perfect match

    At this moment we want to connect our vmware cluster with our symmetrix, because we want the data of our vm host to be online replicated to our fallback location.

    We want to use timefinder/snap/mirror to backup the vmware luns combined with a BCV set. But in case of a disaster we want that the backup with the snaps also are replicated to our fallback location ( SRDF/A)
    Just like the way we have done with our netapp snaps

    For restore , we restore the snap to a bcv and attach this to the ESX server.
    There we van import , copy etc the VM’s plus data from the restore lun..

    Backup on 1 location is possible I think, but is it possible to have the backup also on our fallback location. I know its not recommanded bij EMC but i would be the perfect , quick , cheap backup solution.

    What do you think is it possible

    Thanks in advance


  5. Easy actually. (sorry this has taken so long, been running around like mad of late.)

    All you have he do is make both your primary tuns and your BCV’s RI devices replicating to your remote site. They would replicate to separate sets of tuns, all R2 primary devices.

    What you are actually doing is a combination of SRDF/A and SRDF/AR. The SRDF/A link would be the Production devices to the production R2 devices, the SRDF/AR devices world be the BCV/R1 to non production R2 devices.

    Any time you establish the BCV is to the STD devices, the RDF link is automatically suspended, preserving the R2 devices integrity of the R2 devices. when the BCN establish is complete, the RDF link is resumed, and the new data is then copied to the remote site, to the “non-production” R2devices.

    Simple, right? LOL

    • on January 31, 2008 at 7:57 am
    • Reply

    SANGOD, Thanx for the information,

    We want to use Timefinder /snap so we have a safe area where the snaps are reserved. (was me explained) and we want to use it as a backup with more than 15 copies , so not just 1 with a bcv.
    So the backup is a BCV plus the safe area with snaps.
    My question : does the solution also include the safearea and do we have a complete backup solution for more than 15 copies on our failback,

    If so, LMAO

  6. Here’s the problem with TF/Snap. It’s not a “permanent” backup solution. In most cases the SNAPCache is 20-30% of the size of the production volumes. This allows for only a limited snapshot.retention. Even if you dedicated 50% of the box to snapcache you would probably run out of cache before you could complete a backup.

    The other limitation you’ll find yourself running up against is the fact that only 4 concurrent snap sessions are supported.

    I think you’re more likely to have luck with TF/Clone – it requires more space, but once the mirror is completed the data is retained after you terminate the session, unlike snap in which the snap is discarded when the session is terminated.

    Clone also allows you to make an “immediate” copy (instead of having to wait for the initial sync like you do with BCV’s and TF/Mirror) which allows for better timing.

    Does that make sense or should I stop answering questions before 8am?

    • on February 6, 2008 at 6:18 pm
    • Reply

    Thanx for the very quick response , i wasn t expecting that 😉 , i studing for an exam last couple of days .

    Retention of 6 weeks is acceptable, 4 concurrent session is also acceptable .
    The reservation is also not a big problem because snap also safes a lot of space an we are trying to go to a tapeless backup so we can have a small RTO.
    Dont you think 50% is enough for 6 weeks snaps , with our netapp, this is not a problem.
    After 6 weeks the snaps are released and wont grow anymore , correct ??
    If so and the bcv plus safearea is mirrored (non prod R2) I would be happy.
    Could this be our solution ?

    I will look into de tf/clone but then it think it will cost a lot of more space then the snap especialley with a retention of 6 weeks.
    I asume it also possible to mirror the timefinder/clone bcv. It is very important that al the information data will be mirrored to our remote site.
    Sorry for all the questions but it is hard to find the right info about this subject.

    PS : your answers make sense even in the morning


  7. 4 is the magic number. You can’t have more than four snaps active, and there is no way to preserve the data once you terminate the snap session. So four snap sessions is it.

    There are really two good ways to do this for backup. You can use normal BCVs and TimeFinder mirror, you’re burning space but you can keep as many copies as you’d like, or you invest 20-30K in a small Clariion, maybe 5-10 TB of ATA storage and use SANCopy to move your copies to the Clariion from the Symm. I think the best way to do it and preserve the point-in-time would be to create a snap session at 12:01am, and then sancopy the snap to the clariion as your point in time.

    (For refrence, a single rack of 15 750G ATA disks, carved into two 6+1 raid groups, is about 9TB of usable space.)

    The other way is with a set of BCV’s for each copy, which, as we both know, is an expensive solution.

    • on February 19, 2008 at 11:18 am
    • Reply

    Thanx for the information
    We wil consider it


  8. You are quite welcome – I hope I could be of help.

    • on May 21, 2008 at 10:13 am
    • Reply

    Quick question for you. If you have a BCV and you take that BCV and mount it to another host for testing, and the users change data on it, does the next establish erase the changes that were made to the BCV from the other host or does only the changed tracks from the standard get copied over, effectively causing you to do a full establish to ensure a valid BCV? Does an incremental establish work in both directions?

  9. Short answer is yes – changes made to the BCV are overwritten on the next incremental establish.

    Essentially the track is marked “Dirty” when it is changed, as such when the establish is done it’s considered a track owed to the target from the source.

    Yes – a restore operation can (and usually is) done incrementally. You take the production host off-line, issue the restore, and bring it back up. The production host will have access to the data immediately, because the BCV is considered a third mirror of the first two devices. When the restore is issued the changed tracks on both the source and target are marked dirty on the source instead of the target, causing them to be reverse-synched.

    Investigate using a -protected option when you do a restore. That preserves the BCV’s original contents from changes from the source when you do a remote sync and bring the production host online before the sync is complete. That way your point-in-time backup is still valid.

    • on June 17, 2008 at 3:00 pm
    • Reply

    Along the same lines as the BCV being overwritten. I used clone disk mounted up on a target system. On the target system the data changed. I then did a symclone recreate with the source disk. I once again did a symclone -sid xxxx -f file activate consistent. I again mounted the clones up on the target system. But it looks like data was still the same from the last time it was mount up. Is this possible?

  10. It would be easier for me to give a definitive answer knowing the operating system.

    A lot of times, with some OS’s (windows being one of them) the inode table is stored in memory as long as the volume is online. The only way to reload it is to completely unmount the volume and remount it. (This works in most unix environments, but I suspect that yours is one of the special ones)

    • on June 17, 2008 at 8:57 pm
    • Reply


    HPUX11.23i The clones on the target system we were using for a test (an oracle database). We change the data. I then did a symclone recreate -copy. When I activated them and remount them up on the target system some of the old test test data the we had changed was still there. I did not think that was possible, like you said above I thought it would be mark as a dirty track and written over by the source. Is clones different than bcv’s?

  11. God I hate HP – but in this case it’s not HP.

    Re-try the recreate command with ‘-v’ flag – this should give you more information about the problem.

    The only state which is acceptable for running recreate is copied – run a symclone verify or symclone query to ensure that all clones are 100% copied.

    In order to have the ability to run a recreate, you must have used the -diff option together with either -copy or -pre-copy on the original create.

    The last step toward making this work is to mount it in such a way that would force a rescan of the inode table.

    You might try mounting with the option -o dirsync to force all IO to the directory to happen in synchronous mode.

    Let me know.

    • Kiran on January 2, 2011 at 5:54 am
    • Reply

    Hi Sangod,

    I am new to EMC and would like to know if there is any good/nice doc that explains the terms BCV,standard device,physical device, Plex,Differential,Clone,Thin Pool etc? I have started working on EMC products and getting confused with the terminologies.

    1. My recomendation – use the google wherever you can. 😉

      most of the information you seek is there. 😉

    • Nikhil on March 18, 2012 at 5:23 am
    • Reply

    Hi Sangod,

    I just want to confirm whether VDEV’s should be same as source devices? Tried to do a TF/ Snap manually with different source & target size and it failed saying “ The size of the source device is not same as the size of target device”

    It worked when I created a VDEV with same cylinders as source device, is it the VDEV (a cache device) has to be the same as the source device in emulation, at least as large, and have the same meta configuration if there is one.

    I undersatnd that the backing store (SAV devices) do not need to be the same size.

    Thanks & Regards,

    1. Snapshots must be to the same size/makeup device. IE same number of cylinders / meta members.

      Clone works as long as the target devices are bigger (but must have the same number of meta-members because it depends on a 1:1 mapping.)

      if you’re trying to do a completely different device size/shape, I’d use symmigrate. It’s essentially the same as the migrate functionality in the Clariion where as long as the target device is bigger it doesn’t matter how it’s made up. (We used symmigrate recently to go from 58-way 1.8T metas to 8-way 1.8T metas)

      Hope this helps.

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

Leave a Reply

Your email address will not be published.