timefinder vp snap local repl wp

White Paper

Abstract

This paper describes TimeFinder VP Snap in thin environments on the Symmetrix VMAX Family storage systems for Open Systems platforms. TimeFinder VP Snap is described, as well as associated features for business continuance. Implementation guidelines, including the associated restrictions and limitations for this product, are described. December 2013

IMPLEMENTING TimeFinder® VP SNAP FOR LOCAL REPLICATION Applied technology for thin environments on Symmetrix® VMAX® Family systems

2 Implementing TimeFinder VP Snap for Local Replication

Copyright © 2013 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.


Table of Contents

Executive summary.................................................................................................. 4

Audience ............................................................................................................................ 4

Introduction ....................................................................................................................... 4

TimeFinder VP Snap ................................................................................................. 5

VP Snap operations ............................................................................................................ 6

Handling of Unallocated Source Tracks .............................................................................. 7

VP Snap considerations...................................................................................................... 7

Interoperability ............................................................................................................... 9

Environment variables .................................................................................................. 10

Implementing VP Snap ..................................................................................................... 10

Configuring the devices (Optional) ............................................................................... 11

Creating a device group .................................................................................................... 12

Using symclone to execute VP Snap sessions ................................................................... 13

Restoring VP Snap sessions ............................................................................................. 20

Incremental resynchronization of a clone with cascaded VP Snap ................................ 22

Clone incremental restore to a VP Snap source device .................................................. 29

VP Snap Restore to Target (RTT) .................................................................................... 32

Conclusion ....................................................................................................................... 38

References ....................................................................................................................... 38


Executive summary EMC TimeFinder® for local replication is software that delivers point-in-time copies of devices that can be used for backups, decision support, data warehouse refreshes, or any other process that requires parallel access to production data. TimeFinder allows users to make copies of data on multiple target devices from a single source device.

Enguinity provides new TimeFinder functionality called VP Snap that offers space-efficient snaps for virtual pool devices. TimeFinder VP Snap delivers the efficiency of snap technology, with improved cache utilization and simplified pool management.

This document describes TimeFinder VP Snap technology, its associated features for business continuance, and implementation guidelines, including restrictions and limitations for this product.

The features discussed are valid for any environment running Enginuity 5876 on VMAX® 10K, VMAX® 20K, or VMAX® 40K Series arrays.

Audience

This white paper is intended for storage administrators, database administrators, and technologists who have an interest in understanding the concepts surrounding TimeFinder VP Snap.

Introduction

EMC Symmetrix VMAX 40K Series arrays are a technology refresh built on the foundation of the industry-leading Virtual Matrix Architecture, which provides higher levels of scalability, performance, and consolidation for the most demanding virtual data-center environments.

The capabilities of Enginuity to network, share, and tier storage resources allows data centers to consolidate their applications to deliver new levels of efficiency with increased utilization rates, improved mobility, reduced power and footprint requirements, and simplified storage management.

Enginuity 5876 delivers the following new capabilities:

Fully Automated Storage Tiering for Virtual Pools (FAST™ VP) and Virtual Provisioning™ for IBM System z and IBM i environments

VLUN VP Migration support for IBM System z and IBM i environments

Increased efficiency

FAST VP support for SRDF® and SRDFe configurations

Increased consolidation and reduced TCO

RecoverPoint™ Splitter

TimeFinder VP Snap


Ease-of-integration and management

Unisphere® for VMAX

Dynamic back end

Federated Live Migration cluster support

TimeFinder VP Snap TimeFinder VP Snap allows multiple snaps to share capacity allocations within a thin pool, thus reducing the storage required for saved tracks. TimeFinder VP Snap is available with Enginuity 5876 and Solutions Enabler V7.4 and higher, and it is designed to create point-in-time replicas that are conceptually similar to those created by TF/Snap. Both source and target devices must be thin, and the copied data resides on allocations in a thin pool. VP Snap sessions are unique because thin-pool allocations can be shared amongst target devices. For example, source updates that are new to multiple point-in-time copies are saved in a single set of allocations that are shared by two or more target devices. When data being copied from a source device is needed by more than one target, only a single shared copy will be moved to the target thin pool. Allowing multiple targets to reference the same shared copy provides cost-effective space savings.

