10.5 Protecting TIvoli Storage Manager Database


You should periodically backup the Tivoli Storage Manager database so that you can you restore the TSM server if there is any disaster in the future. You can use the DB backup to create a new TSM server with the same configuration, for example in a DR site. 

Taking backup of TSM Database

It is a best practice to schedule the TSM DB backup once or twice a day depending on the DB transaction rate of your TSM server. There are 3 types of backups available in TSM
  • DB Full Backup
  • DB Incremental Backup
  • DB Snapshot Backup
It will take a full backup of the Tivoli Storage Manager database. Only a full database backup clears the archive log.

TSM DB Incremental Backup
It will run an incremental backup of the Tivoli Storage Manager database. An incremental (or cumulative) backup image contains a copy of all database data that is changed since the last successful full backup operation. The first backup of your database must be a regular backup. You can run up to 32 incremental backups between regular backups. To effectively use the tape resources you can also run an incremental backup of the database using a FILE device class scratch volume. Assume a device class of FILE for the backup.

TSM DB Snapshot Backup
It will run a full snapshot database backup. The entire contents of a database are copied and a new snapshot database backup is created without interrupting the existing full and incremental backup series for the database.

Preparing TSM Server for taking DB backup in Multiple Streams

Before taking any type TSM DB backup you have to specify the device class name and number of data streams to be used for automatic backups. You have to use the set dbrecovery command from the administrative command line to specify the device class to use for database backups. You can take backup and restore in multiple streams  but each stream requires its own device. You can back up and restore multiple data streams in parallel. For example
set dbrecovery devclassname NUMstreams=1-4

NUMStreams Specifies the number of parallel data movement streams to use when backing up the database. The default value is 1, and the maximum number is 4. Increasing this value causes a corresponding increase in the number of database backup sessions to be used and in the number of drives to be used for the device class. So, you have to make sure that you have enough scratch tapes and tape drive resources available depending on this parameter value. 

Also Read: Take TSM DB backup immediately if you notice these messages

Multiple streams reduce the total time an operation needs. Parallel data stream support reduces the time required to perform a database backup or restore operation. If the number of available drives for a backup or restore operation equals or is greater than the number of streams, the backup is done with the requested number of streams. If fewer drives are available than the stream value, the backup is done with the available drives.

Using multiple data streams requires the use of additional volumes. With multiple streams that are assigned to database backup processing, more volumes might be used and only partially filled, especially if you are using high-capacity physical tape drives. As a best practice for databases less than 100 GB, use 1 stream; for databases 100 GB - 200 GB, use 2 streams and mount points; for databases 200 GB - 300 GB, use 3 streams and mount points; for databases greater than 400 GB, use 4 streams and mount points. However, these values are just suggestion and they should be considered according to the available resources.

If you do not use the set dbrecovery command before the first database backup runs, the backup fails. If you perform a database backup and use a device class other than the one that you specify in the set dbrecovery command, an error message occurs, but the backup still runs and finishes successfully.

How to Backup Tivoli Storage Manager database ?

Tivoli Storage Manager does full plus incremental backups of the database to tape while the server is running and available to clients. You can then store the Tivoli Storage Manager backup media on-site or off-site and use it to recover the database up to the point of the backup. You can run full or incremental backups as often as you need to ensure that you can restore the database to an acceptable point in time. With an intact recovery log, you can recover the database up to its most current status.

Also Read: Increase TSM DB space when server is offline using this DB2 command 

You can schedule the backups, or perform the backups manually. An incremental backup of the database includes all changes since the last full backup. The following command is used to take the TSM DB backup
backup db devc=devclassname type=FULL|INCREMENTAL|SNAPSHOT

Features of TSM DB Full Backup
  • The first database backup is always a full backup.
  • Only full database backups empty the archive log.
  • You can do a combination of full plus incremental backups, one full backup, then up to six incremental backups. You have to ensure the log size is sufficient during those incremental backups because the archive log does not empty after incremental backups.
  • To back up the Tivoli Storage Manager database to sequential media, use the following command
