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”
Taking a full backup of a 10TB volume traditionally means reading every block, compressing it, and uploading it. That takes hours. A snapshot of the same volume completes in under a second.
The trick is that a snapshot does not copy data at creation time. It captures a set of pointers to the existing blocks on disk. The actual data stays where it is. Only when a block is later modified does the storage layer preserve the original by copying it aside before writing the new version. This is copy-on-write, and it is why every major cloud provider and filesystem (EBS, ZFS, Btrfs, LVM) uses snapshots as the foundation of their backup strategy.
The speed advantage is real, but it hides a risk. A snapshot that shares physical storage with the live volume is not an independent copy. In 2021, a fintech startup lost two days of trading data because a storage controller bug corrupted the live volume and, with it, every snapshot that was still sharing blocks. They had 14 snapshots on paper and zero usable recovery points.
A snapshot at creation time is pure metadata: a table mapping logical blocks to their current physical locations. No data moves. The cost is a few kilobytes regardless of volume size.
| Property | Snapshot Backup |
|---|---|
| What it captures | Block-level pointers to the current state |
| Creation time | Milliseconds, independent of volume size |
| Storage consumption | Only the delta of blocks changed after the snapshot |
| Restore approach | Create a new volume from the snapshot, blocks load lazily |
| Consistency guarantee | Crash-consistent by default, application-consistent with quiesce |
| Provider examples | AWS EBS, GCP Persistent Disk, ZFS, LVM, Btrfs |
The critical subtlety: a snapshot is crash-consistent, not application-consistent. It captures whatever was on disk at that instant, including partially written transactions. For databases, you must call pg_start_backup() (Postgres) or FLUSH TABLES WITH READ LOCK (MySQL) before snapshotting to guarantee a clean recovery point. Aurora and Cloud handle this automatically through their storage layer.