How many backups to keep: the real question is not the count, it is how far back you can go

The question is usually asked as "how many backups should I keep". The right question is: how far back do I need to be able to go. The count follows from that answer, not the other way round.

The two different things retention covers

A recent mistake. You deleted the wrong file, an update broke something, a setting went wrong. You want yesterday. A few days of copies cover this and more.

Slow damage. A file corrupted three weeks ago, an application writing wrong data ever since a bad update, ransomware sitting quietly and waiting. Here yesterday is useless, because yesterday contains the damage too. You have to reach back past the moment it started.

The most common and most misleading rule

"Keep the last 7" is the most frequently configured rule. It is perfect against the first class and does nothing against the second. In damage that went unnoticed for a month, all seven of your copies are damaged. The rule is not wrong, it is incomplete: it answers only one question.

Extending reach without blowing up storage

The answer is not more copies, it is frequent near, sparse far. Daily for a short window, weekly for a couple of months, monthly for further back. The number of copies stays small and the reach grows long. With twenty copies you can go back a year; keeping only dailies, those same twenty copies take you no further than three weeks.

The number to decide first

Not how many copies: how long can damage sit unnoticed on this system. That is not a storage question, it is a question about how closely this system is watched. A machine nobody looks at needs longer reach, not more copies. If you do not know the answer, an honest estimate is usually longer than you think.

The rule is a deletion rule

When you write a retention rule you are really deciding what you will not be able to bring back. Say it out loud once: "I will not be able to recover anything older than a month". If the sentence sounds acceptable, the rule is right. If it makes you uneasy, extend the reach.

A promise and a disk are not the same thing

Retention is a promise about the future, a disk is a fact about the present. Verify the promise fits: number of copies times size, plus room for growth. The day it does not fit is the day backups stop, and that day is usually one nobody is watching.

Where the rule lives

Know whether retention is defined on the target or on the job. If two jobs writing to the same place carry different rules, the result is one that neither of them intended: one believes it is deleting, the other believes it is keeping. A rule that lives in one place is easier than a rule that stays consistent in two.

What Atlas does

Atlas offers retention as part of the storage definition and gives the five tiers separately: last, daily, weekly, monthly, yearly. So the "frequent near, sparse far" shape above can be built directly, without doing the arithmetic by hand.

It also states plainly what leaving a field empty means: empty means unlimited and everything is kept. That looks like a small sentence, but it closes the most common misunderstanding, because in most interfaces an empty field is assumed to mean "the default", while here it means "never delete".