Restoring the database

You might have to restore the Tivoli® Storage Manager database after a disaster. You can restore the database to the most current state or to a specific 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:

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.
You cannot restore a server database if the release level of the database backup is different from the release level of the server that is being restored. For example, if you are using a Version 7.1 server and you try to restore a Version 6.3 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. Choose one of the following methods depending on which version of the database you want to restore:

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:
1. From an administrative client, display a list of containers that the server can identify by issuing the following command:
```
select container_name from containers
```
2. From the file system, display a list of containers by issuing 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 -l
```
```
c:\source_stgpooldir\00>dir
```
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.