Restoring Db2 or Db2 Warehouse by using commands

This process restores a database that was backed up by using the db2 backup command. The restored database starts back the same state that it was in when the backup was made.

Before you begin

You must have an existing Db2 or Db2 Warehouse backup that is accessible on the Red Hat OpenShift cluster.
You must identify the Db2 or Db2 Warehouse catalog node and data nodes and have an SSH connection open to each node. For more information, see Preparing to back up or restore Db2 or Db2 Warehouse.

Note:

The commands in this procedure use the environment variable containing the default database name ${DBNAME}. If you have multiple databases, please update the variable value or commands accordingly.

About this task

The restore script is the preferred strategy to restore because it provides:

A simple flow
A restore strategy for full offline backup images
Native support for restoring encrypted databases

The commands in this procedure are illustrative only and are only applicable when you are restoring from a Db2 or Db2 Warehouse backup in Red Hat OpenShift at a similar version. Further commands are required for restoring an encrypted database. For most restore operations, the best practice is to use the procedure in Using the restore script.

Note: If your backup and restore strategy is based on full offline backup images, you can use a provided script for restoring instead of using the process in this topic. These commands are only applicable when you are restoring from a Db2 or Db2 Warehouse backup in Red Hat OpenShift at a similar version. Otherwise, further commands are required, as detailed in Using restore script.

For a Db2 or Db2 Warehouse deployment, the db2 restore command can be started only from the catalog node, but each available multiple logical node (MLN) participates in the restore operation.

Restriction: A full database restore operation can be run only in offline mode.

Procedure

Exec into the Db2 pod.

Temporarily disable the built-in HA:

sudo wvcli system disable -m "Disable HA before Db2 maintenance"

From a bash shell on each of the nodes specified in the db2nodes.cfg file, switch to the database instance owner. Confirm that the directory that contains the database backup exists and is mounted. For example:
```
su - db2inst1
cd /backup_dir/backup_nnn
```
Where backup_dir is the directory that you create to hold backup images and nnn is an incremental value that was used to put each backup in a separate directory. The directory that is shown here is only an example. The backups can be in any directory on the cluster that is shared by the container nodes and has sufficient space to hold the backups. If you restore a backup from a different directory location, alter these commands as necessary.
Connect to the database:
```
db2 connect to ${DBNAME}
```
On the catalog node, find all the applications that are connected to Db2:
```
db2 list applications
```
This command returns a list of all currently connected applications. You can either stop all the connections by closing the applications, or you can enter the following command to disconnect all connections:
```
db2 force application all
```
Terminate the database:
```
db2 terminate
```
Deactivate the database:
```
db2 deactivate database ${DBNAME}
```
Stop the database:
```
db2stop force
```
Ensure that the command completes on all nodes.
Ensure that all Db2 or Db2 Warehouse interprocess communications are cleaned for the instance:
```
ipclean -a
```
Turn off all communications to the database by setting the value of the DB2COMM variable to null:
```
db2set -null DB2COMM
```
Restart the database in restricted access mode:
```
db2start admin mode restricted access
```
Run the restore operation. On the catalog node, run the following command:
```
db2 RESTORE DATABASE ${DBNAME} FROM backup_dir TAKEN AT backup_image_timestamp INTO ${DBNAME} REPLACE EXISTING WITHOUT ROLLING FORWARD
```
Where backup_dir is the full path to the directory where your backup images are located, and backup_image_timestamp is the associated timestamp on those backup image files. The timestamp is displayed after successful completion of a backup operation, and is part of the path name for the backup image.
Stop the database:
```
db2stop force
```
Ensure that the command completes on all nodes.
Ensure that all Db2 or Db2 Warehouse interprocess communications are cleaned for the instance:
```
ipclean -a
```
Reinitialize the Db2 or Db2 Warehouse communication manager to accept database connections:
```
db2set DB2COMM=TCPIP,SSL
```
Restart the database for normal operation:
```
db2start
```
The offline database restore operation is complete.
Activate the database:
```
db2 activate db ${DBNAME}
```
Re-enable the Wolverine high availability monitoring process:
```
wvcli system enable -m "Enable HA after Db2 maintenance"
```
Connect to the database:
```
db2 connect to ${DBNAME}
```

What to do next

For more information about advanced command options, see the RESTORE DATABASE command