Example: Restoring a server database to a point in time

To restore a database to point in time, you need the latest full backup before the point in time. You also need the latest incremental backup after that last full backup. You can also use snapshot database backups to restore a database to a specific point in time.

Before you begin

Before you restore the database, have available the following infrastructure setup files:

Server options file
Volume history file:
Copy the volume history file pointed to by the server options file. The backup copy must a different name. If the restore fails and you must try it again, you might need the backup copy of the volume history file. After the database is restored, any volume history information pointed to by the server options is lost. This information is required to identify the volumes to be audited.

If your old volume history file shows that any of the copy storage pool volumes that are required to restore your storage pools were reused (STGREUSE) or deleted (STGDELETE), you might not be able to restore all your files. You can avoid this problem by including the REUSEDELAY parameter when you define your copy storage pools.
Device configuration file:
You might need to modify the device configuration file that is based on the hardware available at the recovery site. For example, the recovery site might require a different device class, library, and drive definitions.
Detailed query output about the database and recovery log

If files were migrated, reclaimed, or moved after a backup, the files might be lost and the space that is occupied by those files might be reused. You can minimize this loss by using the REUSEDELAY parameter when you define or update sequential-access storage pools. This parameter delays volumes from being returned to scratch or being reused.

Procedure

To restore the database to a point-in-time, complete the following steps:

If the database or recovery log directories were lost, re-create the directories. For example: AIX operating systems

mkdir /tsmdb001
mkdir /tsmdb002
mkdir /tsmdb003
mkdir /activelog
mkdir /archlog
mkdir /archfaillog

mkdir e:\tsm\db001
mkdir f:\tsm\db001
mkdir g:\tsm\db001
mkdir h:\tsm\activelog
mkdir i:\tsm\archlog
mkdir j:\tsm\archfaillog

Use the DSMSERV RESTORE DB utility. For example, to restore the database to a backup series that was created on April 19, 2009, enter:
```
 dsmserv restore db todate=04/19/2009
```
The server completes the following actions:
1. Reads the volume history file to locate the last full backup that occurred on or before the specified date and time.
2. Using the device configuration file, requests a mount of the first volume. The first volume contains the beginning of the full backup.
3. Restores the backup data from the first volume.
4. Continues to request mounts and to restore data from the backup volumes that contain the full backup and any incremental backups that occurred on or before the specified date.
From the old volume history information that was generated by the QUERY VOLHISTORY command, obtain a list of all the volumes that were reused (STGREUSE), added (STGNEW), and deleted (STGDELETE) since the original backup. Use this list to complete the remaining steps in this procedure. It might also be necessary to update the device configurations in the restored database.
Issue AUDIT VOLUME command and specify the FIX=YES parameter to audit all disk volumes, all reused volumes, and all deleted volumes.
The audit volume process identifies files that are recorded in the database that can no longer be found on a volume. If a copy of the file is in a copy storage pool or an active-data pool, the file on the audited volume is marked as damaged. Otherwise, the file is deleted from the database and is lost.
If the audit detects any damaged files, issue the RESTORE STGPOOL command to restore those files after you audit the volumes in the storage pool.
Mark as "destroyed" any volumes that cannot be located, and recover those volumes from copy storage pool backups. If no backups are available, delete the volumes from the database by using the DELETE VOLUME command with the DISCARDDATA=YES parameter.
Redefine any storage pool volumes that were added since the database backup.

What to do next

After a restore, the volume inventories for Tivoli® Storage Manager and for your tape management system might be inconsistent. For example, after a database backup, a new volume is added to Tivoli Storage Manager. The tape management system inventory records the volume as belonging to Tivoli Storage Manager. If the database is restored from the backup, Tivoli Storage Manager has no record of the added volume, but the tape management system does. You must synchronize these inventories.

Similarly, the volume inventories for Tivoli Storage Manager and for any automated libraries might also be inconsistent. Issue the AUDIT LIBRARY command to synchronize these inventories.