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:
| DRM helps you save the previously listed information.
|
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). |
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
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:
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:
reset logconsumption
query log format=detailed
Record the Cumulative Consumption value, which shows the space, in megabytes, used since the statistic was last reset.
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. |
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. |
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:
| 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 volhistoryIf you do not specify file names, TSM backs up the volume history information to all files specified with the VOLUMEHISTORY server option.
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:
| DRM expires database backup series and deletes the volume history
entries.
|
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:
| 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 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, TSM 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. 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 TSM 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: | 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. |
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.
The following commands read and execute the device configuration file:
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:
You must provide those definitions needed to mount the volumes read by the TSM command that you issued. If you are restoring or loading from a FILE device class, you will need only the DEFINE DEVCLASS command.
The following figure shows an example of a device configuration file:
/* Tivoli Storage Manager Device Configuration */ define devclass tapeclass devtype=8mm library=manuallib define library manuallib libtype=manual define drive manuallib drive02 device=/dev/mt2 |
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
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. |