Administrator's Guide


Backing Up the Database

Backing up the database is a simple operation. You can backup the database with full and incremental backups or by taking a snapshot of a specific point-in-time of the database; these are called snapshot database backups. (See Doing Full and Incremental Backups and Doing Snapshot Database Backups for more information.) Before your first backup, you must do some or all of the following steps:

To restore your database, you should have copies of the following information:



Figure AB0CT203 not displayed.

DRM helps you save the previously listed information.

 

Defining Device Classes for Backups

You can use existing device classes for backups or define new ones. You can also specify different device classes for incremental backups and for full backups. For example, you might want to write full backups to tape and incremental backups to disk. Specifying a device class with a device type of FILE is useful if an incremental backup is run based on a database backup trigger. You should do this only if you are also backing up the files to tape and taking them off site. Otherwise, in a disaster you can only restore the full backup.

You can also reserve a device class and, therefore, a device for automatic backups only. In this way, TSM does not try to back up the database with no device available. If a database backup, shares a device class with a low priority operation, such as reclamation, and all the devices are in use, TSM automatically cancels the lower priority operation. This frees a device for the database backup.

Note:Device class definitions are saved in the device configuration files (see Saving the Device Configuration File).

Setting the Recovery Log Mode

You can set the recovery log mode to either normal or roll-forward. See Database Backup for a description of the two modes and for a comparison their benefits and costs.

If you do not set the recovery log mode, TSM runs in normal mode. To set the log mode to roll-forward, enter:

set logmode rollforward
Note:The log mode is not in roll-forward mode until you perform the first full database backup after entering this command.

To set the log mode back to normal, enter:

set logmode normal

Scheduling Database Backups

Database backups require devices, media, and time. Consider scheduling backups to occur at certain times of the day and after activities such as the following:

Depending on the frequency of these activities and the amount of client data, you might back up your storage pools daily and then immediately back up the database.

Consider the following when you decide what kind of backups to do and when to do them:

Estimating the Size of the Recovery Log

The number of TSM transactions affect how large you should make your recovery log. As you add more clients and increase concurrent transactions, you can extend the size of the log. In roll-forward mode you should also consider how often you perform database backups. In this mode, the recovery log keeps all transactions since the last database backup and typically requires much more space than normal mode does.

To determine the size that the recovery log should be in roll-forward mode, you must know how much recovery log space is used between database backups. For example, if you perform daily incremental backups, check your daily usage over a period of time. You can use the following procedure to make your estimate:

  1. Set the log mode to normal. In this way you are less likely to exceed your log space if your initial setting is too low for roll-forward mode.

  2. After a scheduled database backup, reset the statistic on the amount of recovery log space used since the last reset:

    reset logconsumption
    

  3. Just before the next scheduled database backup, display the current recovery log statistics:
    query log format=detailed
    

    Record the Cumulative Consumption value, which shows the space, in megabytes, used since the statistic was last reset.

  4. Repeat steps 2 and 3 for at least one week.

  5. Increase the highest cumulative consumption value by 30 percent. Set your recovery log size to this increased value to account for periods of unusually high activity.

    For example, over a period of a week the highest cumulative consumption value was 500MB. If you set your recovery log to 650MB, you should have enough space between daily backups.

For information on how to adjust the recovery log size, see Increasing the Size of the Database or Recovery Log or Decreasing the Size of the Database or Recovery Log.

Note:If the recovery log runs out of space, you may not be able to start the server for normal operation. You can create an additional recovery log volume if needed to start the server and perform a database backup. For example, to create a 5MB volume A00, issue the following command:
  dsmserv extend log a00 5mb

Specify volume sizes in multiples of 4MB plus 1 MB for overhead.

Automating Database Backups

In roll-forward mode, you can set a database backup to occur automatically when the recovery log utilization reaches a defined percentage. TSM also automatically deletes any unnecessary recovery log records. You might want to automate database backups if you have scheduled database backups but the recovery log could grow faster than expected. You should still try to coordinate the recovery log size and scheduled backups. A database backup has a higher priority than most operations, and backup based on a trigger could occur during high server activity and affect your other operations. Adjust the recovery log size to avoid triggering back ups at non-scheduled times.

By setting a database backup trigger you ensure that the recovery log does not run out of space before the next backup.

If the log mode is changed from normal to roll-forward, the next database backup must be a full backup. If a database backup trigger is defined when you set the log mode to roll-forward, the full backup is done automatically. The server does not start saving log records for roll-forward recovery until this full backup completes successfully.