Figure depicts a source device with three targets that are sharing a single-track allocation within the thin pool.

Figure 1. VP Snap track-allocation sharing


VP Snap operations

TimeFinder VP Snap sessions copy data from a source device to a target device only if triggered by a host write I/O. Therefore, read I/Os to protected tracks on a target device do not result in data being copied.

For a single activated VP Snap session on a source device, the target represents a single point-in-time copy of the source. Copied data resides on allocations in the thin pool. For example, if tracks 100, 200, and 300 are written on a source device, the copied data for each track resides in a unique allocation in the thin pool.

When there is a second VP Snap session from the same source device to a different target, the allocations can be shared. For example, if tracks 1,100, 1,200, and 1,300 are written on the source device, the data is a new point-in-time copy to both targets, and it can be saved in a single set of allocations that is shared by both target devices.

However, if there is another write to tracks 100, 200, or 300 on the source device, since the data is a new point-in-time copy for only the second session, when the tracks are copied to the second target device, they are put into a set of allocations that are uniquely referenced by the second target device. In other words, the allocations for these tracks cannot be shared.

If more VP Snap sessions are added to the same source device, data is copied to the targets based on whether the source data is new with respect to the point in time of each copy. When data is copied to more than one target, the targets will reference a single shared copy in the thin pool.

If there is a write I/O to one or more of the tracks stored in a shared allocation, the affected allocation for that target splits off from the shared group because the data is now different than the data for the other targets that are using that allocation. The new data of the written target is stored in a separate allocation, while the shared allocation still contains the data of the other targets.

When VP Snap sessions are terminated, the target device is removed from any shared allocations that were part of the session, and any non-shared allocations for that device are deallocated. When all but one of the VP Snap sessions are terminated, the last remaining session uses the same space in the thin pool, but it is no longer a shared allocation. Upon termination of the last session, the space is deallocated.

Similarly, when a recreate command is issued to a VP Snap session, the target device is removed from any shared allocations and any non-shared allocations are deallocated. The recreate will activate a new point-in-time image and resets all of the virtual pointers to point to the source device. The result is effectively the same as terminating a session and then creating and activating it again, all in a single command. The point-in-time for all other VP Snaps from the same source device will not be affected.


Handling of Unallocated Source Tracks

When a VP Snap session is activated, the microcode will clear protection for source tracks that are on unallocated extents. The "symclone query" command looks at the number of tracks that had protection cleared to calculate the percent copied for the pair. Even though VP Snap sessions are copy-on-write sessions, this behavior may give the appearance that the session is copying from source to target even when the source volume has not been updated.

Clearing protection on a source track that has no data before host access helps performance in two ways:

Asynchronous Copy On First Write (ACOFW) process will not be needed if the host writes to the source track.

Redirect will not be needed if the host accesses the track on the VP Snap (read or write).

VP Snap considerations

TimeFinder VP Snap has the following characteristics:

This feature is invoked by using symclone command syntax.

A VP Snap session is created using the –vse attribute. It may only be applied at session creation.

The –vse attribute is not required with the recreate command.

Support of this feature is limited to Open Systems devices (FBA and AS400 D910 iSeries) and thin-to-thin device clone pairs.

Persistent preallocations:

A device with persistent preallocations can be used as a VP Snap source.

A device with persistent preallocations cannot be used as a VP Snap target.

If a device is the target of a VP Snap session, then persistent preallocation cannot be set on that device.

Cascaded sessions from clone targets is supported with the following considerations:

Regular TimeFinder/Clone sessions must be in the Copied or Split state for a VP Snap session to be created from its target device.

The target of a VP Snap session may not be used as a source for any other clone or snap session.

VP Snap allows a total of 48 sessions on a source device—16 traditional sessions (TimeFinder/Clone and TimeFinder/Clone Emulation), plus 32 additional VP Snap sessions.


