How long should you keep backups?

"How long should we keep backups" gets answered with a number someone half remembers from a compliance document, usually 30 days, occasionally seven years, almost never with a reason attached.

There are only three reasons to keep a backup, they want very different windows, and once you know which apply to you the schedule writes itself.

The three reasons

1. Somebody broke something and noticed. A dropped table, a bad migration, a deploy that corrupted a column. Detection is fast, usually minutes to hours.

Window needed: 7 to 14 days. Frequency matters far more than duration here, because your exposure is the gap between backups, not their age.

2. Somebody broke something and did not notice. A silent corruption, a half-working integration writing bad rows, an encryption event that sat dormant. Detection is slow, weeks to months.

Window needed: 90 days to a year, and this is the reason most teams under-retain.

3. Somebody outside asks. An auditor, a regulator, a customer contract, a legal hold.

Window needed: whatever the document says, and it is not negotiable by you. Go read the actual clause rather than the summary; the difference between "seven years" and "seven years after account termination" is enormous.

A default that works for most teams

If nobody has handed you a compliance requirement:

The instinct to keep everything forever is understandable and expensive. Retention is the only setting that bounds your storage bill, so a policy of "keep everything" is a policy of "this line item grows without limit".

The setting that deletes your last good copy

Here is the trap, and it catches careful people.

The most common way to express retention is a bucket lifecycle rule: delete objects older than 30 days. It is one line, it works, and it has no idea whether your backups have been succeeding.

If your dumps started failing 40 days ago, that rule has been methodically deleting your last good copies, on schedule, one per day, while your storage graph looked completely normal. On day 31 you had one good backup left. On day 32 you had none.

Age-based expiry with no knowledge of success is a deletion policy pretending to be a retention policy. It is the single most dangerous configuration in this entire subject, and it is the default almost everywhere.

Count and duration are not the same setting

The other common mistake is expressing retention as a count, "keep the last 5", and assuming it bounds anything.

A count is a floor, not a cap. It says which recent copies are protected from expiry. It cannot decide what to delete on its own, because deleting by count alone is how you lose your only recent copies the moment a source starts producing runs faster than you expected. A backup that suddenly runs hourly instead of nightly will blow through "keep the last 5" in five hours.

So we treat them as what they are:

• Expire after is the trigger. It is the only thing that deletes.
• Keep last is the floor. The newest N are protected from that trigger, and on its own it deletes nothing at all.
• Lock for is protection. It is a promise that nobody may delete the artifact during that window, including us.

The three combine with and. An artifact goes only when it is older than the expiry window, outside the protected floor, and not locked. And whatever the policy says, the newest remaining copy is never deleted, because a backup that has run once should always have something to restore from.

The short version

Keep everything for two weeks, thin it out to weekly for three months, monthly for a year, and longer only when a document tells you to.

Then check the more important thing: that whatever expires your old backups knows whether your new ones are working.