IBM Books

Administration Guide

Recovery Method: Version Recovery

Version recovery using the BACKUP command in conjunction with the RESTORE command puts the database in a state that has been previously saved. You use this recovery method with non-recoverable databases (that is, databases for which you do not have archived logs).

In this section, planning considerations and how to invoke the specific utilities or commands to carry out the method are reviewed. Then, any concepts or related issues that allow effective use of this method are presented.

The following topics provide additional information:

Backing Up a Database

To make a backup copy of the database, you use the BACKUP command or the Control Center. Within the Control Center, you select the database to be backed up and then select the backup action.

Figure 29. Creating a Database Image


In a partitioned database system, you back up database partitions individually using the BACKUP DATABASE command. The operation is local to the database partition server where you issue the command. You can, however, issue db2_all from one of the database partition servers in the instance to submit the backup command on a list of servers, which you identify by their node number. If you do this, you must back up the catalog node first, then back up the other database partitions. You can also use the Control Center to backup database partitions.

In a partitioned database system, you can use the LIST NODES command to determine the list of nodes (database partition servers) that have user tables on them. Because this recovery method does not support roll-forward recovery, regularly back up the database on this list of nodes.

You must keep in mind the recovery method to be used. The following sections provide requirements and other considerations that apply to this task:

Planning to Use the BACKUP Command

Your planning considerations should include:

If you have tables that contain DATALINK columns, also see "Backup Utility Considerations".

Invoking the BACKUP Command

The following considerations are useful when running the BACKUP command:

Backup Images Created by BACKUP

Backup images are created at the target specified when you call the BACKUP command:

The recovery history file is updated automatically with summary information whenever you carry out a backup or restore of a full database. This file can be a useful tracking mechanism for restore activity within a database. This file is created in the same directory as the database configuration file. For more information on the recovery history file, see "Recovery History File Information".

In UNIX-based environments, the file name(s) created on disk will consist of a concatenation of the following information, separated by periods; on other platforms a four-level subdirectory tree is used:

Database alias
A 1-to-8 character database alias name that was supplied when the backup command was invoked.

Type of backup taken, where: "0" is for full database.

Instance name
A 1-to-8 character name of the current instance of the database manager that is taken from the DB2INSTANCE environment variable.

Node number
The node number.

Catalog node number
The node number of the database's catalog node.

Time stamp
A 14-character representation of the date and time the backup was performed. The timestamp is in the format yyyymmddhhnnss, where:
   yyyy is the year (1995 to 9999)
   mm is the month (01 to 12)
   dd is the day of the month (01 to 31)
   hh is the hour (00 to 23)
   nn is the minutes (00 to 59)
   ss is the seconds (00 to 59)

Sequence number
A 3-digit sequence number used as a file extension.

In UNIX-based operating systems, the format would appear as:

Database alias.Type.Instance name.nodennnn.catnnnnn.timestamp.number

On other operating systems, the format would appear as:

Database alias.Type\Instance name.nodennn\catnnnn\yyyymmdd\hhmmss.number

For example in UNIX-based environments, a database named STAFF on the DB201 instance may be backed up on disk to a file named:


For tape-directed output, file names are not created; however, the above information is stored in the backup header for later verification purposes.


  1. If you want to use tape media for database back-up and restore operations, a tape device must be available through the standard operating system interface. On a large partitioned database system, however, it may not be practical to have a tape device dedicated to each database partition server. You can connect the tape devices to one or more ADSM servers, so that access to these tape devices is provided to each database partition server.

  2. On a partitioned database system, you can also use products that provide virtual tape device functions, such as REELlibrarian 4.2 or CLIO/S. You use these products to access the tape device connected to other nodes (database partition servers) through a pseudo tape device. Access to the remote tape device is provided transparently, and the pseudo tape device can be accessed through the standard operating system interface.

Restoring a Database

The following sections provide requirements and other considerations that apply to the RESTORE command:

Figure 30. Restoring a Database Using a Backup Image


Planning to Use the RESTORE Command

You should consider the following:

If you have tables that contain DATALINK columns, see both "Restore and Rollforward Utility Considerations" and "Restoring Databases from an Offline Backup without Rolling Forward".

Invoking the RESTORE Command

The following considerations are useful when running the RESTORE command:

Redefining Table Space Containers During RESTORE

During a backup of a database, a record is kept of all the table space containers in use by the table spaces that are backed up. During a RESTORE, all containers listed in the backup are checked to see if they currently exist and are accessible. If one or more of the containers is inaccessible because of a media failure (or for any other reason), the RESTORE will fail. In order to allow a restore in such a case, the redirecting of table space containers is supported during the RESTORE. This support includes adding, changing, or removing of table space containers.

There are cases in which you want to restore even though the containers listed in the backup do not exist on the system. An example of such a case is where you wish to recover from a disaster on a system other than that from which the backup was taken. The new system may not have the necessary containers defined. In order to allow a RESTORE in this case, the redirecting of table space containers at the time of the RESTORE to alternate containers is supported.

In both situations, this type of RESTORE is commonly referred to as a redirected restore.

You can redefine table space containers through the restore task from within the Control Center. You can also use the REDIRECT parameter of the RESTORE command to specify the redirection. If you are using the Control Center, one way of performing a redirected restore is to use the Containers page of the Restore Database notebook. This page provides function that you can use to add new containers, change the path of an existing container, or remove a container. If, during the process of the restore database operation an invalid container path is detected, the Control Center will prompt you to either change the container path, or remove the container.


  1. Directory and file containers are automatically created if they do not exist. No redirection is necessary unless the containers are inaccessible for some other reason. The database manager does not automatically create device containers.

  2. The ability to perform container redirection on any RESTORE provides considerable flexibility in managing table space containers. For example, even though we do not directly support adding containers to SMS table spaces, you could accomplish this by simply specifying an additional container on a redirected restore. Similarly, you could move a DMS table space from file containers to device containers.

  3. Redirected restore is also supported through a number of APIs. Although you could write a program to perform redirected restore for a specific case, these APIs are primarily intended for developers who want to produce a general purpose utility.

Restoring to an Existing Database

You may restore a backup copy of a full database backup to an existing database. To restore to an existing database, you must have SYSADM, SYSCTRL, or SYSMAINT authority. The backup image may differ from the existing database in its alias name, its database name, or its database seed.

A database seed is a unique identifier of a database that remains constant for the life of the database. This seed is assigned by the database manager when the database is first created. The seed is unchanged following a restore of a backup even if the backup has a different database seed. DB2 always uses the seed from the backup.

When restoring to an existing database, the restore task performs the following functions:

Restoring to a New Database

As an alternative to restoring a database to a database that already exists, you may create a new database and then restore the backup of the data. To restore to a new database, you must have SYSADM or SYSCTRL authority.
Note:The code pages of the backup and the target database must match. If they do not, first create the new database specifying the correct code page, then restore it.

When you restore to a new database, the RESTORE command will perform the following functions:

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]