Differential restores are persistent, which results in increased usage of thin pools.

A differential restore results in an additional session charged to the source device.

The VP Snap will be not ready to the user after the restore command is issued. The user can set it to ready if they wish to access the VP Snap while restore is in progress. This is consistent with TF Snap behavior.

Once a VP Snap session is created, you cannot change it to any other mode by attempting to use set mode.

Incremental restores of VP Snap sessions are supported with the following restrictions:

All clone sessions associated with the selected source device must be fully copied or split.

The VP Snap source device may have only one restored session at a time. (This is consistent with all TimeFinder/Snap and TimeFinder/Clone behavior.)

Once restored, the only operation allowed is terminate of the restored session.

The Clone Larger Target feature is not supported.

All VP Snap target volumes for a particular VP Snap source device must be bound to the same pool.

VP Snap targets may be either bound to the same pool as their source, or placed in a separate or dedicated pool. Several points should be considered when making your decision:

System management may be simpler if the VP Snap source and targets share a pool, and some systems may contain only one pool. However, placing the VP Snap target volumes in a separate pool prevents production volumes from being impacted if activities on the targets create a pool-full condition. Target activity includes the copy process and host writes to the targets.

It is important to ensure that the pool housing VP Snap target devices has enough data and performance capacity to support the I/O workload it will receive. Included in this are the read/write activity related to COFW destage, as well as I/O addressed directly to the VP Snap volumes.

The pool must have sufficient capacity to accommodate the expected change rate of the target volumes, and the pool needs to be properly monitored after implementation.

Some users may opt to use VP Snaps to replicate data to a slower tier. However, if the VP Snaps are expected to be readily accessed by the user, then the target pool should typically have at least the same performance characteristics as the source pool.


Just as with any other Virtual Provisioning pool, a sufficient number of physical drives must be configured, regardless of size and speed, to spread the workload across the back end and help prevent bottlenecks.

Interoperability

TimeFinder VP Snap is interoperable with other EMC Symmetrix software products under the following conditions:

SRDF

The use of R2 devices as VP Snap sources require that SRDF/A Device-level Write Pacing is configured with autostart on the R1 side, or that the Device-level Write Pacing is activated and supported during the SRDF/A session.

A TimeFinder VP Snap target cannot be an RDF device.

ORS

A TimeFinder VP Snap source device may be used as the control device for ORS push operations, but not for pull operations. A VP Snap target device is not permitted to be used with ORS.

FAST VP VP Snap source devices are optimized by FAST VP. FAST VP will not move data between tiers on VP Snap target volumes that have shared allocations.

Best practice is to make sure that all VP Snap targets for a particular source have the same FAST VP profile, which is associated to policies that incorporate the same pools.

Read miss I/Os to tracks on a VP Snap target device that are redirected to the source device will increment the FAST VP metrics for the source device, not the target device.

VP Allocation by FAST Policy:

Beginning with the 2013 Q2 5876 Service Release, VP Snap targets can take advantage of VP Allocation by FAST Policy for host writes and the clone copy process. Shared allocations can be placed in pools other than the bound pool according to FAST Policy only if all VP Snap targets for a particular source are in the same FAST Policy. If they are in different policies or some targets are not in a policy and the bound pool is full then the sessions will fail when they try to create another shared allocation.

Prior to the 2013 Q2 5876 Service Release, VP Snap Targets could not create shared allocations in pools other than the bound pool. Once the bound pool was full, the sessions would fail at the next attempt to create a shared allocation.


VLUN VP Snap source devices can be migrated with VLUN. VP Snap target devices cannot be migrated with VLUN.

FTS TimeFinder VP Snap target devices configured in FTS pools will only share extents when the target devices are non-encapsulated. When target devices are encapsulated, extent sharing is not possible. However, encapsulated target devices will still get the benefit of the extra 32 sessions and restore capabilities.

Environment variables

Users can specify a symcli environment variable to change the default TimeFinder/Clone copy mode. Set SYMCLI_CLONE_COPY_MODE to determine the type of clone session that is to be created by default. A new copy mode VSE_NODIFF is available for VP Snap sessions, however, if the user specifies -precopy, -copy, or -nocopy during the create, the default is overridden.

