Recovery, Logging, Checkpoints, Backup, and Restore
Learn how databases recover from crashes and why logging, checkpointing, and backup strategy are essential for operational reliability.
Inside this chapter
- Why Recovery Is Necessary
- Write-Ahead Logging
- Undo and Redo
- Checkpoints
- Backup and Restore Strategy
- Real-World Example
Series navigation
Study the chapters in order for the clearest path from database fundamentals and SQL to transactions, indexing, recovery, distributed systems, tuning, and advanced DBMS engineering understanding. Use the navigation at the bottom to move smoothly across the full tutorial series.
Why Recovery Is Necessary
Systems crash. Power fails. Hardware breaks. Processes terminate unexpectedly. A DBMS must recover without leaving data in a corrupted or half-written state.
Write-Ahead Logging
A common rule is write-ahead logging, where change information is recorded in the log before the actual data page is written. This enables undo and redo behavior during recovery.
Undo and Redo
Undo reverses incomplete work. Redo reapplies committed work that was not fully written to permanent storage before the failure. Together, they help restore a correct state after crashes.
Checkpoints
Checkpoints reduce recovery time by recording a consistent marker in the log, so the database does not have to replay from the very beginning of history after every crash.
Backup and Restore Strategy
Backups are not only for catastrophic failure. They matter for operator error, accidental deletion, ransomware scenarios, migration rollback, and disaster recovery planning.
Real-World Example
If a payroll database fails during salary processing, recovery mechanisms must ensure no employee is paid twice, skipped incorrectly, or left in a partially updated state. This is why recovery is a business-critical DBMS topic.