Backups
Backup retention planning: choose how many recovery points to keep
Backup retention planning decides how many recovery points survive and for how long. Keeping “the last seven backups” is not a strategy until you know backup frequency, daily change rate, ransomware/deletion discovery time, legal/business retention needs, and how much storage a full plus incremental chain consumes.
Start from recovery scenarios
List the events you need to recover from: accidental deletion noticed within hours, bad deployment noticed tomorrow, corruption discovered next week, compromised credentials, server loss, or a long-hidden application error. Different discovery windows need different retention.
Do not keep one rolling daily copy if a destructive mistake can remain unnoticed longer than that window.
Choose a retention shape
A common shape combines frequent recent recovery points with fewer weekly/monthly copies for older history, but the exact schedule should follow the workload. Databases with continuous change may need more frequent application-consistent backups than static files.
Understand whether incrementals depend on a base full backup and what happens when one chain component is missing.
Calculate storage with change rate
Estimate current protected data, daily changed bytes, compression/dedup assumptions you can actually verify, and growth. Leave operational headroom so retention does not abruptly fail when the source grows.
Monitor used storage plus the oldest and newest successful recovery points. Job success alone does not show retention health.
Expire by policy and test old restores
Automate retention only after confirming which copies are protected from deletion and how a restore selects a point in time. Periodically restore both a recent and an older recovery point to ensure aging policy has not broken the chain.
- Map retention to discovery windows.
- Understand full/incremental dependencies.
- Budget growth and headroom.
- Restore old points periodically.