SYMCLI_CLONE_COPY_MODE specifies the mode in which clone sessions are created. The available clone copy modes are:

NOCOPY_NODIFF

COPY_NODIFF

PRECOPY_NODIFF

COPY_DIFF

PRECOPY_DIFF

VSE_NODIFF

Implementing VP Snap

Implementing VP Snap requires a series of steps to ensure that the proper devices are available, to verify the existence of a virtual pool where target devices will reside, and to create VP Snap sessions.

Note: The following tests can be run on all Symmetrix VMAX Family storage systems.

1. Ensure that the systems are running Enginuity 5876 and Solutions Enabler V7.4 or later.

2. Execute the following commands to display the Enginuity level and Solutions Enabler (SE) code release: symcfg list


symcli

Configuring the devices (Optional)

Configuring devices and creating a thin pool is optional. Users may choose to use devices and a thin pool that already exists. The following instructions can be used as a guide in the event that configuring a new environment is required.

1. Create the target devices (TDEVs). symconfigure -sid 455 commit -nop -cmd "create dev count=64, size=4GB,

emulation=fba, config=TDEV;"

2. Show the current thin pools on the storage array. symcfg -sid 455 list -pool

3. Create a thin pool named VSE. symconfigure -sid 455 -cmd "create pool VSE type=thin;" commit -nop

4. Create DATA devices. symconfigure -sid 455 -cmd "create dev count=8, config=RAID-5,

data_member_count=7, disk_group=5, attribute=datadev, emulation=fba,

size=16344;" commit -nop

5. Add the DATA devices to thin pool. symconfigure -sid 455 -cmd "add dev 527:52e to pool VSE type=thin,

member_state=enable;" commit -nop

6. Bind the TDEVs to the pool. symconfigure -sid 455 -cmd "bind tdev 4df:4ed to pool VSE;" commit –nop

7. Display the pool devices. symcfg show -sid 455 -pool VSE -detail –thin


Creating a device group 1. Create a device group to simplify the manipulation of devices during testing. Add the source and target devices that will be used for the TimeFinder VP Snap sessions. symdg create testdg

symld –sid 455 –g testdg add dev 4df

symld –sid 455 –g testdg addall –RANGE 4df:4ed -tgt

2. Using symcli output, determine the Symmetrix logical device names, and Symm device IDs.

symdg show testdg


Using symclone to execute VP Snap sessions 1. Display the status of the thin pool to determine space and track allocations. a. Review the number of allocated and shared tracks in the pool: symcfg -sid 455 show -pool VSE -thin -detail

Note: In this example, as in most customer environments, the SRC device contained data before the start of the test. Therefore, the Total Written Tracks already stands at 25 percent.


2. Execute the SYMCLI symclone command to create and activate four VP Snap sessions using source and target devices. symclone –sid 455 –g testdg create –vse DEV001 sym ld TGT001 –nop

symclone –sid 455 –g testdg activate DEV001 sym ld TGT001 –nop

symclone –sid 455 –g testdg create –vse DEV001 sym ld TGT002 -nop

symclone –sid 455 –g testdg activate DEV001 sym ld TGT002 -nop





a. Query the result. symclone list –vse


Note: The V and X target device flags and their definitions are provided in the legend in the following graphic.

3. After the initial activation, all written tracks on the source device are protected (as shown in the preceding graphic). Allocations can only be shared when a second VP Snap session from the same source device is created, using a different target. Review the thin pool details to see that the allocated and shared tracks have not changed.

symcfg show –sid 455 –pool VSE –detail -thin


Note: 04DF is the SRC device, and 04EA:04ED are the targets (TGTs).

4. Create and activate four additional VP Snap sessions. symclone –sid 455 –g testdg create –vse DEV001 sym ld TGT005 –nop








5. Query the VP Snap sessions. They all contain the same number of protected tracks. symclone list –vse


6. The IOMeter utility was used to generate I/O to the SRC device.


