Managing volume backups with fast replication

A FlashCopy relationship is established in either COPY or NOCOPY mode. COPY mode results in a background copy which causes all tracks in the FlashCopy relationship to be physically copied from the source volume tracks to the target volume tracks. When the background copy operation completes, the FlashCopy relationship ends. When you define a copy pool with a VERSIONS value of 1 to 85, a COPY mode FlashCopy relationship is established.

NOCOPY mode suppresses the background copy and causes the relationship to be established without immediately initiating a background copy. When the device receives an update to a source track in a FlashCopy relationship, a copy of the point-in-time (pre-update) data is preserved on the target volume. A FlashCopy relationship established in NOCOPY mode remains active until the FlashCopy relationship is withdrawn, or all specified source device tracks or a threshold number of source tracks are updated. When you define a copy pool with a VERSIONS value of 0 (zero), a NOCOPY mode FlashCopy relationship is established.

Incremental FlashCopy provides the capability to refresh a volume in a FlashCopy relationship by copying the changed data only. It reduces background copy time when only a subset of data has changed. An incremental FlashCopy relationship persists until it is withdrawn. DFSMShsm supports incremental FlashCopy in COPY mode.

For more information, see Creating a copy pool incremental version and Recovering from a copy pool incremental version.

DFSMShsm allows the target of the FlashCopy operation to be a Peer-to-Peer Remote Copy (PPRC) primary device. When the tracks associated with the FlashCopy relationship are copied to the PPRC secondary device, the PPRC (Metro Mirror) pair goes into a duplex pending state, to ensure the integrity of the mirror between the local site and the remote site. When the FlashCopy operation completes, the Metro Mirror volume pair returns to full duplex state.

To avoid placing the Metro Mirror pair in an unsynchronized state, IBM® Remote Pair FlashCopy, also known as preserve mirror operation, mirrors the FlashCopy command that is issued at the local site, to the remote site, if proper configuration exists. Preserve mirror operation preserves the Metro Mirror duplex state and at the same time ensures that the Metro Mirror remote site is a true mirror of the local site.

For more information, see Using Metro Mirror primary volume during fast replication backup and Using Metro Mirror primary volume during fast replication recovery.

Space efficient FlashCopy refers to a FlashCopy relationship for which the target volume is a space efficient volume. With space efficient FlashCopy, the amount of physical space consumed by the target volume is limited to the minimum amount of space required to maintain the copy. Space efficient FlashCopy is supported in NOCOPY mode only and cannot be used in combination with preserve mirror operation.

Fast reverse restore provides the capability to reverse the direction of an existing FlashCopy relationship and restore the source volume to the point-in-time state when it was last flashed to the target without waiting for the background copy to complete. Once a fast reverse restore has completed, the contents of the backup volume (the original FlashCopy target) become invalid. When using fast reverse restore, it is best to keep dump tape copies in addition to DASD copies.

DFSMShsm supports fast reverse restore of a copy pool in both COPY and NOCOPY modes. However, fast reverse restore cannot be used in combination with the preserve mirror operation. When the storage subsystem supports cascaded FlashCopy function, the additional FlashCopy targets will not need to be removed prior to attempting fast reverse restore. Ensure the correct backup version is specified on the command you intend to use for fast reverse restore.

For more information, see Recovering a copy pool using fast reverse restore.

When logically related data spans across multiple volumes, FlashCopy consistency group can be used to create consistent copies while minimizing application impact.

To accomplish this, the process consists of freezing the source volumes as each volume pair in the copy pool is copied using FlashCopy, and thawing all the frozen volumes using the Consistency Group Created command after a consistent copy pool backup version has been created. When the FlashCopy freeze option is used, the control unit puts the source volume in an extended long busy (ELB) state causing I/O activities to be held at the host. During the time window starting when the first volume is frozen until the volumes are thawed, no dependent-write updates will take place, which allows a consistent backup version to be created.

The FlashCopy consistency group function can be used in combination with other FlashCopy options.