Thin provisioning support

Edit online

Thin provisioning is used to define a storage unit (full system, storage pool, volume) with a logical capacity size that is larger than the physical capacity assigned to that storage unit. A thin-provisioned volume is typically considered a space-efficient (SE) volume.

With SE volumes, you can retain multiple FlashCopy images of a source volume as backups at a much reduced storage cost. You do not need to allocate the full size of the source volume for each backup that is generated.

General guidelines when using SE volumes

Allocate enough space for space-efficient target volumes to hold 120 % 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 % per day, VSS backups complete every six hours, and a steady rate of change throughout the day is assumed. The expected change rate between snapshots is 5 % of the source volume (20/4). Therefore, the allocated space for the space-efficient target volumes is to be 1.2 times 5 % equal to 6 % 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.
Tip: You can transition your data from fully allocated targets to space-efficient targets by using fully allocated targets as if they are space-efficient when the background copy rate is set to zero.
For SE target volumes, the IBM® SAN Volume Controller and IBM Storwize® V7000 hardware architectures minimize the space that is required to maintain multiple snapshots of the same source volume. Target volumes are placed into a cascade where each target depends on changes that are recorded in target volumes of subsequent snapshots. For example, assume that four VSS snapshots of a source volume are created. S is the source and T1 through T4 are the targets. T1 is the first, chronologically, and T4 is the last. The following cascade occurs: 
S -> T4 -> T3 -> T2 ->
               T1
.

With this type of cascade relationship, a copy-on-write process is needed only between the source volume and the last FlashCopy® target. Any blocks that remain unchanged on the source volume are not copied. To enable cascading FlashCopy mappings, set the IBM VSS provider background copy value to zero by entering the IBMvcfg set background Copy 0 command.

To activate the changes, restart the IBM VSS system service after you enter the command.

Warning: When you use the target volumes as backup versions that are managed by IBM Storage Protect Snapshot, you must carefully consider the cascaded relationship where multiple SE target volumes have the same FlashCopy source. Some operations, for example, restoring or deleting a snapshot, can result in the unexpected removal of targets, and as a result break the cascaded relationship.
  • Delete Example: If T3 was deleted from the chain, then the snapshots that are associated to T2 and T1 would be removed.
  • Restore Example: If T3 was restored, the snapshots that are associated to T3 and any future would be removed.
When using space-efficient target volumes, adhere to the following guidelines to avoid the examples listed above.
  • Do not delete snapshots manually.

    Allow IBM Storage Protect Snapshot to delete backup versions that are based on the defined policy to ensure that deletion occurs in the correct order.

  • If you delete a local snapshot that is stored on a space-efficient volume (SEV) that has multiple dependent targets, delete the snapshots in the same order in which you created them. You must delete the oldest one first, followed by the second oldest.
  • If you perform an instant restore, be aware that the restored versions and newer versions will be removed.
Warning: If FlashCopy mappings are removed from the storage device because of breaks in the cascading FlashCopy mappings chain, the MMC GUI will not reflect those removals immediately.
Some operations, for example, restoring or deleting a snapshot, can result in the unexpected removal of targets, and break the cascaded relationship.
  • Delete Example: If T3 was deleted from the chain, then the snapshots that are associated to T2 and T1 would be removed. (In this case, the backups associated with T2 and T1 would still show in the MMC GUI until they were expired by policy or deleted.)
  • Restore Example: If T3 were restored, then the snapshots that are associated to T3 and any future would be removed. (In this case, the backups associated with T3 and any future would still show in the MMC GUI until the next query operation.)