Restoring the database

Edit online

You might have to restore the IBM Storage 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 to the current state or to a specified point in time. If you do not have the required backup volumes, you can still restore the database by re-creating the required backup files.

Before you begin

Restrictions:

To restore the database to its latest version, you must locate the archive log directory. If you cannot locate the directory, you can restore the database only to a point in time.
If the database and recovery log directories are lost, you can re-create the directories. However, you must first re-create the server instance. For detailed instructions about re-creating files and directories that are required to restore a server instance, see Restoring a server when files are missing.
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 2022, use the following command:
```
dsmserv restore db todate=04/19/2022
```

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 replication 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.