You can restore a Db2® database to
another Db2 instance on an alternative host.
You can also choose to restore a database to an instance with a different name and rename the
database. This process creates an exact copy of the database on a different host in a different
instance. If you are restoring a resource to an alternative location, you can restore the same
resource multiple times without specifying different target hosts.
Before you begin
Important:
- For all restore operations, Db2 must be at the same version level on the source and target
hosts. In addition to that requirement, you must ensure that an instance with the same name as the
instance that is being restored exists on each host. This requirement applies when the target
instance has the same name, and when the names are different. In order for the restore operation to
succeed, both instances must be provisioned, one with original name and the other with the new
name.
-
When you run the restore job by choosing the Overwrite existing database
option, the source database in the source instance on the target host is dropped and the source
database is recreated during the process. The redirected restore process first restores the source
database in the source instance and then relocates it to the target instance and renamed target
database.
To avoid restore job failure, you can manually clean up the system to delete source database in
the source instance on the target host before you run the restore job.
Before you create a restore job for
Db2, ensure that the following requirements are met:
- At least one Db2 backup job is set up and
running successfully. For instructions about setting up a backup job, see Backing up Db2 data.
- IBM Storage® Protect
Plus roles and resource groups are
assigned to the user who is setting up the restore job. For more information about assigning roles,
see Managing user access.
- When restoring from a IBM Storage
Protect archive, files
will be migrated to a staging pool from the tape prior to the job beginning. Depending on the size
of the restore, this process could take several hours.
-
Restore jobs can create data in the IBM Db2
log directory. In some cases, if more than one restore job is run, data will remain in the log
directory from the previous job. As a result, the next attempt to restore a database to the original
location fails unless the log directory is purged.
For example, if the Db2 log directory is
empty and a restore job runs with the options Restore to original instance,
Overwrite existing databases, and Recover until end of
backup, the restore job is successfully completed. If the job is followed by a second
job with the options Restore to original instance, Overwrite
existing databases, and Recover until end of available logs, this
second restore attempt fails because the original restore job left data in the Db2 log directory.
Before you start a restore operation to an alternative instance,
ensure that the file system structure on the source machine is matched on the target machine. This
file system structure includes table spaces, online logs, and the local database directory. Ensure
that dedicated volumes with sufficient space are allocated to the file system structure. Db2 must be at the same version level on the source and
target hosts for all restore operations, and an instance of the same name must exist on each host.
For more information about space requirements, see Space requirements for Db2 protection. For more information about
prerequisites and setup, see Prerequisites
for Db2.
Restriction: If data exists on the local database directory to which you are restoring
the database backup to, and the Overwrite existing databases option is not
selected, the restore operation fails. No other data can share the local database directory where
the backup is restored. When the Overwrite existing databases option is
selected, any existing data is removed and the local database directory on the alternative host.
Note: When you are restoring multi-partitioned databases to an alternative location, ensure that the
target instance is configured with the same partition numbers as the original instance. All of those
partitions must be on a single host. When you are restoring data to a new instance that is renamed,
both instances instances required for the restore operation must be configured with the same number
of partitions.
About this task
Ensure that the disk paths for the redirected restore operation include the instance name
and the database name. The information is needed for all types of paths: database paths, container
paths, storage paths, and log and mirror log paths.
Procedure
-
In the navigation panel, expand and click .
The Rrestore wizard opens.
- Optional:
If you started the restore wizard from the Jobs and Operations page, click
Db2 as the source type and click Next.
Tips:
- For a running summary of your selections in the wizard, click Preview
Restore in the navigation panel
in the wizard.
- The wizard is opened in the default setup mode. To run the wizard in advanced setup mode, select
Advanced Setup. With advanced setup mode, you can set more options for your
restore job.
-
On the Select source page, click a Db2 instance to show the databases in that instance.
Choose a database by clicking the plus icon
for that database name. Click
Next to continue.
-
In the Source snapshot page, choose the type of restore operation
required.
- On-Demand: Snapshot: creates a once-off restore operation from a
database snapshot. The job is not set to recur.
- On-Demand: Point-in-Time: creates a once-off restore operation from a
point-in-time backup of the database. The job is not set to recur.
- Recurring: creates a recurring job that runs on a schedule and
repeats.
Tip:
For an On-Demand: Snapshot you can select no recovery or to recover until
the end of the backup. For an On-Demand: Point in Time restore job you can
select to recover until the end of the available logs, or recover until a specific point-in-time.
-
Complete the fields on the Source snapshot page and click Next to continue.
The fields that are shown depend on the number of items that were selected on the Select source page and on the restore type. Some fields are also not shown until you select a related field.
Fields that are shown for an on-demand snapshot, single resource restore
| Option | Description |
|---|
| Date range |
Specify a range of dates to show the available snapshots within that range. |
| Backup storage type |
All backups in the selected date range are listed in rows that show the time that the backup operation occurred and the service level agreement (SLA) policy for the backup. Select the row that contains the backup time and SLA policy that you want, and then take one of the following actions:
- Click the backup storage type that you want to restore from. The storage types that are shown depend on the types available in your environment and are shown in the following order:
- Backup
- Restores data that is backed up to a vSnap server.
- Replication
- Restores data that is replicated to a vSnap server.
- Object Storage
- Restores data that is copied to a cloud service or to a repository server.
- Archive
- Restores data that is copied to a cloud service archive or to a repository server archive (tape).
- Click anywhere on the row. The first backup type that is shown sequentially from the left of the row is selected by default. For example, if the storage types Backup, Replication, and Archive are shown, Backup is selected by default.
|
| Use alternate vSnap server for the restore job |
If you are restoring data from a cloud service or a repository server, select this box to specify an alternative vSnap server, and then select a server from the Select alternate vSnap menu.
When you restore data from a restore point that was copied to a cloud resource or repository server, a vSnap server is used as a gateway to complete the operation. By default, the vSnap server that is used to complete the restore operation is the same vSnap server that is used to complete the backup and copy operations. To reduce the load on the vSnap server, you can select an alternative vSnap server to serve as the gateway.
|
Fields that are shown for an on-demand snapshot, multiple resources restore; or recurring restore. For point-in-time restore, only Site is available for Restore Location Type.
| Option | Description |
|---|
| Restore Location Type |
Select a type of location from which to restore data:
- Site
- The site to which snapshots were backed up. The site is defined in the pane.
- Cloud service copy
- The cloud service to which snapshots were copied. The cloud service is defined in the pane.
- Repository server copy
- The repository server to which snapshots were copied. The repository server is defined in the pane.
- Cloud service archive
- The cloud archive service to which snapshots were copied. The cloud service is defined in the pane.
- Repository server archive
- The repository server to which snapshots were copied to tape. The repository server is defined in the pane.
|
| Select a location |
If you are restoring data from a site, select one of the following restore locations:
- Primary
- The primary site from which to restore snapshots.
- Secondary
- The secondary site from which to restore snapshots.
If you are restoring data from a cloud or repository server, select a server from the Select a location menu.
|
| Date selector |
For on-demand restore operations, specify a range of dates to show the available snapshots within that range. |
| Restore Point |
For on-demand restore operations, select a snapshot from the list of available snapshots in the selected date range. |
| Use alternate vSnap server for the restore job |
If you are restoring data from a cloud service or a repository server, select this box to specify an alternative vSnap server, and then select a server from the Select alternate vSnap menu.
When you restore data from a restore point that was copied to a cloud service or repository server, a vSnap server is used as a gateway to complete the operation. By default, the vSnap server that is used to complete the restore operation is the same vSnap server that is used to complete the backup and copy operations. To reduce the load on the vSnap server, you can select an alternative vSnap server to serve as the gateway.
|
- Choose a restore method appropriate for the destination chosen
for the restore operation. Click Next to continue.
- Production: In this mode, the Db2 application server first copies the files from the
vSnap repository volume to the target host, which is either an alternative location or the original
instance. That copied data is then used to start the database.
- Test: In this mode, the agent creates a new database by
using the data files directly from the vSnap repository.
- Instant Access: In this mode, no further action is taken
after IBM Storage Protect Plus mounts the volume from the vSnap
repository. Use the data for custom recovery from the files in the mounted volume.
- Add a database name when you are restoring the database to a different location and
you want to rename the database.
- Set the destination for the restore operation to Restore to alternate
instance to restore data to a different location, which you can select from the list of
eligible locations. Click Next to continue.
When you are restoring to an alternative location, choose an instance in the
Instance table before you click Next. Unsuitable
target instances cannot be selected.
- Choose options as described in Restoring Db2 data.
- In the Schedule page, name the restore job and choose the
frequency for the job to run. Schedule the start time, and click Next to
continue.
If the restore job you are specifying is an on-demand job, there is no option to enter a
schedule. Specify a schedule only for recurrent restore jobs.
- In the Review page, review your selections for the restore
job. If all the details are correct for your restore job, click Submit, or
click Back to make amendments.
Results
A few moments after you click Submit, the
onDemandRestore record is added to the Job Sessions
pane. To view progress of the restore operation, expand the job. You can also download the log file
by clicking the download icon 
. All running jobs are viewable in the
Jobs and Operations
Running Jobs page.