Life cycle of TSM data objects

Backup data objects and archive data objects are managed differently. We will use the term life cycle to describe how these data objects exist on TSM storage from initial creation to when they are purged.

4.5.4.1 Life cycle of archive data objects

An archive object exists in two states ‘current’ and expired before being purged from the TSM server. Figure 9 shows the three steps involved in the life cycle of an archive data object.

Step 1: A copy of the client data is sent to the TSM server as an archive object. Upon initial creation the archive object is in a ‘current’ state.

Step 2: It remains in a ‘current’ state until the TSM client program deletes the archive object manually, or the archive object exceeds its retention setting. At this point the archive object changes state from current to expired.

Step 3: The archive object remains in the expired state until expiration processing runs on the TSM server. This process is invoked by a TSM

administrator with the expire inventory command. When expiration

processing encounters an archive object in the expired state, it purges that object from the TSM database and frees up the storage space where the archive object resided.

Chapter 4. TSM server considerations 45

Draft Document for Review May 2, 2001 8:03 pm 6249ch03a.fm

When an archive object moves into the expired state, it is no longer accessible by the TSM client. Additionally, there is no way for the archive object to change back to a ‘current’ state once it has become expired. 4.5.4.2 Life cycle of backup data objects

A backup object exists in three states active, inactive, and expired before being purged from the TSM server. Figure 10 shows the four steps involved in the life cycle of a backup data object.

Step 1: A copy of the client data is sent to the TSM server as a backup object. When a backup object is sent to the TSM server, it becomes the active version.

Step 2: It remains in an active state until the TSM client program deletes the backup object manually, or a newer version of the backup object is sent. At this point the backup object changes state from active to inactive.

Step 3: The backup object remains inactive until it exceeds its retention settings. A backup object can exceed retention settings by either time or number of versions. At this point the backup object changes state from inactive to expired.

Step 4: The backup object remains in the expired state until expiration processing runs on the TSM server. This process is invoked by a TSM

administrator with the expire inventory command. When expiration

processing encounters a backup object in the expired state, it purges that object from the TSM database and frees up the storage space where the backup object resided.

6249ch03a.fm Draft Document for Review May 2, 2001 8:03 pm A backup object that is the active version or in the active state will never be purged from TSM storage(never expires). It must first be inactivated by the TSM client program. The TSM client program can do this by manually deleting the backup object or sending a new version of the backup object.

When a backup object becomes inactive or moves into the inactive state, it is still accessible by the TSM client. A main difference between active and inactive is that an active object becomes inactive due to a client operation. An inactive object becomes expired automatically by the TSM server as soon as it exceeds its retention criteria. Changing from inactive to expired does not require a client operation. There is no way for a backup object to change back to the active state once it has become inactive.

When a backup archive object moves into the expired state, it is no longer accessible by the TSM client. Additionally, there is no way for the backup object to change back to the inactive state once it has become expired. If the retention for the backup object is set to retain zero inactive objects(retextra=1,verdel=0) or to retain inactive copies for zero

days(retextra=0, retonly=0), the active backup object will change to the expired state as soon as the active backup is inactivated.

What a unique backup object is to TSM

Both backup and archive objects can be manually deactivated by the client program that initially backed them up. A key difference between backup and archive objects is that a backup object changes states when a newer version of the backup object is sent to the TSM server. This brings up the question how does the TSM determine what a unique version is. A backup object is considered ‘unique’ based on NODE_NAME, FILESPACE_NAME,

HL_NAME, LL_NAME. These fields and how to view them were discussed in Section 4.5.2.1, “Viewing the description of a backup object” on page 37. When a backup data object is sent to the TSM server, if it has the same NODE_NAME, FILESPACE_NAME, HL_NAME, LL_NAME as an existing backup data object. The new data object becomes the ACTIVE_VERSION, and the older version changes state and becomes an INACTIVE_VERSION. Many API products use a unique value for the LL_NAME based on a

timestamp or a random non-recurring value. Because of this unique value for the LL_NAME the backup object will only change states from active to inactive when the API product manually inactivates (deletes) the backup object. An active object is not subject to retention settings until it is

inactivated. You must run the appropriate command from the API product to inactivate these backups objects or else they will remain forever on the TSM server.

Chapter 4. TSM server considerations 47

Draft Document for Review May 2, 2001 8:03 pm 6249ch03a.fm