Tivoli Header

Administrator's Guide


Backing Up the Database

Backing up the database is a simple operation. You can back up 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 must have copies of (or be able to create) the following information:



DRM Icon

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, the server 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, the lower priority operation is automatically canceled. 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 and Recovery Log Protection for a description of the two modes and for a comparison their benefits and costs.

If you do not set the recovery log mode, the server 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

Estimating the Size of the Recovery Log

The number of 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 by using the following command:

    reset logconsumption
    
  3. Just before the next scheduled database backup, display the current recovery log statistics by using the following command:
    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 1MB for overhead.

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:

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. The server also automatically deletes any unnecessary recovery log records. You might want to automate database backups if you have scheduled database backups. However, while the newly automated database backups are occurring, the recovery log could grow faster than expected. You should 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 backups 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.

By doing the steps 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, the server automatically runs only full backups.

Note:
If you issue a BACKUP DB command with the TYPE=INCREMENTAL parameter, the server 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

The following information is displayed:

+--------------------------------------------------------------------------------+
|             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, the server 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 recovery log size if you want roll-forward recovery.

Saving the Volume History File

Volume history information is stored in the database, but during a database restore, it is not available from there. To perform a restore, therefore, the server must get the information from the volume history file. It is very important to save your volume history file so that you do not have to manually examine every volume.

The following volume information is stored in the database:

The server 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).

To ensure the availability of volume history information, it is extremely important to do one of the following:



DRM Icon

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 the server updates volume information in the database, it also updates the same information in the backup files.

Note:
When you install Tivoli Storage Manager, a default VOLUMEHISTORY option in the server options file specifies a volume history backup file named volhist.out.

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

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

In order to ensure updates are complete before the server is halted, we recommend you:

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 type=all todate=today-8

Notes:

  1. Existing volume history files are not automatically updated with the DELETE VOLHISTORY 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 such volumes, they automatically return to scratch status. The volumes are then available for reuse by the server and the information stored on them may be overwritten.


DRM Icon

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

 

Saving the Device Configuration File

Make a copy of your device configuration file and save it.

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

This information is stored in the database, but during a database restore, it is not available from there. To perform a restore, therefore, the server must get the information from the device configuration file. When device information is updated in the database, it is also updated in the device configuration file. The device information must match the devices configured on the system where the restore will be performed. You may have to edit those commands in an existing file so that they match.

To ensure the availability of the device configuration information, it is extremely important that you do one of the following:



DRM Icon

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 the server updates device configuration information in the database, it also updates the same information in the backup files.

Note:
When you install Tivoli Storage Manager, a default DEVCONFIG option in the server options file specifies a device configuration backup file named devcnfg.out.

During a database restore operation, the server tries to open the first device configuration file in the order in which the files occur in the server options. If it cannot read that file, it searches for the next usable device configuration file. 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, the device configuration file is backed up to all files specified with the DEVCONFIG server option.

In order to ensure updates are complete before the server is halted, we recommend you:

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

If you are using automated tape libraries, volume location information is also saved in the device configuration file. The file is updated whenever CHECKIN LIBVOLUME, CHECKOUT LIBVOLUME, and AUDIT LIBRARY commands are issued, and the information is saved as comments (/* ...... */). This information is used during restore or load operations to locate a volume in an automated library. If you must recreate the device configuration file, you will be unable to recreate the volume location information. Therefore, you must define your library as a manual library and manually mount the volumes during server processing. If an automated tape library is used at the recovery site, volume location information in comments (/*...*/) in the device configuration file must be modified. First, manually place the physical database backup volumes in the automated library and note the element numbers where you place them. Then manually edit the device configuration file to identify the locations of the database backup volumes so that the server can find them to restore the database.

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:
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 information in the database, the device configuration file is automatically updated. This information includes definitions for device classes, libraries, drives, and servers.

If a disaster occurs, you may have to restore Tivoli Storage Manager 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.

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 shows an example of a device configuration file:



/* Tivoli Storage Manager Device Configuration */
define devclass tape8mm devtype=8mm library=8mmlib
define library 8mmlib libtype=manual
define drive 8mmlib tapedrive3 
define path server1 tapedrive3 srctype=server desttype=drive library=8mmlib device=mt3.0.0.1

Saving the Server Options

You should make a copy of your server options file and save it.

Saving the Database and Recovery Log Information

You should make copies of this output and save them. The database and recovery log setup information is the output from detailed queries of your database and recovery log volumes.

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, the backup data is written 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. Snapshot database backups enhance the protection of your server and its data while maintaining the full and incremental database backup series. Although 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 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 ]