Restoring a server database to a point in time

To restore a server database for IBM Spectrum® Protect to the state at a specified point in time, you require the most recent full backup before the point in time. You also require the incremental backup that was created immediately after that last full backup. You can also use snapshot database backups to restore a database to a specific point in time.

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

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

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

   

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

2. Optional: To prevent client or server operations from accessing data on the storage pool volumes until the database restore operation is complete, you can temporarily disable server maintenance processes and client sessions. To disable these processes, start the server in maintenance mode. For more information, see Starting the server for maintenance or reconfiguration tasks.
3. Run the DSMSERV RESTORE DB command. For example, to restore the database to a backup series that was created on 19 April 2016, run the following command:

   dsmserv restore db todate=04/19/2016

   You can use several parameters with the DSMSERV RESTORE DB command. For example, if your environment uses encrypted container storage pools in a cloud environment, you can use the RESTOREKEYS and PASSWORD parameters. Other parameters specify the paths that are used for database and log information and the ability to preview the operation. For more information, see DSMSERV RESTORE DB.

   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.
4. Run the QUERY VOLHISTORY command to obtain a list of all the volumes that were reused, added, and deleted since the original backup. Use this list to complete the remaining steps in this procedure. The device configuration file in the restored database might also need to be updated. To ensure that volumes are accurately audited in the restored database, you can temporarily disable access to sequential volumes in the list until the remaining steps in this procedure are complete.
5. Optional: To temporarily disable access to the sequential volumes, run the following command:

   UPDATE VOLUME volume_name ACCESS=UNAVAILABLE

   If you disable access to the volumes, you must run the following command before you run the AUDIT VOLUME commands in the remaining steps:

   UPDATE VOLUME volume_name ACCESS=READONLY

6. Run the AUDIT VOLUME command and specify the FIX=YES parameter for the following volume types:
   • All disk volumes
   • Reused volumes and deleted volumes for TAPE, VTL, and non-deduplicated FILE 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 storage pool, the file on the audited volume is marked as damaged. Otherwise, the file is deleted from the database and is lost.

   Auditing FILE volumes in a deduplicated storage pool: Do not run the AUDIT VOLUME command with the FIX=YES parameter on FILE volumes in a deduplicated storage pool. For more information about special considerations for FILE volumes in a deduplicated storage pool, see step 9.d in this procedure.
7. If the audit volume process detects any damaged files, run the RESTORE STGPOOL command to restore the files.
8. Complete the following steps:
   1. Mark any volumes that cannot be located as deleted from the database. To mark the volumes as deleted, you can use the DELETE VOLUME command with the DISCARDDATA=YES parameter. This action discards the database entries that would allow the server to access the files on the volume if the files are located in future.
   2. If your storage environment includes directory-container storage pools, you might have to take additional steps to recover data in the storage pools. For instructions, see Recovering from data loss or system outages.
   3. If node replication is configured in your system environment, review the information and take any appropriate steps. A point-in-time database restore of a source replication server disables replication operations that originate from the source server to prevent deleting copies of data that might exist on the target replication servers. To preserve the data that exists on target replication servers, determine whether data copies that are on the target replication server are needed. If they are, you must replicate data that is on the target replication server to the source replication server. Follow the steps in message ANR0340E.
   4. For FILE volumes in a deduplicated storage pool, you must take further actions. Follow the instructions in technote 1883611.
   5. Recover any other 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.
9. Redefine any storage pool volumes that were added since the database backup.