Published June 25, 2026
Part 1 covered mistakes that come from not managing backups at all. This part looks at a quieter category: teams that do manage them, but choose how long to keep copies without thinking it through.
Retention decisions cause some of the costliest backup mistakes, because they only show up at the worst moment. Here are two common approaches compared.
Short retention keeps only a few recent copies. A daily backup kept for two or three days is a typical example. It is simple, it keeps storage costs low, and the list of backups stays small enough to read at a glance.
For many systems, this is a reasonable choice. If a server is easy to rebuild and its data changes little, a handful of recent copies may be all anyone needs.
The risk is a problem that goes unnoticed. Suppose a script quietly damages records on Monday and nobody sees it until Friday. With three days of retention, every copy now contains the damage, and the clean version is gone. Nothing failed in the backup process. It did exactly what it was told, and the recovery window was still too short.
Short retention has another weakness: it gives you no margin for a backup job that stops. If runs fail for a few days, the last good copies can expire before anyone notices, leaving nothing at all.
Long retention keeps many copies over weeks or months. It gives you far more places to go back to, and it covers slow-burning problems that take days or weeks to discover.
The cost is mostly storage, which grows with every copy. The less obvious cost is clutter. A long list of backups is harder to scan, and older copies of servers that no longer exist can pile up with nobody sure whether they are safe to remove.
Long retention can also create false comfort. Having sixty copies suggests resilience, but if the newest one is eleven days old, your real exposure is eleven days of data. Volume does not substitute for recency.
Without a rule that removes old copies automatically, long retention drifts toward the opposite problem: unlimited storage growth that nobody planned.
| What matters | Short retention (Option A) | Long retention (Option B) |
|---|---|---|
| Storage cost | Low | Higher, grows with copies |
| Recovery window | Short | Long |
| Slow-to-notice problems | Poorly covered | Better covered |
| Margin if a job stops | Small | Larger |
| Readability of the backup list | Easy | Harder as it grows |
| Needs automatic cleanup | Less | Yes |
| Guarantees a recent backup | No | No |
The last row is the important one. Neither setting makes the newest backup recent. Retention controls how far back you can go; frequency and monitoring control how fresh your latest copy is.
Pick by how long a problem could stay hidden, not by what storage costs. If errors in a system would surface within a day, short retention is fine. If they could take a week to appear, you need retention longer than a week.
A practical approach is to tier it. Give critical systems longer retention, and give easily rebuilt ones shorter retention. Then add three habits that apply to both choices:
Avoid the default trap of setting one value everywhere "to be safe." It leaves critical systems under-protected and cheap ones overpaying.
Bigbell supports either choice, because retention is something you set deliberately. Its backup management feature lets you create daily, weekly, or monthly backup schedules for servers in connected AWS, Azure, and Google Cloud accounts, each with a retention period in days.
On each run, Bigbell creates an image on AWS or a snapshot on Azure and Google Cloud, and removes the copies it created that have passed the retention period. That addresses the clutter problem for long retention without a manual cleanup job. Schedules can be edited later, so retention can follow a system's importance.
On AWS, that cleanup considers copies made for the same server at the same frequency, so after changing a frequency it is worth reviewing older copies yourself.
Backup discovery handles the false-comfort problem. For each server, it shows the number of backups and how many days ago the latest one was taken, so you can see a pile of copies with a stale newest one. A server with none shows "None."
Bigbell does not test restores, and it cannot tell you whether a problem is hiding in your data. For restore testing, see our disaster recovery guide.
Book a demo and see retention and backup age across your servers.
How long should I keep backups? Longer than the time a problem could go unnoticed, balanced against storage cost.
Is more retention always safer? No. It widens your recovery window but does not make the newest backup any fresher.
Why can short retention fail even when backups run? If damage goes unnoticed longer than the retention period, every copy may contain it.
Can Bigbell delete old backups automatically? It removes the backups it created once they pass the retention period.
Can I change retention later in Bigbell? Yes. Schedules can be edited or deleted.
How do I spot a stopped backup job? Look at the age of the newest backup. Bigbell's backup discovery shows days since the latest one.
Does Bigbell test restores? No. Restore testing should be done separately.
Which clouds does Bigbell support for backups? AWS, Azure, and Google Cloud.
Should every server use the same retention? No. Set it by how important the system is and how long problems might stay hidden.
What is the cost of keeping too many copies? Higher storage use and a backup list that is harder to review.
Can I use different retention for different servers? Yes. Each Bigbell schedule has its own retention period.
What if old backups are for servers that no longer exist? Review them and remove what you no longer need, so cost and clutter do not grow.
Does long retention replace regular checks? No. You still need to confirm the newest backup is recent.
How do I choose between a week and a month of retention? Ask how long a problem could stay hidden in that system. Choose the longer window if the answer is uncertain.
Is it a mistake to keep only one backup? Often, yes. A single copy leaves no way back if that copy is damaged or already contains the problem.
What is the quickest retention check I can do today? Pick one critical server and ask whether its oldest backup predates the longest problem you could miss.
Does Bigbell show how many backups a server has? Yes. Backup discovery lists the count for each server.
