saved.sh, backups you actually own

A backup you can only open through a vendor is a dependency, not a backup. This page exists so that sentence is testable.

Everything below uses tools already on your machine. None of it involves us.

What an artifact is

An artifact is an ordinary file, produced by a pipeline with no proprietary step:

dump → compress → encrypt → upload

Reversing it is the same three steps backwards. There is no saved.sh container format, no custom codec, and no index we hold that you need.

1. Get the bytes

While you have an account, the fastest route is the dashboard or the CLI:

saved artifact download <artifact-id> --output ./prod-db.sql.gz.gpg

If you have neither, you still have the object. Artifacts live in object storage you can read directly: the same bucket, the same credentials, listed and fetched with any S3 client.

Downloads keep working in every billing state, including a suspended account. This is a deliberate promise: your backups are never leverage.

2. Decrypt

With the private key you generated, the half we never had:

gpg --decrypt prod-db.sql.gz.gpg > prod-db.sql.gz

If this key is gone, stop. There is no recovery path, no support request and no override. We store ciphertext and we do not have your key. Verify you still hold it before you need it.

3. Decompress

Whatever the backup declared. Gzip is the default:

gunzip prod-db.sql.gz

4. Restore

Now it is a plain dump, and the tool that made it is the tool that reads it:

psql -d mydb -f prod-db.sql

Do this on a normal day

The procedure above is worth performing once, deliberately, while nothing is wrong, against a scratch database, on a laptop, with the CLI logged out.

That rehearsal is what turns a backup into a recovery plan. It also catches the two failures that only ever surface under pressure: a private key nobody actually kept, and a dump that restores into a schema that has since moved on.

Recover by hand