DB2 10.5 for Linux, UNIX, and Windows

Backup, restore, and rollforward operations within DB2 pureScale Feature

The IBM® DB2® pureScale® Feature supports restore plus rollforward recovery through member addition events. The DB2 pureScale Feature also supports restore through topology changes that require an offline database backup.

After the addition of a new member, a database backup is not required. You can restore a backup that is taken before the add member event and run a rollforward operation recovery. The rollforward operation can be to the end of the transaction log or to any point in time. Restore of online backups are also supported. When restored, online backups require a rollforward operation to bring the database back to a consistent point.

Database backup and restore can be categorized as either an explicit or file level copy.

Explicit: The backup image is created explicitly by using the BACKUP DATABASE command. This backup can be incremental or full, and either an offline backup or an online backup. With an offline backup, the database is in a consistent state and no rollforward operation is required. With an online backup, the database is inconsistent and a rollforward is required to get the database to a consistent point.
File level copy: The backup image is created by using a file level copy mechanism, such as split-mirror, manual flash copy, or volume group snapshot. If the backup was taken from an online database by using the SET WRITE command with the SUSPEND option, the backup image might be inconsistent. To get the database to a consistent point, a rollforward is required.

Starting in Version 10.5, even if the topology on the source instance and the target instance differ, you can restore either type of database backup category. The topology in the source instance is also referred to as the database backup image topology.

Target members that are a superset of source members

If all member identifiers present in the source member topology are also present in the target member topology, the target member topology is referred to as a superset of the source member topology. If the target member topology is not a superset of the source member topology, but there is at least a common member identifier, a change to this topology requires an incremental or full offline database backup.

When the target member topology is a superset of the source member topology, these restrictions apply:

After the restore database operation completes:
- An offline database backup is not required.
- If the state of the database was consistent when the backup was taken, the database is available for immediate use on any of the members by issuing either the CONNECT TO command or the ACTIVATE DATABASE command.
- If the state of the database was not consistent when the backup was taken, before the database is available for use you must make the database consistent.
You can roll forward through one or more add member events in the transaction logs. However, the ROLLFORWARD DATABASE command must be run from the common member between the source and target topology.

A common member is required for restore and rollforward

For the restore and rollforward operations, there must be at least one common member between the source and target member topology. In addition, a common member must meet these criteria:

Before the backup image was created, the common member successfully activated the database (by using either the CONNECT TO command or the ACTIVATE DATABASE command).
The BACKUP DATABASE command must be run from the common member on the target instance.
The RESTORE DATABASE command must be run from the common member.

Target members that are not a superset of source members

When there were some members in the source topology that are not in the target topology, these restrictions apply:

You can restore only a database backup of a consistent database (that is, from an offline database backup).
The RESTORE DATABASE command must include the "WITHOUT ROLLING FORWARD" clause. This clause specifies that the database is not to be put in rollforward pending state after the database is successfully restored.
If the database is a recoverable database, after the restore to the new topology, you must take either an incremental or a full offline database backup.