Tivoli Storage FlashCopy Manager with SAN Volume Controller and Storwize V7000

Tivoli® Storage FlashCopy® Manager exploitation of SAN Volume Controller and Storwize® V7000 FlashCopy capabilities on Windows are dependent on the Volume Shadow Copy Service (VSS) hardware provider for SAN Volume Controller and Storwize V7000.

Configuration of the VSS provider for SAN Volume Controller and Storwize V7000 controls what type of FlashCopy is run when a VSS snapshot is requested. It also controls the behavior that results when you use VSS snapshots.

The VSS provider that supports SAN Volume Controller and Storwize V7000 has the following characteristics:

• If the VSS provider is configured to use incremental FlashCopy, only one backup version is allowed. Only one backup version is the limit because each VSS snapshot request for a source volume causes an incremental refresh of the same target volume.

  In this scenario, deleting the VSS snapshot removes it from the VSS inventory, but the FlashCopy relationship remains with the SAN Volume Controller and Storwize V7000. A subsequent VSS snapshot of the same source volume results in an incremental refresh of the target volume.

• When the VSS provider is configured to use space-efficient target volumes - specifically, when the background copy rate is set to zero - the following is true:

  • The deletion of a VSS snapshot, that is represented by a target volume in a cascade, also causes all target volumes that are dependent on the volume that is being deleted (that is, the target volumes that were created earlier) to be deleted. For example, the deletion of a snapshot that is represented by target volume T2 in the sample cascade S -> T4 -> T3 -> T2 -> T1 causes T2 and T1 to be deleted. The cascade S -> T4 -> T3 remains after the deletion.

    When you manually delete backups on the SAN Volume Controller and Storwize V7000 space-efficient target volumes, and multiple backup versions exist, the backup that is being deleted, and any older backups that contain the same volumes are deleted. The deletion might not occur until the next snapshot operation.

  • A FlashCopy restore of the source volume from a target volume in a cascade of multiple target volumes is destructive to the target volume that is being restored and to all newer targets in the cascade. For example, the restore of a snapshot that is represented by target volume T3 in the sample cascade S -> T4 -> T3 -> T2 -> T1 causes T4 and T3 to be deleted. The cascade S -> T2 -> T1 remains after the restore.

    One exception to this pattern is that a FlashCopy restore from an space-efficient target that is the only target in the cascade is not destructive.

  • If an space-efficient target volume runs out of space to hold the data from changed blocks on the source volume, that target volume and all target volumes that are dependent on that target volume go offline and render those backup versions unusable.

A space-efficient backup version is defined by a FlashCopy to an space-efficient target volume that has a background copy rate of zero. The use of space-efficient target volumes with the autoexpand option that is enabled and a background copy rate set to greater than zero does not create space-efficient backup versions. The target volumes grow to the allocated size of the source volumes when the background copy completes.

Given these characteristics, the following requirements apply to Tivoli Storage FlashCopy Manager support of SAN Volume Controller and Storwize V7000:

• Using a mix of space-efficient and fully allocated target volumes is not supported. You must choose to use either space-efficient or fully allocated volumes for FlashCopy targets, and set the VSS provider background copy rate parameter.

  A transition from fully allocated targets to space-efficient targets is accommodated by treating fully allocated targets as if they were space-efficient when the background copy rate is set to 0.

• When you use space-efficient backup versions:

  • Do not mix persistent and nonpersistent VSS snapshots. Use of a nonpersistent VSS snapshot that follows one or more persistent snapshots causes the older persistent snapshots to be deleted when the nonpersistent snapshot is deleted.

    A VSS backup with backupdestination set to TSM creates a nonpersistent VSS snapshot. Therefore, do not follow a series of backups to local with backupdestination set to TSM. Instead, set backupdestination to both to send data to Tivoli Storage Manager while it preserves local snapshot backup versions. The settings backupdestination=LOCAL and backupdestination=TSM are mutually exclusive. Do not use both in a backup strategy.

  • Enable autoexpand for the space-efficient target volumes to avoid out-of-space conditions.
  • Allocate enough space for space-efficient target volumes to hold 120 percent of the data that is expected to change on the source volume in the time between snapshots. For example, if a database changes at a rate of 20 percent per day, VSS backups are done every six hours, and a steady rate of change throughout the day is assumed, the expected change rate between snapshots is 5 percent of the source volume (20/4). Therefore, the allocated space for the space-efficient target volumes is to be 1.2 times 5 percent equal to 6 percent of the source volume size. If the rate of change is not consistent throughout the day, allocate enough space to the target volumes to accommodate the highest expected change rate for the period between snapshots.
  • Do not delete snapshots manually. Allow Tivoli Storage FlashCopy Manager to delete backup versions that are based on the defined policy to ensure that deletion is done in the correct order. This process avoids deletion of more backup versions than expected.