Backup and restore

How it works

DevBench holds two kinds of thing, and only one of them has a home already. Every workspace's repos live at GitHub or GitLab; the only code at risk is whatever is sitting uncommitted on a container volume. Everything else, the workspaces, the repos each imports, the git flow, the environments, the deploy recipes, the shared tools, the agents, the watchers, the schedules, exists in one database, and re-entering it by hand is days of work nobody has a record of.

So a backup runs in two halves, in this order:

1. Push. Every eligible workspace's repos are committed and pushed to their own branches, the same call the Push button uses. A stopped box can be started for it. An info-only workspace is skipped, because "nothing is ever pushed from here" is a promise the product makes and a backup is not a reason to break it.
2. Record. The configuration is serialized to gzipped JSON, with each repo appearing as the branch and commit its work was pushed to. The repository contents are never in the file.

That ordering is what makes the size claim true: a hundred workspaces come out as a few hundred kilobytes rather than tens of gigabytes. Small enough that every backup is kept and nobody has to decide which to throw away. What is deliberately not in it, git objects, container images and volumes, and every kind of history, is recorded as a count, so a file opened a year from now says plainly what it is not.

Secrets are off by default. Turned on, each secret travels as the ciphertext already in the database; the plaintext is never written. So a backup with secrets is only usable on an install holding the same encryption key, which is the property that makes it safe to leave one in a bucket.

Restoring

The dry run is the default, and it is performed with the same walk as the real restore, inside a transaction that is thrown away. A dry run whose logic has drifted from the real thing is worse than none, because it is believed.

It is also the diff: comparing two DevBench instances is exactly "restore this file into that org and tell me what moves", answered in both directions.

Three rules hold everywhere:

• Nothing is ever deleted. Something the target has and the backup does not is reported and left alone.
• Merge is the default. Existing rows are untouched unless you ask for overwrite. Restoring twice changes nothing the second time.
• Code is not restored, because it was never taken. A restored workspace points at the same repository and branch; its box is provisioned as normal.

What cannot come back is reported rather than skipped in silence: user accounts (members are matched to accounts that already exist and the rest are listed as people to invite), other people's git tokens, the inbound webhook secret, media file bytes, and, if the file was taken without secrets, or this install holds a different encryption key, every credential. A wrong key is detected up front by test-decrypting one value, so it is reported once instead of field by field, and the rest of the configuration still restores.