How is database rollforward processing executed after restoring a full database backup?

Rollforward (also called redo or recovery) is the process of replaying committed transactions from the redo/transaction log after a full backup restore to advance the database to its most recent consistent state. This ensures no committed work is lost. Options B, C, and D are incorrect: B describes rollback (undo), C is disk formatting (destructive), and D ignores the critical log replay mechanism that enables point-in-time recovery.

Step-by-step Derivation:
Database crash recovery follows the standard ACID compliance pattern: (1) Restore full backup to get baseline state at checkpoint time T0. (2) Read redo logs from T0 onwards. (3) Replay all committed transactions (rollforward) to reach the state at failure time or target time. The redo log contains all changes made by committed transactions after the backup, so applying these logs deterministically restores lost data. This is distinct from rollback (undo), which removes uncommitted changes during recovery. Option A directly describes this textbook rollforward mechanism used in all production databases (Oracle, PostgreSQL, MySQL, SQL Server).