Backups

Back up $TINY_DATA_DIR as one unit. Objects are not replicated, and snapshots are sibling directories on the same filesystem — so a lost host disk loses object storage along with any SQLite database beside it.

What lives under `$TINY_DATA_DIR`

Default: .tiny/control-plane.

Path	Contents
the control-plane SQLite file	organizations, apps, revisions, deployments, bindings, grants, audit, outbox
`artifacts/`	content-addressed uploaded and built artifacts
`databases/`	one SQLite file per environment
`storage/<environment>/<name>/`	object namespaces
`storage/.staging/`	in-flight writes; safe to exclude
instance state	runtime desired state, encrypted on the host

What lives outside it

TINY_SECRET_KEY — the root of every sealed connection credential and secret. Without it, a restored $TINY_DATA_DIR cannot decrypt any of them.

TINY_TOKEN_SECRET and TINY_SESSION_SECRET — losing these invalidates live sessions and tokens but is recoverable.

Guest images and the kernel — rebuildable, but keep the exact ones a rollback might need. See Guest images.

An external Postgres cluster, if you attached one. Its durability is the cluster’s own story, not Tinycloud’s.

Store TINY_SECRET_KEY somewhere separate from the data backup. A single archive containing both the ciphertext and its key is a single thing to lose.

Taking a consistent copy

The control-plane store is SQLite, so copy it the way SQLite wants to be copied rather than with cp on a live file:

sqlite3 "$TINY_DATA_DIR/control-plane.db" \
  ".backup '/backup/control-plane.db'"

rsync -a --exclude '.staging' \
  "$TINY_DATA_DIR/" /backup/tinycloud-data/

Exclude storage/.staging — those are in-flight writes that have not been renamed into place. Excluding them is correct, not a compromise.

For a stronger guarantee, take a filesystem snapshot (LVM, ZFS, or your provider’s volume snapshot) and copy from that.

What `tiny archive` covers

pnpm tiny archive my-app
pnpm tiny restore my-app

Archive snapshots resources before stopping the environments. It is a lifecycle operation, not a disaster-recovery strategy.

Covers	Does not cover
the app’s SQLite database (`VACUUM INTO`)	other apps
the app’s Postgres database (`pg_dump`)	the control-plane database
its object namespaces	`TINY_SECRET_KEY`
—	anything if the host disk is gone — snapshots are siblings on the same filesystem

Postgres snapshots require postgresql-client on the control-plane host. Without it, archiving an app with a Postgres database will not capture its data. Verify this before relying on it.

Restore does not deploy a worker — deploy again to resume traffic.

Deletion has a grace window

pnpm tiny delete my-app --confirm my-app

The --confirm value must be the exact slug, and deletion is scheduled after a seven-day grace window. That window is a recovery path, but it is not a backup.

Testing a restore

The only backup that works is one you have restored.

Restore onto a fresh host

Same TINY_DATA_DIR contents, same TINY_SECRET_KEY.

Start the control plane

pnpm api
curl https://…/v1/ready

Check that a sealed secret still decrypts

List connections and invoke one capability. That is the test that proves you kept the right key.

Redeploy an app and open it

Restored state does not serve traffic until a deployment runs.

Get started

Build apps

Operate

What lives under `$TINY_DATA_DIR`

What lives outside it

Taking a consistent copy

What `tiny archive` covers

Deletion has a grace window

Testing a restore

​What lives under $TINY_DATA_DIR

​What lives outside it

​Taking a consistent copy

​What tiny archive covers

​Deletion has a grace window

​Testing a restore

What lives under `$TINY_DATA_DIR`

What lives outside it

Taking a consistent copy

What `tiny archive` covers

Deletion has a grace window

Testing a restore