Managing Tivoli Storage Manager data objects

When a data object is sent, the Tivoli Storage Manager server places the copy of the client data out on Tivoli Storage Manager pre-allocated storage (in a storage pool) and records information in its own internal database describing the object. This description includes such things as the node name, filespace name, high level qualifier, low level qualifier, and

management class. This information is made available in a Tivoli Storage Manager internal table that can be queried using an SQL select statement.

For backup objects you can run the command select * from backups. For archive objects you use the command select * from archives. Both

commands are run using the Tivoli Storage Manager administrative command line program (dsmadmc) or as a script.

4.3.2.1 Viewing the description of a backup object

Information about each backup object is externalized in a Tivoli Storage Manager database table named backups. You can use a SQL select statement to view the entries in this table. We will restrict the output of the select command by nodename. Before running this command we made a DB2 backup of the sample database using Tivoli Storage Manager.

db2 => backup db sample user db2admin using itsosj use tsm

Backup successful. The timestamp for this backup image is : 20010322134658 db2 =>

After taking the backup we ran the SQL query select * from backups where node_name=’JAMAICA_DB2’. The entry in the quotes is case sensitive and must be upper case. The output of this command tells us that the backup object

was sent by a client program (DB2) that authenticated with the Tivoli Storage Manager server as node JAMAICA_DB2. The client program did not specify which management class to use with this object, so the Tivoli Storage Manager server bound the default management class for the node to this backup object. DB2 uses the database name as the FILESPACE_NAME when sending the object to the Tivoli Storage Manager server. The HL_NAME or high level qualifier corresponds to the DB2 structure

nodegroup. Information on nodegroups and how DB2 is structured can be found in 2.2, “DB2 UDB concepts” on page 13. Our environment consists of single-partition DB2 configurations, so only a single nodegroup exists. For the LL_NAME or low level qualifier, DB2 uses the type of backup concatenated with the timestamp for the backup.

tsm: BRAZIL>select * from backups where node_name='JAMAICA_DB2'

ANR2963W This SQL query may produce a very large result table, or may require a significant amount of time to compute.

LL_NAME: FULL_BACKUP.20010322134658.1 OBJECT_ID: 46908

BACKUP_DATE: 2001-03-22 13:48:42.000000 DEACTIVATE_DATE:

OWNER:

CLASS_NAME: DEFAULT

4.3.2.2 Viewing the description of an archive object

Information about each archive object is externalized in a Tivoli Storage Manager internal database table named archives. You can use an SQL select statement to view the entries in this table. We will restrict the output of the select command by nodename. Before running this command, we configured the DB2 sample database to invoke a user exit that archives logs to Tivoli Storage Manager. After performing this configuration we ran the SQL query select * from archives where node_name=’JAMAICA_DB2’. The entry in the quotes is case sensitive and must be upper case. The output of this

command tells us that the archive object was sent by a client program (DB2) that authenticated with the Tivoli Storage Manager server as node

JAMAICA_DB2. The client program did not specify which management class to use with this object, so the Tivoli Storage Manager server bound the default management class for the node to this archive object. DB2 uses the database name as the FILESPACE_NAME when sending the object to the

corresponds to the DB2 structure nodegroup. Information on nodegroups and how DB2 is structured can be found in 2.2, “DB2 UDB concepts” on page 13.

Our environment consists of single-partition DB2 configurations, so only a single nodegroup exists. For the LL_NAME or low level qualifier, DB2 uses the filename for the log file.

tsm: BRAZIL>select * from archives where node_name='JAMAICA_DB2'

ANR2963W This SQL query may produce a very large result table, or may require a significant amount of time to compute.

DESCRIPTION: Log file for DB2 database SAMPLE CLASS_NAME: DEFAULT

4.3.2.3 Differences between backup and archive objects

Based on the output of the SQL commands for backup and archive objects, you can see that there are some similarities and some differences.

The backups table contains two fields that the archives table does not:

STATE and DEACTIVATE_DATE. These two fields are used in implementing versioning which is specific to backup objects. The STATE field can be either ACTIVE_VERSION or INACTIVE_VERSION. When the backup object is inactivated, the STATE changes to INACTIVE_VERSION and the timestamp when this occurred is placed in the DEACTIVATE_DATE field.

The archives table contains one field that the backups table does not:

DESCRIPTION. The DESCRIPTION field is used to logically group archive objects together. For example, the Tivoli Storage Manager Backup-Archive client GUI uses this field during the retrieve operation to group archive objects that were backed up with similar descriptions.

4.3.2.4 Owner field in backups and archives tables

Both the backups and archives tables have an OWNER field for each data object. This is used for client data sent from a UNIX operating system. For files and directories, the OWNER corresponds to the UNIX security owner for the file or directory. For API data this field normally comes from the UNIX user that is used to perform the backup. Only the owner of the data object or a root user can access data objects on a Tivoli Storage Manager server or

authorize that access to other nodes. The Windows operating system that does not use this field, so in our examples in the prior sections, the OWNER field is blank.

DB2 backups and restores source the OWNER value from the user performing the backup or restore when PASSWORDACCESS is set to GENERATE. When PASSWORDACCESS is set to PROMPT, the OWNER is sourced from the DB2 database configuration parameter, TSM_OWNER.

This plays an important role when doing redirected restores.