---
title: "Your backup vendor should be optional"
description: "We publish the procedure for opening a saved.sh artifact without saved.sh, with no account, no CLI, and no us."
url: "https://saved.sh/blog/recover-without-us"
date: "2026-08-03"
author: "saved.sh"
tag: "Engineering"
---

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 [#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:

```bash
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 [#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-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 [#what-we-are-actually-promising]

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

| Promise                     | Ours                                                                                      |
| --------------------------- | ----------------------------------------------------------------------------------------- |
| Your data will be there     | Yes, and it is encrypted, retained under a lock, and outside your production blast radius |
| You will be able to read it | Yes, **and you do not need us to**                                                        |

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