Backup and restore runbook

This is an operator runbook, not a built-in disaster-recovery service. The repository does not provide a one-command full CMS backup/restore. A native site-bundle copy is not a restore: it copies supported current content with new IDs, not the installation’s complete historical and account state. A history transfer adds kept versions and workflow events, but it also uses new IDs and carries no accounts, credentials or audit log, so it is not a restore either.

Define the recovery set

Record the exact CMS source revision, migration history, deployment bindings and a mapping from every site ID to its content database and media storage. Include the control database and every assigned content database, not only the currently selected site. Keep configuration and secret recovery material under the deployment owner’s existing secure process, separate from content exports.

A database backup alone does not preserve the media files. Retain the referenced R2 objects or Cloudflare Images assets and the identifiers needed to serve them. Include generated repositories and owned code when recovering detached backends. A published snapshot intentionally omits drafts, CMS accounts and version history and cannot replace a CMS backup.

Capture a consistent backup

Arrange a pause in writes with the operator, including scheduled publishing, imports and other processes that write data. Capture each database using the provider’s supported consistent export/backup facility, or a SQLite backup operation for local databases. Do not copy a live SQLite file while ignoring its WAL. Record when each part was captured and protect the matching media and configuration set before resuming writes.

Verify that exports are readable and nonempty, that every expected database/site is represented, and that media references resolve to retained bytes. Store a protected inventory with checksums. Retention periods and provider-specific export/restore commands are not established by this source snapshot. The deployment owner must verify those against the actual account before relying on a backup.

Restore into isolation first

Use a separate, explicitly authorized environment. Restore matching database, migration, configuration and media state without binding the restored installation to another site’s live database. Keep cron jobs, outbound webhooks and build delivery disabled until review: restored pending work may otherwise repeat effects in external systems. Do not assume old sessions or old external credentials should be reactivated.

Start the matching source revision and verify database migrations before any upgrade. Then check administrator access, site ownership, roles, private-model refusals, model definitions, drafts, published versions, translations, relations and media. Compare per-site/per-model counts and representative records to the retained inventory. A successful SQL import alone is not successful recovery.

Cutover and rollback

Obtain owner acceptance before routing production traffic. Keep the previous environment and recovery set intact until the restore is accepted. Re-enable background processes that write data and delivery to external systems only after reviewing pending jobs and checking how they handle repeated requests. For detached deployments, also run the deployment and media verification steps.

Authorities and boundaries: backend/src/lib/import/bundle-handlers.ts explicitly implements copy, not native restore. backend/src/lib/graduate/source-db.ts uses a SQLite backup operation. scripts/d1.ts contains guarded D1 export behavior. Do not use a destructive teardown command merely to obtain a backup. See migration for source-system cutover.

---

Unreleased / pre-MVP; no stable version
Source revision: fe23db481c422b40e317b92fc98116b4c0c26a87 (modified checkout)
Build date (UTC): 2026-10-18T09:22:34.630Z
Upgrade target: unavailable: modified checkout. Release notes