We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A 3TB database changes about 40GB per day. Running a daily full backup means copying the same 2.96TB of unchanged data over and over, burning storage, saturating I/O, and stretching backup windows past what the production schedule allows.
Incremental backup solves this by capturing only the blocks that changed since the previous backup. The storage savings are dramatic: a week of daily incrementals on a 3TB database uses roughly 280GB instead of 21TB. The backup window shrinks from hours to minutes.
The trade-off is fragility. Every incremental depends on the one before it, forming a chain. If any single link in that chain is corrupted or missing, every backup after it becomes unusable. Code Spaces learned this in June 2014 when an attacker deleted their S3 buckets. The incremental chain was their only disaster recovery strategy. When the chain broke, the company was dead within 12 hours.
An incremental backup tracks which data blocks were modified since the last backup of any type (full or incremental). Only those modified blocks are written to storage.
| Property | Incremental Backup |
|---|---|
| What it copies | Only blocks changed since the previous backup |
| Storage per run | Small, roughly constant day over day |
| Restore requires | The base full plus every incremental in order |
| Restore complexity | Multi-step: lay base, apply each delta sequentially |
| Typical frequency | Daily or hourly depending on RPO |
| Creation speed | Fast, reads only changed pages |
| Recovery speed | Slower than full, proportional to chain length |
The tools: Percona XtraBackup tracks changed pages via the InnoDB LSN. Postgres uses pg_basebackup for the full and WAL archiving for continuous incrementals. AWS Backup, Rubrik, and Veeam abstract the implementation and present a policy-based interface where you declare RPO and the system picks the strategy.