7. View the pool information again after the second set of write I/O is replicated to the eight target devices. The number of allocated tracks and shared tracks in the pool has increased.

symcfg show –sid 455 –pool VSE –detail -thin

8. The amount of space savings can only be recognized and calculated when you compare the allocated tracks between the VP Snap sessions and regular clone –copy sessions.

a. Take note of the number of allocated and shared tracks in the pool (as shown in the preceding graphic).

9. By terminating the –vse clones and using the same devices as (regular) –copy clones, you see the full benefit and space efficiency of VP Snap.

a. symclone –sid 455 –g testdg terminate DEV001 sym ld TGT001

b. Terminate all remaining targets for TGT002-TGT008.

c. symclone list –vse


10. Recreate the sessions using as traditional TimeFinder/Clone –copy sessions.

a. symclone –sid 455 –g testdg create –copy –nop

b. symclone –sid 455 –g testdg activate –nop

c. Create all remaining sessions for TGT002-TGT008.

d. Activate all remaining sessions for TGT002-TGT008.

11. Again, query the clone sessions. They should appear as regular clone sessions, as indicated by the legend.

a. symclone –sid 455 list

12. Display the thin pool details again. Then, compare this output to the number of allocated and shared tracks produced in step Error! Reference source not found..

a. symcfg show –sid 455 –pool VSE –detail -thin

The number of allocated tracks consumed after activating the –copy clones(414528) is almost four times greater than the number of allocated tracks with the –vse clones (127392).


Restoring VP Snap sessions

VP Snap provides the ability to perform incremental restore operations. This means that target data is not deallocated, as the restores are persistent until all sessions have been terminated.

1. Execute a restore for each target device. Each session must be restored and then terminated before moving onto the next session. symclone –sid 455 –g testdg restore DEV001 sym ld TGT001 –nop

2. Review the status of the restore. symclone –sid 455 –vse list

3. Review the thin pool details for each restored session. Notice that the target tracks are not deallocated. symcfg show -sid 455 -pool VSE -detail –thin


4. Terminate the restored target session, and then display the results. VP Snap restore operations maintain the original session, so that when a VP Snap session is restored, both the original session and the restore session exist. In this case, the restored session must be terminated before the original session. symclone -sid 455 -g testdg terminate -restored DEV001 sym ld TGT004

5. Terminate the original copy session in order to eliminate and deallocate tracks from the thin pool. symclone -sid 455 -g testdg terminate DEV001 sym ld TGT001 –nop

6. Examine the device group and the thin pool VSE. symclone –sid 455 –vse list


Note: When the TGT# is not specified, the VP Snap sessions are terminated in order, from the oldest to the newest session.

7. The tracks are deallocated from the thin pool only after the original VP Snap session has been terminated (as shown in the following graphic). symcfg show -sid xxx -pool VSE -detail –thin

Many users prefer using device files (as opposed to using device groups). The following commands highlight the appropriate syntax when using a device file. symclone –sid 455 –f test.txt create –vse

symclone -sid 455 -f test.txt activate

symclone -sid 455 -f test.txt restore

symclone -sid 455 -f test.txt terminate –restored

symclone -sid 455 -f test.txt terminate

Incremental resynchronization of a clone with cascaded VP Snap

VP Snap features were enhanced with the Enginuity 5876 Q4 2012 Service Release, providing advanced functionality that supports differential recreate and restore features for Cascaded TimeFinder VP Snap.

Incremental resynchronization of a clone with cascaded VP Snap enables users to perform a differential recreate1 of an intermediate TimeFinder/Clone when a cascaded VP Snap session exists.

1 To recreate a session is to activate a new point-in-time image. Recreating a differential clone copy session will only require updates since last point-in-time to be sent to the clone.


For example, if the A->B leg is a regular clone session and the B C leg is an active VP Snap session, then users are now allowed to resynchronize the clone. Enginuity will ensure the persistence of the VP Snap copies from the clone.

The following graphic depicts the new TimeFinder/Clone functionality.

Figure 2. Differential (incremental) resynchronization feature

