TimeFinder from EMC

EMC has three instant copy products, TimeFinder/Mirror, TimeFinder/Clone and TimeFinder/Snap The key differences between the products are summarised in the table below.
TimeFinder/Mirror Copy methodology Copy space required Availability of copy data Performance impact Full mirror. The mirror is always in synch. with the source until the split command is issued. Full disk TimeFinder/Clone Point in time copy based on pointers until copy process is complete TimeFinder/Snap Point in time copy always based on pointers Partial space depending on amount of data updates. Typically 30% of source Copy is available as soon as the PiT pointers are established All initial updates will require extra processing to move data. Minimal DR as full disk is reliant on pointers to original disk Immediate The snap copy can be RAID5

Full disk

BCV cannot be split off until the copy Copy is available as soon as the PiT process is complete pointers are established Hardly any Initial copy is a background process. Some performance impact if data is updated while copy is in progress Full DR once copy is complete, but not if Copyonaccess setting is enabled

DR capability

Full DR once copy is complete

Not accessible until copy is complete Accessability of and the BCV is split from the copy standard volume Protection The BCV cannot be RAID5

Immediately accessible The clone copy can be RAID5

All products can be managed by the EMC Replication Manager, if used for Open Systems data. Also, all products can use Copy Assist, a product which ensures a consistent Point-in-time copy over multiple disks, by temporarily freezing IOs until the copy is complete.

TimeFinder/Mirror
TimeFinder/Mirror uses dynamic mirror volumes called Business Continuity Volumes, or BCVs. The TimeFinder terminology is Standard Volume (SV) for the primary disk, and BCV for the copy disk(s). A BCV is a mirrored copy of an SV, and has its own host address. You can have up to 16 copies, 4 of which can be actively copying data in the background. A BCV cannot be accessed while it is in association with a standard volume, but if it is split from the SV, then it can be accessed for backup, testing or whatever. The TimeFinder/Mirror Commands are -

To set up a BVC you must first create a device group, add an SV to it, then associate a BCV device to the SV. The BCV must be offline, and effectively becomes another mirror to the SV, so the BCV data is synchronised with the Standard Volume. The commands below create a default type group called group1, add a Standard Volume 01f to it, associate BCV device 110 to it, then starts to create the BCV data. As this is the first time the BCV has been created, then a full establish is required.

symdg create group group1 symld -g group1 add dev 01f symbcv -g group1 associate dev 110 symbcv -g group1 -full establish 01f bcv 110

To remove an association between the SV and the BCV you issue the split command. The point-in-time of the copy is the time the Split is issued. The SV is unaffected by a split. TimeFinder keeps a record of changed

tracks after a split, to speed up a refresh of the BCV. The command below will split off a BCV once the copy operation is complete.

symmmir -g group1 split

The establish command is used to re-synchronise a BCV which was formerly established, then split. It copies over tracks which have been changed on the Standard Volume, and also replaces tracks which were changed on the BCV with tracks from the SV, to get the BCV synchronised again.

symmmir -g group1 establish

It is also possible to restore the SV from data on a split BCV. This will restore the Standard Volume back to the state it was in at the start of the Split command, provided the BCV has not been updated. The first command just does a restore of changed tracks, the second command does a full restore of all the tracks.

symmmir -g group1 restore symmmir -g group1 -full restore

If you want to report on the status of your BCV devices, use the following commands.

symmmir -g group1 query

For TimeFinder/Mirror, the point-in-time happens when the mirror split command is issued.

Timefinder/Snap
Timefinder/snap works by creating a new image of a LUN that consists of pointers that reference the data on the original LUN. If any updates are scheduled to the source, the original data is copied to the snap before the source is overwritten. However, the snap does not reserve space for a full disk to cater for any updates. You allocate a 'Save Device', which is a common pool for original data which needs to be copied if updates are made to the primary. Unlike other implementations, TimeFinder/Snap is designed for applications that need temporary access to production data, maybe for reporting or testing. It is not designed to be, nor is it suitable for disaster recovery, as it is completely dependent on the existence of the source data. The Snap utility can normally create up to 16 independent copies of a LUN, when the target data appears to be frozen at the time that each Snap command was issued. You can increase this to 128 copies by issuing the command
SET SYMCLI_MULTI_VIRTUAL_SNAPSIZE=ENABLED

