Restoring the database

You might have to restore the IBM Spectrum® Protect database after a disaster. You can restore the database to the most current state or to a specified point in time. You must have full, incremental, or snapshot database backup volumes to restore the database.

Before you begin

If the database and recovery log directories are lost, re-create them before you issue the DSMSERV RESTORE DB server utility. For example, use the following commands: Linux 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

Restrictions:

To restore the database to its latest version, you must locate the archive log directory. If you are cannot locate the directory, you can restore the database only to a point in time.
You cannot use Secure Sockets Layer (SSL) for database restore operations.
If the release level of the database backup is different from the release level of the server that is being restored, you cannot restore the server database. For example, if you are using a Version 8.1 server and you try to restore a Version 7.1 database, an error occurs.

About this task

Point-in-time restore operations are typically used for situations such as disaster recovery or to remove the effects of errors that can cause inconsistencies in the database. To recover the database to the time when the database was lost, recover the database to its latest version.

Procedure

Use the DSMSERV RESTORE DB server utility to restore the database. Depending on the version of the database that you want to restore, choose one of the following methods:

Restore a database to its latest version. For example, use the following command:
```
dsmserv restore db
```
Restore a database to a point in time. For example, to restore the database to a backup series that was created on 19 April 2015, use the following command:
```
dsmserv restore db todate=04/19/2015
```

What to do next

If you restored the database and directory-container storage pools exist on the server, you must identify inconsistencies between the database and the file system.

If you restored the database to a point in time and you did not delay reuse of the directory-container storage pool, you must audit all the containers. To audit all containers, issue the following command:
```
audit container stgpool
```
If the server cannot identify containers on the system, complete the following steps to display a list of containers:
1. From an administrative client, issue the following command:
```
select container_name from containers
```
2. From the file system, issue the following command for the storage pool directory on the source server:
  Tip: The storage pool directory is displayed in the command output:
```
[root@source]$ ls -lR
```
```
c:\source_stgpooldir>dir /s
```
3. Compare the containers that are listed on the file system and the server.
4. Issue the AUDIT CONTAINER command and specify the container that is missing from the server output. Specify the ACTION=REMOVEDAMAGED parameter to delete the container.
5. To ensure that the containers are deleted on the file system, review the messages that are displayed.
  Tip: After a database restore operation, if containers exist on the file system that are not referenced in the server database, the QUERY STGPOOL command inaccurately displays the storage pool usage. When you restore a database to a point in time, containers might remain on the file system, but are not referenced in the server database. To help ensure accurate statistics about storage pool usage, you must manually delete any containers that are available on the file system, but are not referenced in the server database.