Note: With this implementation, all devices must be thin.

Restrictions

The incremental resynchronization of a clone with cascaded VP Snap functionality can be successfully implemented with the following restrictions:

Recreate of the clone session is not allowed if the VP Snap session is not active.

The pre-copy flag must be used with recreate of the clone session.

The clone session cannot be activated until pre-copy has cycled.

Implementing the feature 1. Verify the test environment.

All devices are TDEVs.

The minimum versions the systems must be running are Enginuity 5876 Q4 2012 SR and Solutions Enabler V7.5.0.0.

2. Three text files are needed to implement incremental resynchronization of a clone with cascaded VP Snap: test1-SRC-TGT.txt, test1-TGT-vpsnap.txt, and test1-TGT-vpsnap2.txt.

a. test1-SRC-TGT.txt contains the source and target devices.


b. test1-TGT-vpsnap.txt contains the target device and one device used for the first cascaded VP Snap session.

c. test1-TGT-vpsnap2.txt contains the target device and one device used for the second cascaded VP Snap session.

The graphic below depicts the test environment setup, including the device IDs.

Note: This is example uses device files for the pairs. If Device Groups is preferred, the following variables need to be enabled in the Options file: SYMAPI_ALLOW_DEV_IN_MULT_GRPS = DISABLE

SYMAPI_COMMAND_SCOPE = DISABLE Figure 3. Device IDs used to implement the feature

3. For the first leg, A B, a full-copy TimeFinder/Clone is created using test1-SRC-TGT.txt. symclone -sid 455 -f test1-SRC-TGT.txt create –nop

The following is a sample output of the file test1-SRC-TGT.txt.

Note: The –nodiff flag creates a nondifferential (or non-incremental) session, which cannot be recreated or restored. Therefore, the default (–diff) automatically created an incremental clone session for the A B leg.

4. Activate the full-copy clone. symclone -sid 455 -f test1-SRC-TGT.txt activate –nop

5. Query the result. symclone –sid 455 list


6. For the second leg, B C, a VP Snap copy is created using the file test1-TGT-vpsnap.txt. symclone -sid 455 -f test1-TGT-vpsnap.txt create -vse –nop

7. Activate the second leg VP Snap session. symclone -sid 455 -f test1-TGT-vpsnap.txt activate –nop


Note: A cascaded TimeFinder/Clone session has been activated.

In the following graphic, the VP Snap session has been activated for the second leg, as designated by the -vse flag, when the session was created.


9. Create the second (and final) cascaded session by issuing the following command: symclone -sid 455 -f test1-TGT-vpsnap2.txt create -vse –nop

10. Activate this session using the following command: symclone -sid 455 -f test1-TGT-vpsnap2.txt activate –nop



12. Incremental resynchronization of a clone with cascaded VP Snap enables users to perform a differential recreate of an intermediate TimeFinder/Clone, which allows users to resynchronize the clone leg and maintain the persistence of the VP Snap copies.

a. Recreate the clone leg by issuing the following command: symclone -sid 455 -f test1-SRC-TGT.txt recreate -precopy –nop

Note: The –pre-copy option must be used. Until this session is activated, the B device remains in a Not Ready (NR) state and is unavailable for use (mounting, and so on).

13. Query the result.

a. Take note of the legend and the pre-copy status.


14. Verify that the (pre-copy) clone has cycled (meaning that it has copied its data). symclone –sid 455 –f test1-SRC-TGT.txt verify –precopy –cycled

15. Activate the clone leg to complete the cycle. symclone -sid 455 -f test1-SRC-TGT.txt activate –nop

16. Query the result.

a. Take note of the legend indicating the copy settings and final status.


Clone incremental restore to a VP Snap source device

Available with the Enginuity 5876 2012 Q4 Service Release, this feature allows users to perform a clone incremental restore operation to a source device that has active VP Snaps running against it. An incremental restore of VP Snap sessions has always been an option, however, restore operations cannot persist simultaneously on both legs at one time. The incremental restore is accomplished with no impact to the active VP Snap session or the TGT clone session.

