---
title: "Your backups are probably in the blast radius"
description: "Snapshots, replicas and nightly dumps all tend to share credentials with the thing they protect, which makes them useless against the failure people actually fear."
url: "https://saved.sh/blog/backups-in-the-blast-radius"
date: "2026-08-02"
author: "saved.sh"
tag: "Security"
---

Ask an engineer whether their database is backed up and the answer is almost always yes. Ask
*where the backup lives* and *what can delete it*, and the answer gets much quieter.

## Three backups that are not external [#three-backups-that-are-not-external]

**Cloud snapshots.** Automated, cheap, restorable in a click. They also live in the same
cloud account, governed by the same IAM, deletable by anything that can call the same API.
An access key with broad permissions deletes the database and its snapshots in two calls.

**Read replicas.** Excellent for availability, useless as a backup. A replica's job is to
faithfully reproduce whatever happened upstream, including `DROP TABLE`, including an
encrypted-in-place ransomware run. It replicates the disaster with impressive latency.

**Nightly dumps to object storage.** Closer, and the most common "we're fine" answer. But
the dump is usually written by a job running in production, with credentials held in
production, to a bucket in the same account. Everything that reached production reaches the
bucket.

None of these are bad. They are all excellent at the failures people plan for: a dropped
table, a bad migration, a corrupted disk. They are all in the blast radius of the failure
people fear.

## The failure they miss [#the-failure-they-miss]

The scenario that actually ends companies has a shape:

1. Someone gets credentials: phished, leaked in a repo, taken from a compromised laptop, or
   simply held by a person who is leaving angry.
2. They have, or can escalate to, permission over the storage layer.
3. They destroy or encrypt the primary **and** everything the primary's credentials can
   reach.

Step three is the whole attack. Modern ransomware operators go looking for backups first,
because they know the ransom is only payable if the backups are gone. A backup reachable
with production credentials is not a second copy; it is the same copy, stored twice.

## What "external" has to mean [#what-external-has-to-mean]

A copy is only genuinely external when all four of these hold:

* **Different credentials.** Nothing in production can authenticate to it.
* **Different storage.** Not the same account, and ideally not the same provider.
* **Different keys.** Encrypted with a key production never had.
* **No delete path.** Even a valid credential cannot remove it inside its retention window.

The last one is the one people skip, and it is the one that matters under attack. Retention
that a sufficiently privileged API call can override is a preference, not a protection. It
has to be a lock with a clock on it, a window during which deletion is refused, no matter
who asks or what permissions they hold.

## The test worth running [#the-test-worth-running]

Forget the vendor comparison for a moment and ask one question about whatever you run today:

> If someone had full administrative access to my production environment right now, and
> wanted to destroy every copy of this data, how far would they get?

If the answer is "all of it", the number of backups you have is not the relevant number.

That question is why saved.sh runs the way it does: the worker holds its own credential on
your hardware, the data is encrypted before it leaves with a key we never see, and artifacts
are written under a retention lock that we cannot override for you, which also means we
cannot override it for anyone claiming to be you.

If you want the longer version of that last part, we wrote about
[why your backup vendor should be optional](/blog/recover-without-us).