In Estimating the Size of the Recovery Log you determined the size of your recovery log. Your database backup trigger should be based on that procedure. For example, assume that your recovery log size is 650MB. Assume also that its utilization percentage is usually less than 500MB between database backups. You want to trigger a backup only in unusual circumstances. Therefore, set the trigger to at least 75 percent (approximately 500MB). To set the trigger to 75 percent and run 20 incremental backups to every full backup, enter:

define dbbackuptrigger logfullpct=75 devclass=tapeclass
 numincremental=20

Each incremental backup, whether automatic or by command, is added to the count of incremental backups. Each full backup, whether automatic or by command, resets the count for incremental backups to 0. If you specify a NUMINCREMENTAL value of 0, TSM automatically runs only full backups.

Note:If you issue a BACKUP DB command with the TYPE=INCREMENTAL parameter, TSM performs an incremental backup of the database regardless of the NUMINCREMENTAL setting. For example, you set NUMINCREMENTAL to 5, and there have been five incremental backups since the last full backup. If you then issue BACKUP DB TYPE=INCREMENTAL, an incremental backup is still done, and the incremental backup counter is set to 6. This occurs if the BACKUP DB command is issued either by an administrator or through an administrative schedule.

After you set the database backup trigger, you might find that automatic backups occur too often. Check the backup trigger percentage by entering:

query dbbackuptrigger

TSM displays the following information:

+--------------------------------------------------------------------------------+
|             Full Device Class: TAPECLASS                                       |
|      Incremental Device Class: TAPECLASS                                       |
|           Log Full Percentage: 75                                              |
|    Incrementals Between Fulls: 6                                               |
|Last Update by (administrator): SERVER_CONSOLE                                  |
|         Last Update Date/Time: 03/06/1996 10:49:23                             |
+--------------------------------------------------------------------------------+

This information shows that the trigger is set to 75 percent. If automatic backups are occurring too often, you could increase the value to 80 percent by entering:

update dbbackuptrigger logfullpct=80

If the database backup trigger automatically runs backups more often than you want and the setting is high (for example, 90 percent or higher), you should probably increase the recovery log size. If you no longer want to use the database backup trigger, enter:

delete dbbackuptrigger

After you delete the database backup trigger, TSM no longer runs automatic database backups.

Note:If you delete the trigger and stay in roll-forward mode, transactions fail when the log fills. Therefore, you should change the log mode to normal. Remember, however, that normal mode does not let you perform roll-forward recovery. Increase the recovey log size if you want roll-forward recovery.

Saving the Volume History File

TSM stores the following volume information in the database:

TSM updates the volume history file as volumes are added. However, you must periodically run a delete operation to discard outdated information about volumes (see Deleting Volume History Information for details).

This information is stored in the database, but during a database restore, it is not available from there. To perform a restore, therefore, TSM must get the information from the volume history file.

To ensure the availability of volume history information, do any of the following:



Figure AB0CT203 not displayed.

DRM saves a copy of the volume history file in its disaster recovery plan file.

 

Note:You can recover the database without a volume history file. However, because you must examine every volume that may contain database backup information, this is a time-consuming and error-prone task.

The VOLUMEHISTORY server option lets you specify backup volume history files. Then, whenever TSM updates volume information in the database, it also updates the same information in the backup files.

You can also back up the volume history information at any time, by entering:

backup volhistory
If you do not specify file names, TSM backs up the volume history information to all files specified with the VOLUMEHISTORY server option.

If your system does not let TSM dynamically allocate a particular data set name, either choose another name or pre-allocate and catalog the data set. The data set attributes for pre-allocation are:

Record format
VB

Logical record length
1028

Block size
6144

The space required depends on your system. Be aware that a volume history data set can grow.

Deleting Volume History Information

You should periodically delete outdated information from the volume history file. For example, if you keep backups for seven days, information older than that is not needed. When information about database backup volumes or export volumes is deleted, the volumes return to scratch status. For scratch volumes of device type FILE, the files are deleted. When information about storage pools volumes is deleted, the volumes themselves are not affected.

To display volume history information up to yesterday, enter:

query volhistory enddate=today-1

To delete information that is seven days old or older, enter:

delete volhistory todate=today-8

Notes:

  1. Existing volume history files are not automatically updated with this command.

  2. Do not delete sequential volume history information until you no longer need that information. For example, do not delete dump volume information or storage volume reuse information, unless you have backed up or dumped the database at a later time than that specified for the delete operation.

  3. Do not delete the volume history information for database dump, database backup, or export volumes that reside in automated libraries, unless you want to return the volumes to scratch status. 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 reside in automated libraries. These volumes are then available for reuse by the server and the information stored on them may be overwritten when the server reuses the volume for some other purpose, such as storage pool volumes or other database backups.


