Differential Backups: Faster Backups, Simpler Restores
A differential backup saves all changes since the last full backup, making daily backups faster. To restore, you only need the full backup and the latest differential file. The footgun: each differential file grows larger until the next full backup is made.
WHY IT EXISTS Full database backups are slow and resource-intensive, making them impractical to run every day. Businesses need a way to capture daily changes for disaster recovery without the massive overhead of a full backup, while keeping the restoration process as simple as possible.
THE MENTAL MODEL Think of a differential backup like a running tally of edits to a book. You make a full copy of the book on Sunday (the full backup). On Monday, you note the changes on a separate piece of paper. On Tuesday, you throw away Monday's paper and create a new one with all changes from both Monday and Tuesday. To restore, you only need the original book and your single most recent list of edits.
HOW IT WORKS The process begins with a full backup. Each subsequent differential backup then saves all data that has changed since that last full backup. This means the differential backup file on Tuesday contains all the changes from Monday and Tuesday. To restore a system, you only need two files: the last full backup and the single, most recent differential backup. This simplifies the restore process significantly compared to other methods.
WHEN TO USE IT Use this strategy when you need a balance between daily backup speed and simple restoration. It's ideal for a schedule where you can only afford to run a full backup weekly (e.g., on a Sunday) but need to protect against data loss on the weekdays. The two-file restore process is its main selling point.
WHEN NOT TO USE IT This strategy is less effective for databases where the amount of data changing each day is very large. Because the differential file includes all changes since the last full backup, it grows larger with each passing day. By the end of the week, the backup process can become almost as slow as a full backup, negating the speed advantage.
ONE CANONICAL EXAMPLE A common schedule is a full backup on Sunday and differential backups from Monday to Saturday. If the database server fails on Thursday afternoon, the recovery process is simple: first, restore the full backup from Sunday. Second, apply the single differential backup file created on Thursday. You can safely ignore the differential files from Monday, Tuesday, and Wednesday.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.