backup db devclass=devclassname type=full

Features of TSM DB Snapshot Backup
A snapshot backup is a full backup that does not interrupt the full plus incremental backup series. It is also referred to as an out-of-band database backup. You can store this backup off-site for disaster recovery purposes. The volume history tracks the database snapshot backup. Use the backup to restore the Tivoli Storage Manager database to the point in time when the snapshot is done. A database snapshot backup does not empty the recovery log. TSM DB Snapshot backup
  • Does not interrupt the normal backup series.
  • Is integrated into Disaster Recovery Manager processing and volume history processing.
  • Can be stored off-site.
  • Full, plus incremental backup series stays on-site for availability.
backup db devclass=devcname type=dbsnapshot



Using shared memory for database backups
You can also use the shared memory communication protocol to reduce processor load and improve throughput, if the database backup performance is slow.
  • SHAREDMEM is only used for communications between clients and servers on the same system. TCP/IP Version 4 must also be installed on the system.
  • Use the SHMPORT option to specify a different TCP/IP port. The default port address is 1510.
  • If shared memory was not configured during the instance configuration, add the following to the dsmserv.opt and the dsm.opt files enable this features
commmethod sharedmem
shmport 1510

There are other additional parameters to customize the TSM DB backup. Check the below syntax, use the appropriate options according to your requirements and situations

TSM backup db command


DEVCLASS=DEVCLASSNAME 
Specifies the name of the sequential access device class to use for the backup. This parameter is required.

Be sure that you use the DEVCONFIG option in the DSMSERV.OPT file to specify an external file to store a backup copy of device class definitions. If you do not have this file and your Tivoli Storage Manager database is damaged or lost and must be restored, the definitions that are created by using the define devclass command are not available and must be recreated manually.

Also Read: How to increase or decrease TSM DB, active log and archive log size ?

TYPE=TYPEVALUE
Specifies the type of backup to run. This parameter is optional. The default value is INCREMENTAL.
VOLUMENAMES=VOLNAME
Specifies the volumes to use for the backup. You can specify more than one volume by separating successive volume names with a comma, with no intervening spaces.
SCRATCH=SCRATCHVALUE
Specifies whether you can use scratch volumes for the backup. This parameter is optional. The default value is YES.
WAIT=WAITVALUE
Specifies whether to wait for the server to complete processing this command in the foreground. The default value is NO.

Useful TSM Database backup-related commands

Query DB
To help you determine how much storage space a regular or incremental backup might require, use the q db command. This command shows the number of changed megabytes in the database. You can also use this command to check the latest TSM DB backup date and time
Query DB Format=Detail

Query Volhistory
Use the q volh type=dbb command to show sequential volume history information on database volumes that the server collects. Volume history information includes data, such as date and time of volumes used in TSM Server
Query VOLHistory type=DBBackup|DBSnapshot|DBDump|EXport|All

How to delete old DB backup volumes

When you take a DB backup on tape volume, that information will be written volume history file. You cannot use the same volume again unless you delete that entry in the volume history file. Use the delete volhistory command to delete sequential volume history information that the server collects when the information is no longer needed. When you delete volume history information about volumes that are not in storage pools, the volumes return to scratch status if Tivoli Storage Manager acquired them as scratch volumes. For scratch volumes with device type FILE, the files are deleted. For example, use the following command to delete all DBsnapshot backups prior to 3 days
delete volhist t=dbs todate=-3

When the delete volhistory command removes volume information for database dump, database backup, or export volumes, the volumes are automatically returned to scratch status if they are in automated libraries. These volumes are then available for reuse by the server. The information stored on them is overwritten when the server reuses the volume for another purpose, such as storage pool volumes or other database backups.

The disaster recovery manager function can manage the volume history file. If you implement the disaster recovery manager function, this step is not necessary.

PREVIOUS: 10.4 Protecting TSM server important configuration files




What Others are Reading Now...

0 Comment to "10.5 Protecting TIvoli Storage Manager Database"

Post a Comment