Administrator's Guide


Backing Up the Database

Requesting a database backup ( "Doing Full and Incremental Backups") is a simple operation. However, before you do your first backup, you must take some or all of the following steps:

To restore your data, you must also save 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. For incremental backups you can specify a device class different from the one used for full backups.

For example, you can write full backups to a tape device and incremental backups to a disk device. 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 one or more device classes and, therefore, mount points for automatic backups only. In this way, you avoid trying to run a backup based on the database backup trigger with no mount point available. If a database backup, which is a high priority operation, shares a device class with a low priority operation, such as reclamation, and all the mount points are in use, ADSM automatically cancels the lower priority operation. This frees a mount point for the database backup.
Note:Device class definitions are saved in the device configuration files (see "Saving the Device Configuration Backup File").

Setting the Recovery Log Mode

You set the recovery log mode to either normal or rollforward. If you do not set the recovery log mode, ADSM runs in normal mode. See "Database Backup" for a description of the two modes and for a comparison their benefits and costs.

To set the log mode to normal, enter:

set logmode normal

To set the log mode to rollforward, enter:

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

Scheduling Database Backups

Database backups can tie up resources (mount points and tapes) and, depending on the type of backup and the size of your database, can take some time. You will probably want to schedule your backups to occur, when possible, after certain activities and at specific times of the day.

To ensure that you have the most recent database information, you might back up the database after activities such as:

You would usually back up your storage pools daily and immediately back up the database. Depending on the amount of client data and frequency of the activities mentioned above, you may back up less often.

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

Full backups

Full backups are required:

Incremental backups

Estimating the Size of the Recovery Log

In both normal mode and rollforward mode, the volume of ADSM transactions affects how large you should make your recovery log. As more clients are added and the volume of concurrent transactions increases, you can extend the size of the log. In rollforward mode you must 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 significantly more space than is required in normal mode.

How, then, do you determine how large your recovery log should be in rollforward mode? You need to determine how much recovery log space is used between database backups. For example, if you plan daily incremental backups, you should check your daily usage over a period of time. You can use the following procedure to make your estimate:

  1. Start by setting your log mode to normal. In this way you are less likely to exceed your log space if your initial setting is too low for rollforward mode.

  2. After a scheduled database backup, issue the following command to 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, issue the following command to display the current recovery log statistics:
    query log format=detailed
    

    The Cumulative Consumption field contains the log space in megabytes used by the server since the statistic was last reset. Record the value.

  4. Reiterate steps 2 and 3 over at least one week.

  5. Increase the highest cumulative consumption value by 30 to 40 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 sufficient space between daily backups.

For information on how to adjust the recovery log size, see "Adding Space to the Database or Recovery Log" or "Deleting Space from 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 the needed database backup. For example, to create a 5MB volume A00, issue the following command:
> dsmserv extend log a00 5mb

Volume sizes are specified in multiples of 4MB plus 1 MB for overhead.

Setting a Database Backup Trigger

In rollforward mode, a database backup trigger can cause ADSM to back up the database automatically. When the space occupied in the recovery log reaches a specified percentage, ADSM automatically runs a full or incremental backup of the database and deletes any unnecessary recovery log records.

Attention: The database backup trigger is intended to initiate a backup when you have scheduled a database backup but the recovery log utilization has grown faster than planned. It should not be used in place of coordinating your recovery log size and your scheduled backups. A database backup has a greater priority than many other operations. A backup based on a trigger could occur at a time of high activity and affect your other operations. To control the timing of scheduled database backups, adjust the recovery log size so that the trigger does not cause the database to be backed up at non-scheduled times.

Setting a database backup trigger is optional, but it is recommended to ensure that the recovery log does not run out of space before the next backup.

If the log mode is changed from normal to rollforward, the next database backup must be a full backup. If a database backup trigger is defined when you set the log mode to rollforward, the full backup is done automatically. The server does not start saving log records for rollforward 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, your recovery log typically consumes less than 500MB between backups, and your log size is 650MB. You do not want the trigger to initiate a backup except in unusual circumstances. Therefore, you should set the trigger no lower than 75 percent (approximately 500MB).

To set the database backup trigger at 75 percent and run 20 incremental backups to every full backup, enter:

define dbbackuptrigger logfullpct=75 devclass=tapeclass
 numincremental=20

If you do not specify the LOGFULLPCT and NUMINCREMENTAL parameters, the trigger defaults to 50 percent and ADSM runs 6 incremental backups to every full backup. Each incremental backup, whether automatic or by command, is added to the count of incremental backups run. Each full backup, whether automatic or by command, resets the count for incremental backups to zero. When you specify 0 for the NUMINCREMENTAL parameter, ADSM automatically runs only full backups.
Note:If you issue a BACKUP DB command with the TYPE=INCREMENTAL parameter, ADSM 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 taken, and the counter for the number of incremental backups since the last full backup 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

ADSM 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, ADSM no longer runs automatic database backups.

Note:If you delete the trigger and stay in rollforward 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 rollforward recovery.

Saving the Volume History File

The volume history file contains information about the following:

ADSM 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, ADSM must get the information from the volume history file.

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



Figure AB0CT203 not displayed.

DRM saves snapshots 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 (for details, see the ADSM Administrator's Reference). After the server is restarted, whenever ADSM updates volume information in the database, it also updates the same information in the backup files specified by the VOLUMEHISTORY option.

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

backup volhistory

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

Deleting Volume History Information

You should periodically delete outdated information from the volume history file. For example, if you keep your backups for seven days, any information older than that is not needed (see the example below). When information about database backup volumes or export volumes is deleted, the volumes return to scratch status in the libraries attached to the server and may be reused. For scratch volumes with device type FILE, the files are deleted. When information about volumes in storage pools is deleted, the volumes themselves are not affected.

To display volume history information up to yesterday, enter:

query volhistory enddate=today-1

For example, to delete information that is seven days old or older, enter:

delete volhistory todate=today-8


Figure AB0CT203 not displayed.

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

 

Saving the Device Configuration Backup File

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

Whenever ADSM 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, ADSM 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 snapshots 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 ADSM Administrator's Reference). After the server is restarted, whenever ADSM updates device configuration information in the database, it also updates the same information in the backup files.

During a database restore operation, ADSM tries to open the first device configuration file. If it cannot open or read that file, ADSM 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.

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

backup devconfig

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

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.

If you are using automated tape libraries, ADSM also saves volume location information 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.

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.

Recreating a Device Configuration File

The following commands read and execute the device configuration file:

Note:The DSMSERV LOADDB command 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:



/* IBM AdStar Distributed Storage Manager Device Configuration */

define devclass tapeclass devtype=8mm library=manuallib

define library manuallib libtype=manual

define drive manuallib drive02 device=/dev/mt2

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, for example, enter:

backup db type=full devclass=tapeclass

In this example, ADSM 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


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