How long should your backup history actually go back? The right answer depends on your risk profile, compliance obligations, and how you actually use restores — not a generic default. A full comparison, a 4-factor decision framework, and the real cost tradeoffs at each tier.
Retention period is one of the most consequential backup settings that almost nobody deliberately chooses. Most people, and most businesses, run whatever their backup tool ships as a default — without ever asking whether that default actually matches their real risk profile, their compliance obligations, or how they’ve actually used restores in the past.
This article breaks down what retention actually controls, compares the three most common windows in detail, and gives you a practical framework for choosing the one that fits your specific situation.
30d
Catches the vast majority of accidental-deletion scenarios
90d
The common compliance-driven default for regulated businesses
∞
Indefinite retention is usually a cost decision, not a safety one
What retention period actually controls
Retention determines how far back you can go when restoring a previous version of a file — not whether backup happens at all, but how deep the available history is once you need to go back further than the most recent version. A shorter window means lower storage cost and simpler management; a longer window means protection against issues that take longer to surface, at a real ongoing cost.
The three tiers, compared
| Window |
What it covers well |
Cost implication |
Practical note |
| 30 days |
Catches the vast majority of accidental deletions and “oh no I need that back” moments |
Lowest storage cost of the three; simplest to manage |
Won’t help if you discover a problem more than a month after it occurred |
| 90 days |
Common regulatory/compliance-driven default; covers slower-to-notice issues |
Meaningfully more storage cost than 30 days, but still bounded |
The most common “safe default” for businesses without a specific reason to choose otherwise |
| Indefinite / “forever” |
Covers even the rarest, slowest-to-surface issues or long-tail legal holds |
Storage cost grows continuously and indefinitely |
Rarely actually needed in practice — usually a cost decision disguised as a safety one |
💡 The most common mistake
Choosing indefinite retention “just to be safe,” without ever checking whether the additional storage cost is buying meaningfully better protection versus 90 days. In most cases, it isn’t — the marginal issues caught beyond 90 days are rare, while the cost keeps growing indefinitely.
How to choose the right window for your situation
Work through these four factors in order — the first one that applies to you should generally set your floor.
1
Do you have a specific compliance requirement?
If a regulation, industry standard, or contract specifies a minimum retention period, that’s your floor — don’t go below it regardless of what else this list suggests.
2
How quickly do issues in your data typically surface?
If problems (errors, disputes, audits) in your business typically surface within weeks, 30 days may be sufficient. If they can surface months later, lean toward 90 days or more.
3
What’s your actual restore history telling you?
Look at your own restore request history if you have it. Most businesses find they’ve never actually needed anything older than 60-90 days — but this is worth confirming with real data rather than assuming.
4
What’s the storage cost tradeoff at each tier?
Get concrete numbers for what 30 vs. 90 vs. indefinite actually costs for your data volume before deciding — the difference is sometimes smaller than people assume, and sometimes much larger.
Compliance requirements always come first
If your industry or contracts specify a minimum retention period, that requirement overrides any cost or convenience consideration. Confirm this before optimizing for anything else — retention that’s technically cheaper but non-compliant isn’t actually a valid option.
Frequently asked questions
Q: Can I use different retention windows for different types of data?
Yes, and many organizations do — for example, 90 days for financial records but 30 days for general working documents. This requires your backup tool to support per-folder or per-policy retention settings, which is worth confirming before assuming it’s possible.
Q: Does a longer retention window mean better protection?
Not necessarily. Longer retention protects against slower-to-surface issues, but it doesn’t improve protection against the most common scenarios (accidental deletion, device failure), which are usually caught well within 30 days. Longer retention is about covering edge cases, not overall protection quality.
Q: What happens to data after the retention window ends?
It’s permanently deleted from the backup system, following whatever schedule your provider uses to actually purge expired versions. This is worth understanding specifically — some systems purge immediately at the exact retention boundary, others on a periodic cleanup cycle.
Q: Should retention policy be a technical decision or a business decision?
Both, but the business/compliance side should set the requirement, and the technical implementation should follow it — not the other way around. Choosing retention based on whatever a vendor’s default happens to be is the pattern this article is specifically arguing against.
Retention period deserves the same deliberate attention as any other security or compliance setting — not because the decision is complicated, but because it’s so easy to never actually make it, and just inherit whatever default a vendor happened to ship with.
