How long should you keep backups?

Short answer: 30 days minimum for anything you would actually restore, structured as roughly 14 dailies, 8 weeklies and 12 monthlies. Below 30 days you cannot recover from a problem you did not notice quickly, and quiet problems are the norm.

The full answer depends on three things: how long errors go unnoticed, how long attackers sit in networks, and what your regulator says.

Why 30 days is the floor

Corruption is discovered late. A migration that mangles a rarely-read column, an integration writing bad values, a slow drift in a report — these surface when someone finally looks, which is weeks later. Seven days of retention means the last clean copy expired before anyone noticed the problem.

Attackers deliberately outlast short retention. Intrusions commonly sit quiet for weeks before triggering, and destroying backups is an early step, not a late one. A 7-day window is not a defence; it is a delay an attacker can simply wait out. See immutable backups.

Restores are often not from yesterday. The most useful snapshot is frequently "the last one before the change," and finding it means having a range to choose from.

Grandfather-father-son

The standard structure, and it long predates cloud. Three tiers with different densities:

The insight is that recency is worth more than density. You want every day of last week and one day of last March, not every day of both. GFS encodes exactly that.

A sensible default for production application data:

14 daily + 8 weekly + 12 monthly = 34 restore points, covering 12 months

Thirty-four snapshots, not 365, and every practical recovery window is covered.

What it actually costs

The instinct is that a year of retention costs 365× a single backup. With deduplication it does not come close.

Take a 50 GB database with 2% daily churn:

The unchanged 98% is stored once. Retention costs the differences, so extending from 14 days to 12 months roughly doubles storage rather than multiplying it by 26.

Which reverses the usual advice. Aggressive pruning is a false economy on deduplicated storage — you save little and give up recovery options. Prune to keep the snapshot list navigable and to honour deletion obligations, not to save money.

Media-heavy datasets are the exception: they dedupe poorly, and there retention genuinely is expensive. See backup storage cost.

Sizing by workload

For the last row, do not guess from a blog post. Retention minimums vary by jurisdiction, sector and record type, and getting them from your compliance owner is the only correct route. Backup compliance covers what auditors typically ask to see.

Automating it

const policy = {
  sourceId: snapshot.sourceId,
  keepLatest: 30,
  before: new Date(Date.now() - 90 * 86400_000).toISOString(),
};

// Always preview. This is the one operation that destroys data on purpose.
const preview = await client.pruneSnapshots({ ...policy, dryRun: true });
console.log(`would delete ${preview.snapshotIds.length}:`, preview.snapshotIds);

await client.pruneSnapshots({ ...policy, dryRun: false });

Three rules that matter more than the numbers:

Deletion requires both conditions. A snapshot goes only if it is both outside the newest keepLatest and older than before. A quiet week cannot age out your entire history.

Dry-run first, every time. Print what would go before anything goes. Retention bugs are silent — you discover them when you reach for a snapshot that a date-arithmetic error removed months ago.

Run pruning from somewhere other than the machine being backed up. If the credential that writes backups can also delete them, a compromised server can erase your recovery. Separate the two — this is the core idea in immutable backups.

One current caveat: retention applies across a whole workspace rather than per source, so keepLatest counts every snapshot in the workspace. If you back up two systems into one workspace nightly, keepLatest: 30 gives you 15 days of each. Keep workloads with different retention needs in separate workspaces.

Deleting data on request

There is a genuine tension between "keep backups for a year" and "delete this person's data on request," and it is worth knowing the shape of the answer.

The general position from data protection authorities is that backups may retain personal data until the backup rotates out naturally, provided you can show that the data is frozen — not used, not restored into production — and that erasure is re-applied if a restore happens. Rewriting historical backups to remove records is generally not expected and would destroy their integrity.

What that means in practice: document the retention period, log erasure requests, and make re-applying pending erasures a step in your restore runbook. Talk to whoever owns compliance before writing it down as policy — this is a summary of a common position, not legal advice.

Common questions

Is 7 days enough? Only for data you would notice losing within a day, like dev environments. For production it leaves you with nothing when a problem surfaces late.

Should I keep backups forever? Rarely useful and it accumulates liability. Data you hold is data you must protect and may have to disclose. Keep what has a reason.

How many restore points for a 1-hour RPO? Hourly backups plus GFS: 48 hourly, 14 daily, 8 weekly, 12 monthly. Deduplication is what makes that affordable — see RPO vs RTO.

Does deleting old snapshots corrupt newer ones? Not in a reference-counted system. Chunks still referenced are kept automatically.

Start with the free tier: backupdata.io has 5 GB free, no card, and the 10-minute quickstart gets you to a first verified snapshot today.