The recovery component of a database system takes up the hard task of ensuring atomicity and durability of every modification made to a database (the "A" and "D" of ACID transactions).

While the system is running, the logging component keeps track of what happens with the data, collecting information necessary to undo and redo modifications.

When a failure occurs, recovery kicks in and restores the data to the most recent transactionally consistent state, based on the information it finds in the logs.

The problem we try to solve is that recovery is a painful process, which leaves the system unavailable for hours or even days. Our goal is to design simple algorithms that greatly improve the availability and robustness of the system, without noticeable impacts on runtime performance.