The following graphic depicts the new TimeFinder/Clone functionality, where an incremental restore is performed from a traditional TimeFinder/Clone target to its original source device.

Figure 4. Clone incremental restore to a VP Snap source device

Note: With this implementation, the TGT clone may be a thick or thin device. VP Snap devices must always be thin.

Restrictions

A clone incremental restore can be successfully implemented only when the following conditions exist:

All native clone sessions on the source device must be fully copied.

The restore is allowed only when all sessions on the source device are active.

This feature does not support restore to a third device.

Recreate of the virtual sessions are not allowed while the state is restore in progress.

This feature is not supported for TimeFinder/Clone Emulation.


Implementing the feature 1. Verify that the environment is running the appropriate code level.

To invoke this feature, the minimum versions systems must be running are Enginuity 5876 Q4 2012 SR and Solutions Enabler V7.5.0.0.

2. One device group and one text file are created.

a. The device group controls the SRC VP Snap operations.

b. The device file controls the SRC clone operations.

The following graphic depicts the environment setup, including the device IDs used.

Figure 5. Device IDs used for test 2

3. Create a device group using the following command syntax. This device group will be used for the SRC VP Snap operations. symdg create test2-tdevs

4. Add the source device. symld -sid 455 -g test2-tdevs add dev 4df

5. Add two virtual devices (VDEVs). symld -sid 455 -g test2-tdevs addall -range 4eb:4ec -tgt

6. Query the device group. symdg show test2-tdevs


7. Create and activate two TimeFinder/Snap sessions from the SRC device. symclone -sid 455 -g test2-tdevs create DEV001 sym ld TGT001 –nop

symclone -sid 455 -g test2-tdevs activate DEV001 sym ld TGT001 –nop

symclone -sid 455 -g test2-tdevs create DEV001 sym ld TGT002 –nop

symclone -sid 455 -g test2-tdevs activate DEV001 sym ld TGT002 -nop


9. Create a text file that contains a thin SRC device (04DF) and a TGT (04EA) of the same size. These devices will be used for the SRC clone operations.

The sample output of the file test2-SRC-TGT.txt is shown here.

10. Create and activate a differential clone session from the SRC device. This allows users to perform a restore of the clone copy.

symclone -sid 455 -f test2-SRC-TGT.txt create –nop

symclone -sid 455 -f test2-SRC-TGT.txt activate –nop

11. Query the result. symclone –sid 455 –f test2-SRC-TGT.txt query


12. Restore the clone target (in this case, device 4EA). symclone -sid 455 –f test2-SRC-TGT.txt restore –nop


Note: At this point, the incremental restore operations allowed on the clone copy are split, recreate, activate, and terminate.

VP Snap Restore to Target (RTT)

TimeFinder Restore to Target functionality has been enhanced with the Enginuity 5876 2012 Q4 SR. Restore to Target (RTT) allows users to perform an incremental restore from a cascaded clone target to its source. VP Snap Restore to Target permits the cascaded VP Snap to restore data to its source, which is also a clone target. The clone target can then restore back to the clone source.

For devices A B C in a cascaded VP Snap session, where the AB leg is a clone, and the BC leg is a VP Snap session, the following considerations apply:

If the clone leg is in the copied or split state, and the VP Snap leg is in the CopyOnWrite or copied state, a VP Snap incremental restore is allowed.

The VP Snap will be not ready to the user after the restore command is issued. The user can set it to ready if they wish to access the VP Snap while restore is in progress. This is consistent with TF Snap behavior.


If the clone leg is in the copied or split state, and VP Snap leg is in the restored state, an incremental restore of the clone session is allowed.

Once both the clone and the VP Snap sessions are restored, the only operation allowed which will allow the sessions to remain intact is terminate of the VP Snap restored session. The clone restored session can then be split and recreated.

The sessions can also be completely terminated in any order from the restored state.

The following graphic depicts TimeFinder Restore to Target functionality.

Figure 6. VP Snap restore to target (RTT)

Note: With this implementation, all devices must be thin.

Restrictions

VP Snap Restore to Target can be successfully implemented only when the following conditions exist.

