Backward Recovery applies the journal file to the active database, moving backward from the end of the file. Backward Recovery uses "before-image" journaling. With before-image journaling, GT.M captures the database updates, as well as "snapshots" of portions of the database immediately prior to the change caused by the update. JOURNAL -RECOVER -BACKWARD works only if the production database is usable, and if the MUPIP SET command that created the journal file specified the BEFORE_IMAGES qualifier.

In effect, BEFORE_IMAGES creates "mini-backups" preceding each database update. Backward Recovery uses the mini-backups to restore the database as far back in time as specified by the qualifiers used with the MUPIP JOURNAL command, then it replays the database updates.

Using Backward Recovery with the MUPIP JOURNAL qualifiers -SINCE=, -BEFORE=, and -LOOKBACK_LIMIT=, you can specify a block of time to recover.

Do not delete a database that you want to -BACKWARD recover. Recovery can only occur into an existing/used database.

Use -RECOVER -FORWARD for databases that have been recreated.

Example of Backward Recovery:

This shows a recovery after a system crash at 10:35. The recovery "un-does" the database updates backward to 10:20, then applies updates forward until the crash. By adding -BEFORE="- - 10:30" to the command, the recovery stops when forward processing encounters updates that originally occurred after 10:30. If the application includes ZTSTART and ZTCOMMIT commands to fence a group of transactions, backward processing may continue back prior to 10:10 searching to resolve fenced transactions that were incomplete at 10:20. The -LOOKBACK_LIMIT= qualifier controls the maximum amount of additional backward processing, in this case, 10 minutes. Note that the -SINCE time in this example is slightly exaggerated for the sake of the graphical representation.