---
title: "How long should you keep backups?"
description: "The honest answer depends on why you are keeping them, and there are only three reasons. Work out which apply and the schedule falls out. Then avoid the one retention setting that quietly deletes your last good copy."
url: "https://saved.sh/blog/how-long-to-keep-backups"
date: "2026-08-08"
author: "saved.sh"
tag: "Product"
---

"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 [#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.

<Stats>
  <Stat value="14" unit="days" label="Covers the incidents you notice" />

  <Stat value="90" unit="days" label="Covers the ones you do not" />

  <Stat value="1" label="Reason that is not your decision" />
</Stats>

## A default that works for most teams [#a-default-that-works-for-most-teams]

If nobody has handed you a compliance requirement:

| Age of backup     | Keep             | Why                                                        |
| ----------------- | ---------------- | ---------------------------------------------------------- |
| 0 to 14 days      | Every run        | Reason one, and it is cheap because dumps compress         |
| 14 to 90 days     | One per week     | Reason two, at a fraction of the storage                   |
| 90 days to 1 year | One per month    | Reason two's long tail, plus most audit asks               |
| Beyond a year     | Only if required | Storage that grows forever, for a case that may never come |

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".

<Figure caption="Frequency covers the incidents you catch quickly. Duration covers the ones you do not.">
  <RetentionDial />
</Figure>

## The setting that deletes your last good copy [#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: &#x2A;*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 [#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.

<Aside title="Two questions that set your policy" tone="accent">
  How long could something be wrong with your data before anyone would notice? That
  number is your retention window, and it is usually much larger than 30 days. Then:
  if every backup failed starting tomorrow, how long until your expiry rules deleted
  the last good one? If you cannot answer the second, your retention is a timer, not
  a policy.
</Aside>

## The short version [#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.