Your backup vendor should be optional

Every backup product asks you to trust it twice. Once with your data, which everyone talks about, and once with your ability to get the data back, which almost nobody does.

The second one is the dangerous half. A backup you can only open by logging into a vendor is not a backup of your data. It is a backup of your relationship with that vendor. If the company is acquired, changes its pricing, has an outage on the day you need it, or simply goes away, the bytes may still exist and be no use to you at all.

So we wrote down how to open a saved.sh artifact without saved.sh, and we put it in the documentation rather than in a support macro.

The pipeline has no proprietary step

An artifact is produced by three operations, in this order:

dump → compress → encrypt → upload

That is the whole format. There is no saved.sh container, no custom codec, no metadata sidecar you need from our API to make sense of the bytes. Reversing it is the same three steps backwards, with tools that are already on your machine:

gpg --decrypt prod-db.sql.gz.gpg > prod-db.sql.gz
gunzip prod-db.sql.gz
psql -d mydb -f prod-db.sql

Three commands, none of them ours.

This is a constraint, not a feature we added

It would have been easier to invent a format. A container with an index makes partial restores fast, makes deduplication tractable, and makes a nice diagram. It also makes us load-bearing, and being load-bearing was the thing we were trying to remove.

The same logic drove the encryption design. Data is encrypted on the machine that produced it, with a public key you supply, before anything is uploaded. We hold ciphertext and the public half. That has a consequence we state plainly rather than bury:

We cannot decrypt your backups. If you lose your private key, neither of us can recover your data.

That sentence costs us support tickets. It is also the only version of "we cannot read your data" that means anything; every other version is a promise not to look.

The part that is actually hard

The technical side is the easy half. The hard half is that a backup nobody has ever restored is a hypothesis, and the procedure above is worth performing once, deliberately, on a normal Tuesday, against a scratch database, with the CLI logged out.

Two failures only ever surface under that kind of pressure, and both are silent until then:

• A private key nobody actually kept. It was generated on a laptop that has since been reimaged, or it lives in a password manager only one person could open.
• A dump that no longer fits. The schema moved on, an extension is missing, the target Postgres is two majors ahead.

Neither is caught by a green tick in a dashboard. Both are caught by a rehearsal that takes twenty minutes.

What we are actually promising

We think there are two separate promises in a backup product, and vendors routinely blur them:

The second row is the one worth choosing a vendor on. Ask anyone you are evaluating to show you their version of this page. If they cannot, the answer is already interesting.