Local backups

A local backup runs on a machine you own. Your worker connects to the source, produces the dump, encrypts it, and uploads ciphertext. We schedule the run and record what happened.

This is the stronger of the two connected kinds, and the one to prefer whenever you can run a process.

The data path

your worker: dump → encrypt → checksum → upload
        us:                                  ↳ inspect → compress → deliver → finalize

The crucial line is the second one. A local backup is encrypted before it leaves your network, by the worker, with a public key you put in its config. Our side of the pipeline never holds a key that could open it.

What we send the worker

Three identifiers: the workspace, the backup, and the run. That is the whole payload.

No credentials, no source configuration and no data travel to the worker, because they never came from us. It resolves the backup ID against its own config.yaml and works from there. A backup with no matching entry fails with ConfigDrift rather than guessing.

Configuring one

A local backup is configured in two places, and both are required.

On our side, the definition says which worker runs it and how often:

workers:
  - name: prod-worker-1

backups:
  - name: prod-db
    kind: local
    source_type: postgres
    worker: prod-worker-1
    schedule: "0 2 * * *"
    retention:
      keep_last: 10
      expire_after: 90d

On the worker, keyed by the backup ID, the source itself:

backups:
  "<backup-uuid>":
    source_type: postgres
    source:
      database: app
      host: db.internal
      password: "<password>"

See worker configuration for every field each source type accepts.

Source types

All eight local types, including the three that exist nowhere else:

script, file and folder are local-only permanently. script runs a command you wrote, and we are not taking on the sandboxing and abuse problem of executing customer commands in our cloud. file and folder read your filesystem, which does not exist in our cloud at all.

That makes script 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.

Routing

A local backup must name a worker, and its runs go only to that worker's queue.

• If the worker is offline, runs queue until it returns. They are not redistributed, because no other machine has the credentials.
• Changing the worker recreates the schedule, so the change takes effect from the next fire.
• One backup, one worker. To spread load, provision a second worker and split the backups between them.

What it costs you

The honest trade, stated in both directions.

The second row of the right-hand column is the one people underestimate. A worker with a full disk fails every run, and it fails at the dump step, which is the most expensive place to fail.

Next