Tivoli® Storage Manager policy determines how Data Protection for Exchange backups are managed on Tivoli Storage Manager storage and on local shadow volumes when the environment is configured for VSS operations.
The Tivoli Storage Manager server recognizes Data Protection for Exchange as a node. Data that is backed up to Tivoli Storage Manager storage from this Data Protection for Exchange node is stored and managed according to settings that are specified for Tivoli Storage Manager server policy items.
Tivoli Storage Manager policy can manage the VSS backups that are placed in Tivoli Storage Manager server storage pools. The Tivoli Storage Manager server manages VSS backups.
If you use IBM Tivoli Storage Manager for Copy Services and upgrade to Data Protection for Exchange, with the license for Tivoli Storage Manager for Copy Services, you can store VSS backups to local shadow volumes.
The number of local backup versions that are maintained by the Tivoli Storage Manager server is determined by the value that is specified by the Tivoli Storage Manager server verexists parameter, which is defined in the copy group of the management class to which the local backup belongs. Allocation of target volume sets is not necessary when you use the system provider. When you do not use the system provider, the number of target volume sets that are allocated for local backups must be equal to the verexists parameter. Target volume sets are not applicable to XIV®.
For example, if verexists=3, then at least three sets of target volumes must be allocated for the backup to complete successfully. If only two sets of target volumes are allocated, the third and subsequent backup attempts fail. If more sets of target volumes exist than the number specified by the verexists parameter, these sets are ignored by the Tivoli Storage Manager server. A high number of local backup versions cannot be stored. If you want to have N number of local backup versions, set the verexists parameter to N + 1.
When you use the configuration wizard in the GUI, the VSSPOLICY parameter that must be configured in the tdpexc.cfg file.
Depending on the policy management settings, LUNs can also be reused for new backups. When a new backup is requested and the maximum number of versions is reached, the software deletes the oldest snapshot (backup) to make space for the new snapshot. If the new request fails after the oldest snapshot is deleted, you have one less backup version than expected.
Policy management of local backups is required to reconcile the local backup repository with the information that is stored on the Tivoli Storage Manager server. For example, if target volume LUNs that are used for a local backup are removed from the storage subsystem, the information that represents the backup on the Tivoli Storage Manager server must be reconciled. Similarly, if the Tivoli Storage Manager server policy determines that a local backup copy is no longer needed, the local backup manager must free the target volume LUNs to the storage subsystem. The release of the local backup manager is necessary so that these LUNs can be used for future backup operations. Tivoli Storage Manager automatically detects when these situations occur and completes the reconciliation.
Consider the scenario where you use a two-member DAG, named MEMBER1 and MEMBER2. When you complete a backup to LOCAL on MEMBER1 and complete more backups on MEMBER2, the backups to LOCAL on MEMBER1 do not expire until the next time you complete a backup, query, or deletion operation on MEMBER1. In this scenario, you might use more storage than specified by verexists.
Tivoli Storage Manager requires that sufficient storage space is available to create shadow volumes for VSS backup processing. Even when the VSS backup destination is the Tivoli Storage Manager server, storage space to create a shadow volume is still required, but only on a temporary basis.
The value of the verexists parameter that is specified for your local backup policy determines the number of backup versions to retain on local shadow volumes. Therefore, a verexists=1 setting causes the existing backup to be deleted on local shadow volumes (during a VSS backup to Tivoli Storage Manager server storage) to create enough temporary space for the new snapshot. Therefore, if you want to keep N backups on local shadow volumes and you also do VSS backups to Tivoli Storage Manager server storage, provision enough storage space on local shadow volumes and specify verexists=N+1.
If you keep only one backup, the same disk is reused. The process initially removes the existing backup and attempts the new backup. If the new backup fails, no backups exist.
If you retain multiple backups (snapshots), the oldest backup is removed before a new backup is created. If the new backup fails, you might have one less backup than specified by the policy. For example, if you specify to retain five backups, but the latest backup fails, you might have only four backup versions.
Make sure to specify a verexists value that accommodates your VSS backup goals. If you have limited storage space for VSS operations and are restricted to a verexists=1 setting, you can use the Backup DestinationBOTH option. This option stores the backup on local shadow volumes and sends a copy to Tivoli Storage Manager server storage.
VSS backups (that Data Protection for Exchange creates and stores on local shadow volumes) can be changed and deleted from outside of Tivoli Storage Manager control. For example, issue the Microsoft VSSADMIN DELETE SHADOWS command to remove a VSS backup that is managed by Tivoli Storage Manager. Tivoli Storage Manager is not able to prevent the removal of the backup. In such a situation, Tivoli Storage Manager detects that the backup is removed and reconciles its index of available backups with what is on local shadow volumes. Because backups can be removed, it important for you to establish a strategy that protects VSS backup data that is stored on local shadow volumes from being compromised.