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
Every outage post mortem eventually reaches the same question: can we restore from backup? The answer splits companies into two groups. Those that tested their restore path and recovered in minutes. And those that discovered their backups were incomplete, corrupted, or nonexistent, then spent days rebuilding by hand.
GitLab learned this in January 2017. Five separate backup mechanisms had been configured for their production PostgreSQL database. When an engineer accidentally deleted a directory on the primary, the team tried each mechanism in sequence. Database had been misconfigured and was not running. LVM snapshots were never enabled. pg_dump to S3 had silently failed weeks earlier. Azure disk snapshots were not configured for the production server. The only functional backup was a staging snapshot that was six hours old. Six hours of production data was lost permanently.
The lesson is not that backups are hard. The lesson is that having a backup strategy on paper means nothing unless every layer is tested, monitored, and matched to the actual recovery requirements of the workload. This lesson covers the five core approaches, full, incremental, differential, snapshot, and continuous, so you can pick the right combination for each service tier.
| Strategy | How It Works | RPO | RTO | Storage Cost | Best For |
|---|---|---|---|---|---|
| Full | Copies every byte every time | Window between runs | Fast (single restore) | Highest | Small databases under 50 GB |
| Incremental | Copies only changes since the last backup (any type) | Window between runs | Slow (chain of restores) | Lowest | Large datasets with low change rate |
| Differential | Copies changes since the last full backup | Window between runs | Medium (full + one diff) | Medium | Balance of cost and restore speed |
| Snapshot | Point in time block level copy | Time since last snapshot | Fast (mount and go) | Medium | Cloud volumes, VMs, databases with snapshot support |
| Continuous | Streams every write in real time (WAL, binlog, CDC) | Near zero | Fastest (point in time restore) | Highest | Tier zero transactional systems |
Every strategy is a tradeoff between four variables: how much data you can afford to lose (RPO), how fast you need to recover (RTO), how much storage you are willing to pay for, and how complex the restore procedure is. No single strategy wins on all four. Production systems almost always combine two or three.
It is easy and good
“It is really nice and good Please join the course”