saved.sh, backups you actually own

A backup is a definition, not a copy. It says what to take, where it runs, how often, and how long the results are kept. Each execution is a run, and a successful run produces an artifact.

Kinds

Kind is chosen when the backup is created and cannot be changed afterwards. It decides who connects to your data.

Kind	We connect	You run a worker	Source credential
`local`	No	Yes	Stays on your machine
`cloud`	Yes	No	Held in our vault
`manual`	No	No	There is no source, you upload

Kind is immutable because changing it would silently move a credential across a trust boundary. Create a second backup instead.

Source types

Type	`local`	`cloud`	Status
`postgres`	Yes	Yes	Available
`web`	Yes	Yes	Available
`script`	Yes	Never	Available
`file`	Yes	Never	Available
`folder`	Yes	Never	Available
`redis`	Yes	Yes	In progress
`s3`	Yes	Yes	In progress
`gdrive`	No	Yes	In progress
`onedrive`	No	Yes	In progress

Three of these are local-only, permanently, and it is worth knowing why:

script runs a command you wrote. Running arbitrary customer scripts in our cloud is a sandboxing and abuse problem we are not taking on. It is also the most useful type in the list: it lets you back up anything we have no connector for, on your own hardware, with no work from us.
file and folder are your own filesystem. There is nothing for our cloud to connect to, and a remote copy of your disk would be a different product with a different trust story.

Submitting one of these as a cloud backup is refused, naming the type you sent.

Schedules

Standard cron, in the timezone you set on the backup:

schedule: "0 2 * * *"      # 02:00 daily
schedule: "0 3 * * 0"      # 03:00 Sundays

"02:00" means 02:00 somewhere. Set the timezone explicitly if it matters, and remember that daylight saving makes one local hour happen twice a year and another not at all.

If a run is still going when the next one is due, the schedule does not stack a second run on top of it. A backup that consistently overruns its interval is a backup whose schedule is wrong.

Retention

Two independent rules. An artifact is removed when either says so:

retention:
  keepLast: 10        # keep the 10 most recent
  expireAfter: 90d    # and nothing older than 90 days

Retention is the only setting that bounds what you store, and therefore what you are billed for archive. A backup with no retention keeps everything forever.

Protection

lockFor protects artifacts for a window during which nothing can delete them, not retention, not the API, not an intruder with a valid credential.

retention:
  keepLast: 10
  lockFor: 30d

The lock is stamped onto each artifact when it is archived, so changing the policy affects future artifacts, never existing ones. That is what makes it a protection rather than a setting.

Runs

Run history is read live rather than mirrored into a database, which has one consequence worth stating: history is available for the last 30 days. Beyond that window the run is gone even though the artifact it produced is not. When a listing comes back empty, it says so rather than implying nothing ever ran.

Backups in depth