Transaction recovery involves the transaction log file that is used as a write-ahead log, plus journal files maintained on a per-database basis. Log files contain short-term recovery information regarding active databases, while the journal files contain long-term information used for auditing and disaster recovery. While the log file is circular and wraps around, journal files are of configurable length and are retained indefinitely.

Ingres employs a page-oriented recovery scheme, where changes to pages are reflected in the transaction log file.

Recovery information is divided into two types:

Ingres performs both online and offline recovery, as described in Recovery Modes.

Undo or transaction backout recovery is performed by the DBMS Server. For example, when a transaction is aborted, transaction log file information is used to roll back all related updates. The DBMS Server writes the Compensation Log Records (CLRs) to record a history of the actions taken during undo operations.

A Redo recovery operation is database-oriented. Redo recovery is performed after a server or an installation fails. Its main purpose is to recover the contents of the DMF cached data pages that are lost when a fast-commit server fails. Redo recovery is performed by the recovery process. Redo recovery precedes undo recovery.

In an Ingres cluster environment where all nodes are active, the local recovery server performs transaction redo/undo for a failed DBMS server on its node, just like in the non-cluster case. The difference in a cluster installation is that if the recovery process (RCP) dies on one node, either because of an Ingres failure, or a general failure of the hardware, an RCP on another node will take responsibility for cleaning up transactions for the failed nodes.