A backup from yesterday can rescue an accidentally deleted file. It may not help when a corrupted database went unnoticed for six weeks. That gap is why a cloud backup retention policy needs to answer a different question from how often backups run: how far back should you be able to recover?
Keeping everything indefinitely sounds safe, but it raises backup storage costs, complicates deletion requests, and increases sensitive data exposure. Keeping too little can make ransomware or slow-moving errors much harder to recover from. A useful policy sets different lifetimes for different recovery points, with a reason for each.
Start with the failures you need to recover from
List realistic events: an overwritten document, failed update, malicious change, database error discovered during month-end reporting, or lost account. Ask how long each problem might remain undetected. That discovery window often matters more than an arbitrary benchmark.
Separate the recovery point objective (RPO) from retention. RPO describes how much recent data loss you can tolerate, influencing backup frequency. Retention defines how old the earliest available recovery point can be. Taking hourly backups for seven days does not provide a restore point from last month.
Choose retention windows by recovery value
A practical cloud backup retention policy keeps many recent points and fewer older ones. This is often called a grandfather-father-son schedule, although intervals should fit the workload rather than follow a rigid formula.
Recent copies for everyday mistakes
For actively edited files or databases, short-interval backups may be valuable for several days. Daily recovery points might then be retained for a few weeks. Consider whether holidays and delayed reporting affect how far back staff need to look.
Weekly and monthly copies for delayed problems
Weekly points can cover errors that survive beyond the immediate recovery window. Monthly points help when defects are discovered during reconciliation, audits, or seasonal work. They cannot replace application-aware backups or tested database restoration.
Long-term copies only where justified
Some records warrant annual or longer-lived recovery points because of documented business or legal requirements. Others do not. Retaining backups for seven years does not automatically satisfy recordkeeping law: a restorable backup differs from a searchable records archive.
A worked example for a small online business
Imagine a retailer running an order database and a separate marketing website. Orders change constantly; the website changes a few times weekly. Giving both systems identical backup retention might waste money or leave gaps.
For the order database, an illustrative starting schedule could keep frequent recovery points for two days, daily points for 30 days, and monthly points for 12 months. The website might need daily points for 14 days and weekly points for eight weeks. These are examples, not universal recommendations; recovery and legal requirements may demand something different.
Now imagine a reporting error discovered 45 days after it began. Daily points have expired, but a monthly point could provide a useful comparison baseline. It may still be too coarse to reconstruct every affected transaction. An older point can exist without offering the precision required for recovery.
Make compliance and deletion rules explicit
Backup retention and legal data retention are related but not identical. Privacy, employment, tax, contractual, and sector-specific obligations vary by country and data type. Record the applicable requirement, its owner, and whether it calls for an archive, a backup, or both. Seek qualified advice where obligations are unclear.
Define what happens when an account is removed, an employee leaves, or a retention period ends. Deleting live data may not immediately remove it from historical backups. Document how protected copies age out, how restored data is handled, and how legal holds suspend deletion when required.
Indefinite retention should be an approved exception, not the default left behind after a project closes.
Account for the true backup lifecycle cost
Storage is only part of the bill. Backup storage costs may include data transfer, requests, retrieval fees, cross-region copies, and minimum-duration charges for colder tiers. Some systems store incremental changes efficiently; others retain large independent copies. Check actual usage before estimating savings.
Moving an old recovery point into an archive tier might lower its storage rate but increase restore time or retrieval expense. AWS Backup requires supported recovery points moved to cold storage to remain there for at least 90 days. Check provider-specific limits before shortening a lifecycle rule.
Evaluate costs against how quickly the business must recover. A cheap archive that takes too long to retrieve may fail a critical recovery-time objective.
Keep retention separate from backup security
Longer retention does not guarantee resilience. An attacker who can delete every recovery point can erase years of history. Use restricted access, independent credentials where possible, monitoring, and immutable or deletion-protected backups for critical systems.
Immutability can prevent premature deletion, including deletion you later want for privacy or operational reasons. Expiry settings, legal holds, and locked protection periods need review together before changes become irreversible.
For additional protection, maintain an appropriately isolated copy and periodically test a complete restore, not merely whether a backup job reported success.
Put the policy into operation
Write a schedule for each workload stating backup frequency, the points kept daily, weekly, and monthly, maximum retention, storage location, deletion conditions, and owner. Include exceptions and a review date.
Check the oldest and newest available recovery points in the console. Confirm expiration rules remove eligible copies and protected copies resist premature deletion. Test restoring an older point, including encryption keys and application dependencies needed to use it.
Review the policy after major system changes, new regulatory obligations, or incidents. Data retention rules work only while they reflect actual operations.
Frequently asked questions
How long should cloud backups be kept?
There is no universal duration. Many teams keep short-interval recent points plus daily, weekly, or monthly history. The right window depends on how late problems emerge, recovery costs, commitments, and applicable law.
Does a 30-day retention setting mean 30 daily versions?
Not necessarily. It may mean each recovery point expires after 30 days, but frequency and provider behaviour determine how many usable points exist. Inspect the actual recovery-point inventory.
Should backups be kept forever for safety?
Usually not. Indefinite backup retention increases exposure and cost and may conflict with data minimisation requirements. Keep longer-lived records when there is a documented reason and suitable storage method.
Can retention replace disaster recovery testing?
No. A retained point may be incomplete, inaccessible, or slow to retrieve. Regular restore tests demonstrate that the policy supports the recovery outcomes the business needs.
Conclusion
A strong cloud backup retention policy preserves useful choices, not the greatest number of copies. Match recovery points to the age of problems you might discover, keep compliance records distinct from operational backups, check lifecycle costs, and verify deletion and restoration. That balances recoverability, cost, and responsible data handling.
