Back up, observe, and recover

The moment to design recovery is before the destructive mistake, because during one you will be typing fast with bad information.

D1 gives you two recovery tools. Time Travel can restore a database to an earlier point in time, using its built-in change history:

npx wrangler d1 time-travel info my-app-db
# 🚧 Time Travel is currently active
# ⏳ Earliest restorable bookmark and timestamp shown here

The other is a plain SQL export you own:

npx wrangler d1 export my-app-db --remote --output=backup-2026-08-03.sql

The export is a file on your side — store it where your other backups live. D1’s time-travel and backup capabilities evolve with the platform, and retention windows differ by plan, so check current retention and command documentation rather than copying an old number into the runbook. A runbook that says “we have 30 days” is only true until the plan or the product changes.

Restore into a separate target first

A restore is itself a destructive operation when pointed at the wrong place. Test recovery into a separate target before replacing good production data:

npx wrangler d1 create my-app-db-restore-test
npx wrangler d1 execute my-app-db-restore-test --remote --file=backup-2026-08-03.sql
npx wrangler d1 execute my-app-db-restore-test --remote \
  --command 'select count(*) from notes'

Now you know the backup actually restores, how long it takes, and what the row counts should look like — while production keeps running untouched. An untested backup is a hope, not a plan.

Observe without leaking

Log operation, duration, safe request ID, and failure class — never row contents or credentials. note.create failed: UNIQUE constraint is diagnosable; logging the note body is a data leak waiting for a log-access review. Monitor query latency, errors, storage size, and your position against current limits, and alert on the trend, not just the outage: a database growing toward a storage limit is a Tuesday problem or a 3am problem depending on when you notice.

Now run the full drill on a practice database: create disposable data, record a recovery point, make a destructive change like dropping a table, and restore or clone according to current official instructions. Time yourself — that number belongs in the runbook.