Figure AB0CT203 not displayed.

DRM expires database backup series and deletes the volume history entries.

 

Saving the Device Configuration File

The device configuration file contains information needed to read backup data. This information includes the following:

Whenever TSM updates device configuration information in the database, it updates the device configuration file.

This information is stored in the database, but during a database restore, it is not available from there. To perform a restore, therefore, TSM must get the information from the device configuration file.

To ensure the availability of the device configuration information, you can do any of the following:



Figure AB0CT203 not displayed.

DRM saves a copy of the device configuration file in its disaster recovery plan file.

 

The DEVCONFIG server option lets you specify backup device configuration files (for details, see the Administrator's Reference). After the server is restarted, whenever TSM updates device configuration information in the database, it also updates the same information in the backup files.

During a database restore operation, TSM tries to open the first device configuration file. If it cannot open or read that file, TSM tries to use any remaining device configuration files (in the order in which they occur in the server options) until it finds one that is usable. If none can be found, you must recreate the file. See Recreating a Device Configuration File for details. After the database has been restored, you may have to update the device configuration.

You can also back up the device configuration information at any time, by entering:

backup devconfig

If you do not specify file names, TSM backs up the device configuration file to all files specified with the DEVCONFIG server option.

If your system does not let TSM dynamically allocate a particular data set name, either choose another name or pre-allocate and catalog the data set. The data set attributes for pre-allocation are:

Record format
VB

Logical record length
1028

Block size
6144

The space required depends on your system.

If you lose your device configuration file and need it to restore the database, you must recreate it manually. See Recreating a Device Configuration File for details.

For virtual volumes, the device configuration file stores the password (in encrypted form) for connecting to the remote server. If you regressed the server to an earlier point-in-time, this password may not match what the remote server expects. In this case, manually set the password in the device configuration file. Then ensure that the password on the remote server matches the password in the device configuration file.

Note:You set the password in clear text. After the server is operational again, you can issue a BACKUP DEVCONFIG command to store the password in encrypted form.

Updating the Device Configuration File

Whenever you define, update, or delete device configuration information in the database, TSM automatically updates the device configuration file. This information includes definitions for device classes, libraries, drives, and servers.

If a disaster occurs, you may have to restore TSM by using devices other than those that are included in the device configuration file. In such a case, you will have to update the device configuration files manually with information about the new devices. See Recreating a Device Configuration File for details.

Recreating a Device Configuration File

The following commands read and execute the device configuration file:

Note: The DSMSERV LOADDB utility may increase the size of the database. The server packs data in pages in the order in which they are inserted. The DSMSERV DUMPDB utility does not preserve that order. Therefore, page packing is not optimized, and the database may require additional space.

If no device configuration file is found, you must recreate it before you can start the restore operation. The device configuration file must follow these conventions:

The following figure shows an example of a device configuration file:



/* Tivoli Storage Manager Device Configuration */
define devclass tapeclass devtype=cartridge

Doing Full and Incremental Backups

The first backup of your database must be a full backup. You can run up to 32 incremental backups between full backups.

To perform a full backup of your database to the TAPECLASS device class, enter:

backup db type=full devclass=tapeclass

In this example, TSM writes the backup data to scratch volumes. You can also specify volumes by name. After a full backup, you can perform incremental backups, which copy only the changes to the database since the previous backup.

To do an incremental backup of the database to the TAPECLASS device class, enter:

backup db type=incremental devclass=tapeclass

Doing Snapshot Database Backups

A snapshot database backup is a full database backup that does not interrupt the current full and incremental backup series. Snapshot database tapes can then be taken off-site for recovery purposes and therefore kept separate from the normal full and incremental backup tapes. The snapshot database backups enhance the protection of your server and its data while maintaining the full and incremental database backup series. While snapshot database backups cannot restore a database or a database volume to its most current state, you can use them to restore a database to a specific point-in-time.

Snapshot database backups:

Use the BACKUP DB command to perform a snapshot database backup. New volume history entries are created for the snapshot database volumes.

To perform a snapshot database backup to the TAPECLASS device class, enter:

backup db type=dbsnapshot devclass=tapeclass
Note:Snapshot database backups should be used as an adjunct to the full and incremental backups. When the server is in roll-forward mode, and a snapshot database backup is performed, the recovery log keeps growing.

When full and incremental backups are performed with roll-forward mode enabled, the recovery log is restarted each time a full backup is performed.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]