Recover a Database from an Old Checkpoint
If the most recent checkpoint has been damaged or is unreadable, it is possible to recover from an older checkpoint. You can use either a specific checkpoint number or the most recent usable checkpoint.
To recover the database from a particular checkpoint and apply all journals after that time, issue the following command:
Windows:
rollforwarddb +j #cn dbname
Linux:
rollforwarddb +j '#cn' dbname
where n is the checkpoint number. For example the following command requests recovery from checkpoint 4 for the Employee database:
rollforwarddb +j #c4 employee
The checkpoint sequence number must be a valid checkpoint number. You can verify this number with the infodb command.
If the most recent checkpoint is unfinished and you want to recover using the most recent usable finished checkpoint, issue the following command:
Windows:
rollforwarddb +j #c dbname
Linux:
rollforwarddb +j '#c' dbname
The #c flag can also be used with the -b and -e flags if you want to restore a database to its state at a previous moment in time.
Caution! You must exercise extreme caution with the -b and -e options. Because these commands roll the database forward to a point in time other than that fully represented by the journals, transactions that were performed after the -e time or before the -b time are lost. Partially completed transactions can be backed out by the roll forward process. Furthermore, a checkpoint must always be performed after completion of such a roll forward, thereby ensuring that obsolete journal data is not inadvertently reused in a subsequent recovery (or by an audit database operation to produce inaccurate auditing results).
Note: The audit database -b and -e flags behave in the same manner as the equivalent roll forward flags, and can be used to predict roll forward results.
Note: If the database is encrypted and ALTER PASSPHRASE WITH NEWKEY was performed after the old checkpoint, a special procedure is required to restore that checkpoint.
Last modified date: 01/27/2026