Backup, restore, and rollforward operations within Db2 pureScale Feature

The IBM® Db2 pureScale Feature supports restore and rollforward recovery through topology changes.

After adding or dropping a member, a database backup is not required. You can restore a backup that is taken before the topology change event and run a rollforward recovery operation. 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 not identical to the source members

A restore and rollforward is allowed from a source topology into a target topology where the members are not identical. 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.

When the target member topology is not a superset of the source member topology, these restrictions apply:
  • There must be at least one common member between the source and target member topology.
  • 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.
  • The ROLLFORWARD DATABASE command must be run from the common member.
For more information, see Restore and roll forward through a topology change.