The starting point for defining a snap copy is to set up a volume group that contains all the data that you want snapped. The examples below refer to a volume group called SNAPDB. Once you have your volume group, you need to start the session between a standard volume and a snap copy with a create command. The device numbers are for illustration only. Use your own device numbers. addall means add all the ungrouped devices in the specified range, -vdev means the command just applies to virtual devices

symdg create SNAPB

symld -g SNAPDB addall -range 00:09 symld -g SNAPDB addall dev -range 3E:37 -vdev symsnap -g SNAPDB create

Activate starts the copy-on-write process that preserves the snap copy.

symsnap -g SNAPDB activate -consistent

If you want to 'refresh' your snap copy to make it look like a current copy of the source group, you need to terminate the existing session, then re-establish the snap. This starts a new point in time copy using a differential update.

symsnap -g SNAPDB terminate symsnap -g SNAPDB create symsnap -g SNAPDB activate -consistent

RESTORE used to recover a volume back to the point in time state. This can be the original volume or a new volume.

symsnap -g SNAPDB restore

Timefinder/Clone
TimeFinder/Clone volumes are called clone copies, and can be BCVs. The Clone copies can be in RAID5 format and do not require that a previous mirror has been established . You can have up to 8 concurrent clone copies. Clone data is immediately accessable from a host, unlike standard BCVs where you need to wait for the copy to complete. TimeFinder/Clone has two activate modes; -copy and -nocopy. With the -copy mode you will eventually have a complete copy of the original disk at the clone, as it was at the point-in-time the activate command was issued. With the -nocopy mode, only updated tracks are copied and uncopied data is maintained at the clone with pointers. Either option requires that the clone be the same size as the source. In open systems, Nocopy is the default and as all the data is not copied, it cannot be used as a DR position. The create command has a -precopy option that starts the full copy process off before the activate, so speeding up the process of creating a full copy. In a mainframe setup, the SNAP command automatically starts a full copy process. The TimeFinder/Clone Commands are -

Create initiates a session between a standard volume and a clone copy. You can initiate sessions for an entire device group, between two devices in a group, or between two ungrouped devices. The first command below assumes a device group called CLONEDB has already been defined and creates clone sessions to target devices within the group. The second command will initiate a session between 2 specific devices. The third command uses the -precopy option so the copy process begins as soon as the clone relationship is established, and -differential, which allows the clone to be refreshed at at later date.

symclone -g CLONEDB -tgt create symclone create DEV001 sym ld DEV002 symclone create DEV001 sym ld DEV002 -precopy -differential

Activate makes the clone available for read/write and with the -copy option, starts the data copy process from standard volume to clone. The default action is no-copy, which means that only updated trackes are copied over from the source. You can query the status of a clone, including the status of the copy process, with the third command below. The copy status will be either 'copyinprog' or 'copied'.

symclone -g CLONEDB -tgt activate -consistent symclone activate DEV001 sym ld DEV002 symclone -g CLONEDB query

If the clone was started with the -differential option, it is possible to refresh the clone copy to the current point in time. To do this you need to issue the recreate then activate commands below.

symclone -g CLONEDB -tgt recreate

symclone -g CLONEDB -tgt activate -consistent

You use RESTORE to recover a volume or group back to the point in time state. This can be the original volume or a new volume. You need the -force option if your source volume is in an active RDF session with remote R2 devices. The symclone query command will show the status as 'Restore in Progress' or 'Restored'. Once the restore completes you need to split the clone before you can re-establish cloning in the normal direction

symclone symclone symclone symclone

-g CLONEDB -tgt restore -force restore DEV001 sym dev 0041 -g CLONEDB query -g CLONEDB split

Use terminate to break a clone relationship into discrete volumes, but the clone must be in 'copied' status or the data on it will not be complete

symclone -g CLONEDB query symclone -g CLONEDB terminate DEV001 sym ld DEV002