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 6-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”
Every other backup strategy requires you to reason about consistency. Hot backups rely on transaction logs. Snapshots capture a fuzzy point in time. Incremental backups depend on a chain of prior copies. Cold backups skip all of that by stopping the database first.
When the database process is not running, there are no in-flight transactions, no dirty pages in memory, no WAL records waiting to flush. The files on disk represent the exact, complete state of the data. You copy those files. That is the backup. No reconciliation, no redo log replay, no risk of a half-written page.
This simplicity is why cold backups persist in 2026 despite decades of improvements in online backup technology. Banking core systems, healthcare databases subject to HIPAA, and payment processors under PCI-DSS Level 1 all still schedule cold backup windows because auditors trust a stopped database more than they trust a running one with a "consistent snapshot" guarantee they cannot independently verify.
The trade-off is obvious: your system is offline for the entire duration. For a 3 TB MySQL instance, that window runs 60 to 120 minutes. For an organization serving global traffic around the clock, that kind of outage is unacceptable. For a payroll system that processes batches overnight, it is perfectly fine.
A cold backup has one defining characteristic: the database engine is fully shut down before the copy begins.
| Property | Cold Backup |
|---|---|
| Database state during copy | Stopped, all buffers flushed to disk |
| Consistency guarantee | Absolute, no recovery replay needed |
| Downtime required | Yes, entire backup window |
| Copy method | File-level: tar, rsync, cp, or storage-level snapshot |
| Restore complexity | Low. Copy files back, start the database |
| Typical duration (1 TB) | 30 to 90 minutes depending on I/O |
| Best for | Compliance archives, regulated workloads, simple environments |
| Worst for | 24/7 systems, SLA-bound services, anything with global users |
The key distinction from every other backup type is that consistency comes from the shutdown, not from the backup tool. You do not need XtraBackup, pg_basebackup, or any database-aware agent. A plain cp -r of the data directory produces a valid backup because the files are not being modified during the copy.
This is also why cold backups are the fastest to restore. There is no WAL replay, no crash recovery, no InnoDB redo log application. You place the files, start the database, and it opens cleanly.
Compare cold backup to warm standby and hot backup to see where each strategy fits.