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 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 is responsible for managing VSS backups.
If you used IBM Tivoli Storage Manager for Copy Services and upgraded 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 that 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 are not using the system provider, the number of target volume sets allocated for local backups is to be equal to the verexists parameter. Target volume sets are not applicable to XIV®.
For example, if verexists=3, then at least 3 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, offered through the graphical user interface, the VSSPOLICY parameter that is to be configured is set 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.
The policy management of local backups is responsible for reconciling the local backup repository with the information stored on the Tivoli Storage Manager server. For example, if target volume LUNs that were 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. Likewise, 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. This release is necessary so that these LUNs can be used for future backup operations. Tivoli Storage Manager automatically detects these situations and does 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 are not expired until the next time you do a backup, query, or deletion operation on MEMBER1. This scenario can lead to using more storage than specified by verexists.
Tivoli Storage Manager requires that sufficient storage space is to be available to create shadow volumes that are required 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, though on a temporary basis.
Because the value of the verexists parameter that is specified for your local backup policy, determine the number of backup versions to retain on local shadow volumes, a verexists=1 setting causes the deletion of an existing backup 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 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, there are no backups.
If you keep 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 that there are to be five retained 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 take advantage of the Backup DestinationBOTH option. This stores the backup on local shadow volumes and sends a copy to Tivoli Storage Manager server storage.
It is possible for VSS backups (that Data Protection for Exchange creates and stores on local shadow volumes) to be changed and deleted from outside of Tivoli Storage Manager control. For example, the Microsoft VSSADMIN DELETE SHADOWS command can remove a VSS backup that are managed by Tivoli Storage Manager without Tivoli Storage Manager being able to prevent such a removal. In such a situation, Tivoli Storage Manager recognizes the backup removal and reconciles its index of available backups with what is on local shadow volumes. Because of this potential for removal, it is important to establish a strategy that protects VSS backup data that is stored on local shadow volumes from being compromised.