Hello,

There are three basic steps for making a Snapshot available to a server:
1)create Snapshot - This is object placed in the server storage group
2)create snapsession - This is the 'point in time' copy
3)activate snapshot - This makes the point in time copy available to the server via the snapshot

So for the initial setup, you can create the Snapshot, place it in a storage group. The Snapshot can remain in the storage group. Then each time you want to present a new point in time copy, you can perform steps 2 and 3.

Once the snapshot is activated and in a storage group, its available for read/write access by the server. Snapshots do not require the MirrorView link to be inactive, however, coordinating snapshots with the proper secondary image state is important.

When you create the snap session, you will want to make sure the MirrorView seconday image(s) is in a synchronized or consistent state. As long as the secondary image is in one of these states you can create the snap session with the mirrorview link either active or inactive(fractured).

If write ordering across several volumes is important in your environment, you can create a consistent snap session across several LUNs. Again, this can be done with the MirrorView link active or inactive.

Or if you want the link to be inactive during your test, you can fracture individual mirrors or consistency groups. If you facture the mirrors/congroups, you can synchronize the mirror/group after your testing for a partial resync. If this is MirrorView/Synchronous, then use of the Write Intent Log(WIL) is recommended. The WIL will protect you from a full resync in the instance of an outage while the mirrors are fractured.

Regards,
Bruce