Configuring a Tivoli Storage Manager client

Before the Db2® database manager can use an IBM® Tivoli® Storage Manager (TSM) client to manage database or table space backup or restore operations, you must configure the TSM environment.

Before you begin

A functioning TSM client and server must be installed and configured. In addition, the TSM client API must be installed on each Db2 database server. TSM client proxy nodes are supported if the TSM server has been configured to support them. For information on server configuration and proxy node support, see Considerations for using Tivoli Storage Manager or refer to the Tivoli documentation.

Note: Tivoli Storage Manager (TSM) Version 7.1.8 and Version 8.1.2 introduce significant enhancements for improved security between client and server communication. When the TSM server is upgraded to Version 7.1.8 (or higher versions) or 8.1.2 (or higher versions) and configured with the improved security protocol, and the TSM backup-archive client is upgraded to Version 7.1.8 (or higher versions) or Version 8.1.2 (or higher versions), the security settings for the backup-archive client must be re-configured to work with the new security enhancements on the server. Failure to re-configure the client may result in a TSM authentication error code 927 or other errors. For details, refer to the New Features and Updates of TSM Version 7.1.8: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/client/r_new_for_version.html, or TSM Version 8.1.2: https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/client/r_new_for_version.html. Please also take care of configuration changes in the following technote: https://www.ibm.com/support/pages/configuration-changes-needed-ibm-spectrum-protect-formerly-tivoli-storage-manager-client-versions-starting-718-and-812

Note: When configuring TSM backup-archive client of version 7.1.8 or version 8.1.2 on Solaris, if you issue API dsmapipw as the instance owner, you might get an error message, which says "Server signon failed: (160) TA not found in its directory". In this case, the workaround is to issue API dsmapipw as a root user and then change the ownership of key files to the instance owner.

Procedure

To configure the TSM environment for use by Db2 database systems:

Set the environment variables used by the TSM client API:

DSMI_DIR

Identifies the user-defined directory path where the API trusted agent file (dsmtca) is located.

DSMI_CONFIG

Identifies the user-defined directory path to the dsm.opt file, which contains the TSM user options. Unlike the other two variables, this variable should contain a fully qualified path and file name.

DSMI_LOG

Identifies the user-defined directory path where the error log (dsierror.log) will be created.

Note: In a multi-partition database environment, these settings must be specified in the sqllib/userprofile file.
If any changes are made to these environment variables and the database manager is running, stop and restart the database manager.
For example:
- Stop the database manager using the db2stop command.
- Start the database manager using the db2start command.
Depending on the server's configuration, a Tivoli client might require a password to interface with a TSM server.
If the TSM environment is configured to use PASSWORDACCESS=generate, the Tivoli client needs to have its password established.

The executable file dsmapipw is installed in the sqllib/adsm directory of the instance owner. This executable allows you to establish and reset the TSM password.
To execute the dsmapipw command, you must be logged in as the local administrator or root user. When this command is executed, you will be prompted for the following information:
- Old password, which is the current password for the TSM node, as recognized by the TSM server. The first time you execute this command, this password will be the one provided by the TSM administrator at the time your node was registered on the TSM server.
- New password, which is the new password for the TSM node, stored at the TSM server. (You will be prompted twice for the new password, to check for input errors.)
Note: Users who invoke the BACKUP DATABASE or RESTORE DATABASE commands do not need to know this password. You only need to run the dsmapipw command to establish a password for the initial connection, and after the password has been reset on the TSM server.

What to do next

Depending on your backup and log archiving strategies, you might need to perform additional steps to configure the TSM clients if you want to use proxy nodes. Proxy nodes enable you to consolidate backups and log archives of databases existing on multiple client nodes or under multiple users to a common target nodename on the TSM server. This configuration is useful when the administrator or computer that performs the backup can change over time, such as with clusters. The asnodename option also allows data to be restored from a different computer or from a user different than the one that performed the backup.

If you want to use TSM in your Db2 pureScale® environment, proxy node configurations are recommended because each member can be represented as a TSM client or node and be mapped to a common proxy node.

If you do not want to use proxy nodes by default, no additional client setup is required. When you want to perform backup or restore operations using proxy nodes, specify the asnodename value in the OPTIONS parameter when invoking the BACKUP DATABASE or RESTORE DATABASE commands.

If you want to use TSM proxy nodes by default, use the following methods:

Update database configuration parameters to use different proxy nodes for different databases.
Update the dsm.sys file to use the same proxy node for all the users and databases on a machine.
Note: Every user-host combination using the same TSM proxy name will appear as the same Db2 instance to TSM. This can mean that if multiple Db2 instances use the same database name in a TSM client-node proxy configuration, then they can potentially overwrite each other's log archives and backup images. To avoid this:
- Create a different proxy hostname for each Db2 instance.
- Do not use TSM's client-node proxy feature if multiple Db2 instances might create databases using the same TSM proxy name.

TSM client setup using vendoropt, logarchopt1, and logarchopt2

You can set one or more of the following database configuration parameters to enable different proxy node settings for each database:

To enable commands using TSM (such as backup and restore) to use proxy nodes, specify the asnodename option in the vendoropt database configuration parameter, as follows:
```
db2 update db cfg for dbname using vendoropt '-asnodename=proxynode'
```
where proxynode is the name of the shared TSM proxy node.
To configure log archiving to the TSM server, set the logarchmeth1 database configuration parameter to TSM and specify the name of the proxy node as the asnodename value in the logarchopt1 database configuration parameter, as follows:
```
db2 update db cfg for dbname using logarchmeth1 tsm 
logarchopt1 '-asnodename=proxynode'
```
where proxynode is the name of the shared TSM proxy node.
You can make similar updates to the logarchmeth2 and logarchopt2 database configuration parameters.

In Db2 pureScale environments, these database configuration parameters are global parameters and you can set them from any member.

TSM client setup method using the dsm.sys file

Edit the dsm.sys file and add the proxy node information, as follows:
```
asnodename proxynode
```
where proxynode is the name of the shared TSM proxy node.
Ensure that the dsm.opt file specified in the DSMI_CONFIG path contains the name of the TSM server, as follows:
```
servername servername
```
where servername is the TSM server name.