saved.sh

Introduction

What saved.sh is, and the one idea the whole product is built around.

saved.sh keeps copies of your data outside the system that produced it, so that losing production does not mean losing the backup too.

That sentence is the entire product. Everything below is a consequence of it.

The problem it solves

Most backups share fate with the thing they back up. A snapshot lives in the same cloud account. A replica answers to the same credentials. A nightly dump written to the same object store is reachable by anything that reached the store.

That is fine for the failure people plan for (a dropped table, a bad deploy) and useless for the one they don't: an attacker, a departing employee, or an automation with more permission than anyone realised. Whoever gets your production access gets the backups too, which is precisely the moment the backup was supposed to matter.

A copy is only external if it is under different keys, in different storage, on a different trust boundary, and the compromised system has no route to it and no permission to delete it.

How it fits together

Workspace

The tenant. Members, permissions, quotas and billing all belong to one workspace, and nothing crosses between them.

Backup

A definition: what to copy, on what schedule, kept for how long. Not the copy itself.

Run

One execution of a backup. Succeeds or fails, and says which.

Artifact

What a run produced. Encrypted, sized, retained under a policy, and downloadable.

Worker

A credential that lets a machine you control claim work. Not a machine: several processes may share one.

Where a backup runs

This is the choice that decides who holds your credentials, and it is made per backup.

KindWho connects to the sourceWhere the credential lives
LocalA worker on your hardwareYour machine, in the worker's own config. Never sent to us
CloudWe doOur vault, read at run time
ManualNobody, you uploadThere is no source

Local is the stronger position and the one to prefer when you can run a worker. Cloud exists because sometimes you would rather we connected than stand up a process, and that is a legitimate trade as long as it is explicit.

What we can and cannot do

Being unable to read your data is a feature, and it cuts both ways.

  • Data is encrypted on the machine that produced it, with a public key you supply, before anything is uploaded. We store ciphertext.
  • We never hold the private half. We cannot decrypt your backups, and we cannot recover them if you lose your key.
  • Bulk data moves directly between your machine and object storage. Only metadata passes through our orchestration.
  • Artifacts are self-describing, so you can unpack one by hand with no account and no CLI.

Next

On this page