Snapshot Copy uses the log-structured-file architecture of the V2X, which means that it does not require the full amount of allocated space to establish a snap shot copy.
With most other storage implementations, configuring a virtual disk sets
up a fixed relationship between the apparent data blocks on the virtual
disk, and the real data blocks in the real disks. A V2X subsystem does
not define a fixed relationship, the location of the data changes every
time it is written out. This means that a V2X never overwrites existing
data but always stores changed data in a new location.
When a Snapshot Copy of a disk is created, a new set of pointers are created from the virtual index to the real disk. This does not require any space for the 'copy data', just a small amount of space for the new pointers. When the original data is updated, as it is written out to a new location there is no need to copy the old data first. At this point, the snapshot starts to occupy space, as the old data must be retained for the snapshot.
Up to four snapshots can be made of the original volume.
PPRC Snapshot
If you are mirroring your disk subsystems between sites using power PPRC (z/OS) or Open PPRC (Open Systems), then it was not possible to snap to a volume which was part of a PPRC pair. You either had to snap to a non-PPRC volume then mirror it, or suspend mirroring before the snapshot could proceed. PPRC snapshot allows you to create a mirrored snapshot of a volume, without having to do this.
The STK terminology for PPRC and Snapshot volumes is Primary and Secondary for PPRC, and Source and Target for Snapshot. To use PPRC Snapshot, you need Source and Target volumes on your primary V2X, which must be mirrored to Source and Target volumes on the secondary V2X. When PPRC Snapshot is invoked, it snaps both target volumes at the same point in time, but does not copy the data over the PPRC link. It simply snaps from both Source volumes, which are already in a PPRC relationship.
PPRC Snapshot will only allow a SNAP command issued to primary PPRC volumes to proceed, if it detects that both secondary volumes are in the same V2X. It also requires that PPRC-SNP, Snapshot and PowerPPRC-002 is installed on both controllers.
SNAP-TO-PRIMARY
Snap-to-Primary basically works by having a pair of PPRC mirrored volumes defined, and reserved as snapshot targets. When a point in time copy at the remote site is required, A Source volume (PP1) at the production site is snapped to the Primary PPRC volume (PS1) at the production site. The data is then copied over to the backup site by the Power PPRC mirroring to the PPRC Secondary (SS1).
Once the copy is complete, the data can then be snapped again at the backup site to another volume (ST1), and kept as a point-in-time copy, where the Point Of Consistency is the time of the original snapshot. The original Source volume PP1 can be snapped again, and then only data which was changed on the source since the first snap will be copied to the remote site. This can be snapped again at the secondary site to create a second POC copy (ST2). This sounds expensive in terms of disk use, but it will probably not be as each POC snap will only store a subset of the data. Of course the original source volume can be part of a PowerPPRC mirrored pair which provides synchronous mirroring to protect from site failure, while the POC snaps protect from data corruption. You will also preserve at least one consistent copy of the data at all times.
Basically,the difference between PPRC SnapShot and a Snap-to-Primary operation is that with PPRC SnapShot, no data is copied over the link. With Snap-to-Primary, data snapped to the primary is PPPC copied over to the secondary.
