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
The naive answer is "forever." The realistic answer is "it depends on how problems are discovered and how much you are willing to pay."
Most data corruption is caught within 24 hours by automated monitoring or angry users. A smaller fraction surfaces in weekly reports. A still smaller fraction shows up in quarterly audits. Compliance obligations can extend the tail to seven years or more. The retention policy mirrors this decay curve: keep many recent copies, fewer older ones, and a handful of archival snapshots stretching years into the past.
Getting this wrong in either direction is expensive. Keep too few backups and you discover during a crisis that the corruption predates your oldest copy. Keep too many and you pay thousands per month in storage for data nobody will ever restore. Worse, keeping backups longer than your stated retention policy is itself a GDPR and CCPA violation because you are holding personal data past its declared lifecycle.
Veeam, Rubrik, and AWS Backup all default to tiered retention policies because their largest customers, banks and healthcare systems, learned through audits and incidents that flat "keep everything forever" or "keep 7 days" policies both fail. The industry standard is a pyramid: 14 dailies, 8 weeklies, 12 monthlies, 7 yearlies. The shape follows the probability curve of when problems are discovered.
A retention policy is a set of rules defining how many backups to keep at each granularity level and when each backup expires.
| Tier | Count | Granularity | Retention | Purpose |
|---|---|---|---|---|
| Daily | 14 | Every night | 14 days | Operational recovery from recent mistakes |
| Weekly | 8 | Sunday snapshot promoted | 8 weeks | Mid-range recovery for delayed corruption discovery |
| Monthly | 12 | 1st of each month promoted | 12 months | Quarterly audit support, annual compliance |
| Yearly | 7 | January 1st promoted | 7 years | HIPAA, SOX, PCI-DSS, financial record laws |
The promotion model keeps the system simple: you do not run separate backup jobs for each tier. The nightly backup runs once. On Sunday, that night's backup gets an additional "weekly" tag. On the first of the month, the weekly gets a "monthly" tag. On January 1st, the monthly gets a "yearly" tag. Expiration rules delete backups when their tag's retention window expires.
For a 500 GB Postgres database, this pyramid holds 41 distinct backup images. Raw storage looks like 20 TB, but deduplication and incremental chains in tools like Rubrik or pgBackRest typically reduce that by 60 to 80%. The actual storage footprint lands around 4 to 8 TB, costing roughly $460 per month across mixed S3 tiers.
It is easy and good
“It is really nice and good Please join the course”