A backup retention policy is the set of rules that decides how long each backup copy is kept, how many versions of a file or system are saved, and when older copies are deleted. It answers a practical question: if something went wrong a week, a month or a year ago, is there still a copy to restore from? The policy balances recovery needs, legal and contractual requirements, and storage cost, and it is enforced through settings in your backup software or service.
At a glance
- Retention sets how far back you can restore; backup frequency sets how much recent data you could lose. Both matter.
- Many policies keep frequent short-term copies and fewer long-term ones, for example daily, weekly and monthly tiers.
- Retention should cover how long an attack or silent corruption might go unnoticed, not just accidental deletion.
- Legal, regulatory, contract and insurer requirements may set minimums, and privacy rules may push for maximums; rules vary by jurisdiction and industry.
- Longer retention usually means higher storage costs, especially for locked or isolated copies.
What problem it solves
Without a deliberate policy, retention ends up set by a product default or by whoever configured the backup job. That causes two opposite problems. Retention that is too short means the copy you need has already expired: a user notices a deleted folder after two months, or ransomware that sat quietly for weeks has already been copied into every remaining backup. Retention that is too long means storage costs keep climbing, and backups hold personal or sensitive data long after the business stopped needing it, which can create legal and privacy exposure.
A written policy makes those trade-offs explicit, gives auditors and customers a clear answer, and gives your backup provider a target to configure and report against.
How it works
Define restore needs. Start with how far back different systems might need to go. Email and files may need months of history for accidental deletion and investigations; a database might need many recent restore points but fewer old ones.
Set tiers. A common pattern keeps daily backups for a few weeks, weekly backups for a few months and monthly or yearly backups for longer. Each tier is a separate retention rule in the backup system.
Account for attacks. Retention for protected copies, such as immutable backups or an air-gapped backup, should be long enough to reach back past the point an attacker got in. A short lock on a copy that expires before you discover the problem doesn’t help.
Align with legal duties. Retention should match the records rules your organization follows and account for exceptions. When litigation is expected, a legal hold may require keeping data that the normal schedule would delete, so the backup team needs a way to suspend deletion for specific data.
Apply across systems. Policies should cover servers, endpoints and cloud applications. SaaS backup for Microsoft 365 or Google Workspace often has its own retention settings, separate from the application’s built-in retention.
Review and test. Check periodically that old restore points actually exist and restore, and that deletion happens when it should.
When it matters for buyers
- When choosing a backup service. Default retention, maximum retention and how retention affects price vary widely across backup as a service (BaaS) providers.
- When a compliance deadline or audit lands. Auditors and customers often ask for a documented retention schedule.
- When cyber insurance renews. Insurers may ask how long protected backups are kept.
- When storage costs jump. Retention is usually the biggest lever on backup storage spend.
- When leaving a provider. Ask what happens to retained copies at the end of the contract.
Questions to ask vendors
- What retention is configured by default, and what is the longest retention you support for each system we’d back up?
- Can we set different retention tiers for daily, weekly, monthly and yearly copies?
- How does retention affect our price, and is long-term or immutable retention a separate tier?
- How do we place specific data on hold so it isn’t deleted on schedule?
- Can you report which restore points exist for each system, and prove old ones restore?
- What happens to our retained backups if we cancel or don’t renew?
How it differs from recovery point objective (RPO)
A recovery point objective (RPO) is about the newest copy: how much recent data you could afford to lose, which drives how often backups run. Retention is about the oldest copy: how far back you can still go. A system can have a tight RPO with backups every 15 minutes and still have short retention, leaving no clean copy once an attack is discovered weeks later. Both belong in the same policy. Our backup as a service overview covers how providers handle retention and pricing.