Backup Retention: How Long to Keep Backups (and Why 'Longer' Isn't Always Better)

Every backup system asks the question during setup, and most businesses answer it by accident: how long do we keep backups? The default gets accepted — 30 days, maybe 60 — and nobody revisits it until the day someone needs a file from February and it’s May. Retention is one of the few backup decisions that’s genuinely a business decision wearing technical clothes, and getting it deliberate takes about an hour. Here’s the thinking.

The problem retention actually solves: delayed discovery

The instinct says backups exist for disasters — and disasters use yesterday’s backup, making long retention seem pointless. The instinct misses where retention actually earns its keep: problems discovered long after they happened. The folder deleted in January, noticed when a client asks in May. The spreadsheet quietly corrupted months before anyone opened it. The ransomware intrusion that began weeks before detonation — where you need a restore point from before the attacker got in, not from last night when they were already inside. And the departed employee whose files mattered after the account countdown expired. Thirty days of retention protects you against problems noticed within thirty days; real-world discovery timelines are reliably longer, which is why short default retention is the gap businesses discover exactly once.

The pattern that makes long retention affordable: GFS

Keeping every nightly backup for years would cost a fortune and help nobody. The industry’s elegant answer — grandfather-father-son (GFS) — keeps density where recency matters and sparsity where it doesn’t:

• Sons — daily backups, kept for a few weeks: the “restore yesterday” tier where most recoveries live
• Fathers — one weekly backup, kept for a few months: coarse but sufficient for “sometime in March”
• Grandfathers — one monthly backup, kept for a year or more (some businesses add one annual, kept for years)

The result: you can restore to yesterday precisely, to any week this quarter, and to any month this year — at a fraction of keep-everything storage. Every serious backup platform implements this natively; the work is choosing your numbers, not building the machinery. A sane small-business starting point: 30 daily / 12 weekly / 12–24 monthly, tuned by the tiers below.

Three inputs tune your numbers

1. Data tier. The classification map does the sorting: Restricted and business-record data earns the long grandfathers; the general file share can live on standard settings; the truly archival belongs on cheap long-term media rather than expensive backup-platform retention.

2. Legal and industry obligations. Some retention floors aren’t yours to choose: healthcare and financial-services record rules, tax records, litigation-hold obligations for firms, and contract terms with your own clients. Two precision notes here: backup retention and records retention are different policies — backups are a recovery mechanism, not a records-management system, and regulators generally care about the latter; and retention cuts both ways — data you’re required to delete (or promised to) shouldn’t live forever in backups either. Where obligations are real, get the numbers from counsel or your compliance source, not a blog — this one included.

3. Cost, honestly. Long retention costs storage, and cloud storage bills monthly — which is the practical argument for GFS density-tapering and for tiering: pay premium storage for the recent, restorable-in-hours copies, and cheap archive tiers for the grandfathers. If retention costs are surprising, the fix is almost always tiering, not shortening.

Two settings that interact with retention

Immutability windows should fit inside your retention design: the immutable lock needs to cover at least your realistic breach-discovery window (30+ days), and locked copies can’t be pruned early — so set both numbers together, not separately. And retention only counts if verified: the restore tests should occasionally reach deep — pull a file from a six-month-old grandfather, because the aged tiers are the ones nobody exercises and the whole reason the policy exists.

Write it down (one paragraph does it)

The finished policy is short enough to memorize: dailies kept X days, weeklies Y months, monthlies Z months; systems A and B get extended retention for [reason]; immutability window N days; reviewed annually with the IT plan. That paragraph, written, is what turns retention from a default into a decision — and it’s the exact answer the insurance application and every client security questionnaire is fishing for.

The bottom line

Retention isn’t “how paranoid are we” — it’s matching your restore reach to how late problems actually surface, at a cost the GFS pattern keeps sane. Set the tiers on purpose, honor the legal floors, lock the immutable window inside it, test the old copies occasionally, and write the paragraph down. An hour of deliberateness, and “can we get it back from March?” becomes a yes with a timestamp instead of a lesson.