For the most comprehensive coverage, you should use all the following methods for protecting TSM data:
Attention: ADSM Version 1 provided database salvage commands in case of a catastrophic error. Although these commands are still available, you should use the current database backup and recovery functions for the best server protection. Do not use the database salvage commands without help from an IBM service representative.
If one or more storage pool volumes is lost or damaged, the client data may be permanently lost. However, you can back up storage pools to sequential access copy storage pools and move the volumes offsite. If data is lost or damaged, you can restore individual volumes or entire storage pools from the copy storage pools. TSM tries to access the file from a copy storage pool if the primary copy of the file cannot be obtained for one of the following reasons:
For details, see Restoring Storage Pools, Using Copy Storage Pools to Improve Data Availability, Recovering a Lost or Damaged Storage Pool Volume, and Maintaining the Integrity of Files.
Two TSM commands let you restore files from copy storage pools:
TSM uses database information to determine which files should be restored for a volume or storage pool, so restore processing does not require that the original volumes be accessed. For example, if a primary storage pool volume is damaged, you could use the RESTORE VOLUME command to recreate files that were stored on that volume, even if the volume itself is not readable. However, if you delete the damaged files (DISCARDDATA=YES on the DELETE VOLUME command), TSM removes from the database references to the files on the primary storage pool volume and to copies of the files on copy storage pool volumes. You could not restore those files.
Restore processing copies files from a copy storage pool onto new primary storage pool volumes. TSM then deletes database references to files on the original primary storage pool volumes. If a primary storage pool volume becomes empty because all files that were stored on that volume have been restored to other volumes, TSM automatically deletes the empty volume from the database.
To facilitate restore processing of entire volumes, TSM has a destroyed volume access mode. This mode designates primary volumes for which files are to be restored. If a volume is designated as destroyed, TSM does not mount that volume for either read or write access. You can designate a volume as destroyed with either of two commands:
The destroyed designation for volumes is important during restore processing, particularly when the RESTORE STGPOOL command is used to restore a large number of primary storage pool volumes after a major disaster:
The database contains information about the client data in your storage pools. The recovery log contains records of changes to the database. If you lose the recovery log, you lose the changes that have been made since the last database backup. If you lose the database, you lose all your client data.
You have several ways to protect this information:
You can prevent the loss of the database or recovery log due to a hardware failure, by mirroring them. Mirroring simultaneously writes the same data to multiple disks. However, mirroring does not protect against a disaster or a hardware failure that affects multiple drives or causes the loss of the entire system. While TSM is running, you can dynamically start or stop mirroring and change the capacity of the database.
TSM mirroring provides the following benefits:
However, there are also costs:
TSM can perform full and incremental backups of the database to tape while the server is running and available to clients. With TSM in normal mode, the backup media can then be stored onsite or offsite and can be used to recover the database up to the point of the backup. You can run full or incremental backups as often as needed to ensure that the database can be restored to an acceptable point-in-time.
You can provide even more complete protection if you specify that TSM run in roll-forward mode. With TSM in roll-forward mode and with an intact recovery log, you can recover the database up to its most current state (the point at which the database was lost).
For the fastest recovery time and greatest availability of the database, mirror both the database and recovery log, and periodically back up the database. When operating in roll-forward mode, mirroring better ensures that you have an intact recovery log, which is necessary to restore the database to its most current state.
Roll-forward mode offers the greatest protection for your data.
However, there are costs to roll-forward mode. The following tables
describe the protection afforded by each mode and the requirements for each
mode.
Level of Protection | |
---|---|
Normal Mode | Roll-forward Mode |
Recover to a point-in-time of the latest full or incremental backup only. | Recover to a point-in-time of the latest full or incremental backup or, with an intact recovery log, to the most current state. |
Recover with loss of client data that has been:
| With an intact recovery log, recover to the most current state with no loss of client data. |
You must restore the entire database even if only one volume is damaged. | You can restore a single volume. |
| Preferable if the server supports HSM clients (space-managed files should be protected as fully as possible from hardware failure). |
Storage Requirements | |||
---|---|---|---|
Normal Mode | Roll-forward Mode | ||
Does not require a recovery log to restore to a point-in-time. The recovery log keeps only uncommitted transactions, and its size is not affected by normal mode. | Requires an intact recovery log to restore to the most current
state. The recovery log keeps all transactions since the last database
backup. In this mode you should significantly increase the recovery log
size. However:
| ||
For the greatest availability, you should mirror the database and recovery log or place them on devices that guarantee availability. | You should mirror the recovery log to recover to the most current
state.
|
The following table compares four typical TSM data recovery configurations, two for roll-forward mode and two for normal mode. In all four cases, the storage pools and the database are backed up. The benefits and costs are:
Mode | Mirroring | Coverage | Speed to Recover |
---|---|---|---|
Roll-Forward | Log and database | Greatest | Fastest |
Log Only | Medium | Moderate | |
Normal | Log and database | Medium | Moderate |
None | Least | Slowest |
Attention: If the log mode is set to roll-forward after a point-in-time database restoration, a database backup starts when the server is brought up for the first time. This can cause loss of data: a tape can have current data on it, but because of the point-in-time restoration, it can be marked as scratch. When the server starts for the first time, TSM may use this tape to write the database backup, thus destroying the original data on this tape.
This situation could occur if roll-forward mode is enabled, but the administrator restored the database as if the server was operating in normal mode, not roll-forward mode. For example: the database is to be backed up at midnight everyday Monday through Friday. On Friday, the database was restored to a point-in-time of midnight Wednesday. Thursday's database backup was not used; this tape exists and does contain valid data. But because the database was restored to Wednesday at midnight, the Thursday's tape was marked as scratch. This tape was then inadvertently chosen and written with the database backup information. Therefore, the data for Thursday was lost.