VP Snap restore is not allowed if the clone session is not active.

Cascading from TimeFinder/Clone Emulation targets is not supported.

Implementing the feature 1. Verify the test environment.

The minimum versions systems must be running are Enginuity 5876 (Q4 2012 SR) and Solutions Enabler V7.5.0.0.

2. One device file and one device group are created. a. The device file controls the SRC TGT clone operations.


b. The device group controls the B device (TGT) VP Snap operations.

The following graphic depicts the environment setup, including the device IDs used.

Figure 7. Device IDs used for RTT

3. Create a text file that contains the SRC device (04DF) and a TGT (04EA) of the same size. a. The sample output of the file test3-SRC-TGT.txt is shown here.

4. Create a device group using the following command syntax. The devices contained within the device group will be used for the TGT VP Snap operations. symdg create test3-vpsnap

a. Add the source device. symld -sid 455 -g test3-vpsnap add dev 4EA

b. Add two virtual devices (VDEVs). symld -sid 455 -g test3-vpsnap addall -range 4EB:4EC -tgt

c. Query the device group. symdg show test3-vpsnap


5. Create and activate a differential clone session from the SRC device. This allows users to perform a restore of the VP Snap sessions. symclone -sid 455 -f test3-SRC-TGT.txt create –nop

Note: By default, a differential session was created. The –diff need not be specified.

symclone -sid 455 -f test3-SRC-TGT.txt activate –nop

6. Query the result. a. Review the clone session attributes based on the legend. symclone –sid 455 list

7. Create and activate the cascaded TimeFinder/VP Snap sessions from the TGT device 4EA. symclone -sid 455 -g test3-vpsnap create -vse DEV001 sym ld TGT001

symclone -sid 455 -g test3-vpsnap activate DEV001 sym ld TGT001

symclone -sid 455 -g test3-vpsnap create -vse DEV001 sym ld TGT002

symclone -sid 455 -g test3-vpsnap activate DEV001 sym ld TGT002

8. Query the result again.


Note: At this point, the A B leg should be running an active TimeFinder/Clone session, and the B C leg should be running two VP sessions from the active TGT device 4EA.

9. Restore the first snap session by issuing the following command. symclone –sid 455 –g test3-vpsnap restore DEV001 sym ld TGT001 –nop


11. Once a restore operation is in progress (or has completed), users can import the volume group and mount the file system.

12. If an attempt is made to restore any other VP Snap session, the task will fail until the restored session is terminated first.


13. The following command terminates the DEV001/TGT001 restore session, but it does not affect its copy session. symclone -sid 455 -g test3-vpsnap terminate -restored DEV001 sym ld

TGT001

Note: At this point, TimeFinder provides the ability to restore from the clone target to its source. The restore operation can be performed before or after the terminate –restored of the VP Snap leg.



Conclusion

TimeFinder VP Snap allows multiple target sessions to share allocations within a thin pool, thus reducing the storage required for saved tracks. VP Snap is conceptually similar to the use of TimeFinder/Snap. It works only with thin devices and is invoked by the SYMCLI symclone command syntax. VP Snap allows a maximum of 32 sessions on a source device. This is in addition to the maximum of 16 traditional sessions (TimeFinder/Snap, TimeFinder/Clone, and TimeFinder/Clone Emulation). Thus a source device may have as many as 48 total sessions.

Additional enhancements for this feature-set allow for quick differential refreshes from the source volume to a primary clone that has cascaded VP Snap sessions. This provides more efficiency for users who need to create periodic cascaded backups. Test and development projects and applications continue unaffected while the primary clone is refreshed.

VP Snap is easy to manage and combines the benefits of both full-copy clone and space-saving snap technologies.

References

Reference information and product documentation can be found at support.EMC.com including;

EMC Symmetrix TimeFinder Product Guide

EMC Solutions Enabler Symmetrix TimeFinder Family CLI Product Guide

EMC Symmetrix TimeFinder for VMAXe Product Guide

http://www.iometer.org

timefinder vp snap local repl wp

Documents