Your backups are probably in the blast radius

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

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

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

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.