Skip to content

Step 13 — Backups, and restoring from one

About 30 minutes. Branch: step-13.

The one new idea: a bundle is the database plus the drives plus a manifest, and exactly one is taken for you.

Take one first

mecca app backup tally -d "before the tag column" -b tutorial
mecca app backups tally -b tutorial

The description is not decoration. In six weeks, before the tag column is the difference between confidence and guessing.

A bundle is one consistent moment across everything. Not a database dump — the database, every declared drive, and a manifest describing what was taken. Restoring gives you back a coherent state, rather than a database that has forgotten what the files were doing.

Then change the schema

backend/migrations/002_tags.sql @ step-13
ALTER TABLE items ADD COLUMN IF NOT EXISTS tag TEXT;

Deploy. entrypoint.sh applies it, mecca logs --type container shows applying 002_tags.sql, and the API starts returning the new field.

This migration is deliberately safe

It adds a nullable column and destroys nothing, so the restore you are about to practise is a drill, not a rescue — which is exactly when to practise it.

The migrations that genuinely need the backup are the other kind: DROP COLUMN, a NOT NULL added to existing rows, a type change that will not round-trip. Take the backup before those every time — and before ones like this too, so the habit is not conditional on your judgement of the risk.

Practise the restore

mecca app restore tally <bundle-prefix> -b tutorial

The board comes back as it was: no tag column in the data, the pre-migration rows.

The one backup that is taken for you

A restore takes a safety backup first, automatically. It is the only automatic backup on the platform.

In particular: there are no scheduled backups. Nothing takes a nightly copy on your behalf. If you want one before every schema change, it is your command that takes it. That is the sentence to remember from this step.

Redeploy afterwards and 002_tags.sql applies again — the migration runner recorded nothing in the restored database, so it does the right thing.

The rest of the surface

mecca app backups tally -b tutorial                     # list
mecca app download tally <prefix>  # pre-signed URLs
mecca app restore tally <prefix> --db-only -b tutorial  # database only
mecca app restore tally <prefix> --drives-only -b tutorial
mecca app backup-delete tally <prefix>

--db-only and --drives-only matter when only one half is wrong and overwriting the other would lose good work.

Backups outlive the app. Deleting an app does not delete its bundles, which is occasionally the difference between an inconvenience and a disaster.

If it didn't work

Symptom Try Usually
Backup seems to hang mecca queue list It is a queued action like any other
Restore ran, data unchanged mecca app backups Restored a bundle taken after the change
A drive was not restored check --db-only The flag limited it
Nothing to restore mecca app backups -b <branch> Bundles are per branch, and a branch is its own app

Reset to the reference

git fetch upstream && git reset --hard upstream/step-13 && git push --force origin tutorial

Next: Step 14 — Rolling back, and a deliberate disaster