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.
- 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.
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.
- 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
- 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
- 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.