The backup component of the Tivoli Storage Manager system supports several versions of named objects that are stored on the server.
Any object backed up to the server that has the same name as an object that is already stored on the server from that client is subject to version control. Objects are considered to be in active or inactive states on the server. The latest copy of an object on the server that has not been deactivated is in the active state. Any other object with the same name, whether it is an older version or a deactivated copy, is considered inactive. Management class constructs define different management criteria. They are assigned to active and inactive objects on the server.
| Field | Description |
|---|---|
| VEREXISTS | The number of inactive versions if active versions exist. |
| VERDELETED | The number of inactive versions if active versions do not exist. |
| RETEXTRA | The number of days to keep inactive versions. |
| RETONLY | The number of days to keep the last inactive versions if active versions do not exist. |
If backup versions each have a unique name, such as using a time stamp in the name, then versioning does not happen automatically: every object is active. Active objects never expire, so an application would be responsible for deactivating these with the dsmDeleteObj call. In this situation, the application would need the deactivated objects to expire as soon as possible. The user would define a backup copy group with VERDELETED=0 and RETONLY=0.
The archive component of the Tivoli Storage Manager system permits objects to be stored on the server with retention or expiration period controls instead of version control. Each object stored is unique, even though its name might be the same as an object already archived. Archive objects have a description field associated with the metadata that can be used during query to identify a specific object.
Every object on a Tivoli Storage Manager server is assigned a unique object ID. The persistence of the original value is not guaranteed during the life of an object (specifically, after an export or import). Therefore, an application should not query and save the original object ID for use on later restores. Rather, an application should save the object name and insert date. You can use this information during a restore to query objects and verify the insert date. Then, the current object ID can be used to restore the object.