![]() |
![]() |
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 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, 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.
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
To set the log mode back to normal, enter:
set logmode normal
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:
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.
> dsmserv extend log a00 5mb
Specify volume sizes in multiples of 4MB plus 1MB for overhead.
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:
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.
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.
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 saves a copy of the volume history file in its disaster recovery plan
file.
|
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.
You can also back up the volume history information at any time, by entering:
backup volhistoryIf 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:
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:
| DRM expires database backup series and deletes the volume history
entries.
|
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:
To ensure the availability of the device configuration information, it is extremely important that you do one 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 the server updates device configuration information in the database, it also updates the same information in the backup files.
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.
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.
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 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 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 define path server1 drive02 srctype=server destype=drive library=manuallib device=/dev/mt2 |
You should make a copy of your server options file and save it.
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.
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
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