Back up, observe, and recover

Design your recovery before the destructive mistake. During one, you’ll be typing fast with bad information.

D1 gives you two recovery tools. The first is Time Travel, which restores a database to an earlier point in time using its built-in change history:

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

The second is a plain SQL export you own:

npx wrangler d1 export notes --remote --output=backup-2026-08-03.sql

The export is a file on your side. Store it where your other backups live.

Be careful with retention. Time Travel windows differ by plan, and the tooling changes over time. Check the current docs instead of copying an old number into your 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. So test recovery into a separate database before you touch production:

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

Now you know three things. The backup actually restores, how long it takes, and what the row counts should look like. And production kept running the whole time. An untested backup is a hope, not a plan.

Observe without leaking

Log the operation name, the duration, a safe request ID, and the failure class. Never log row contents or credentials. note.create failed: UNIQUE constraint is diagnosable. The note body in your logs is a data leak waiting for a log-access review.

Monitor query latency, errors, storage size, and where you stand against the current limits. Alert on the trend, not just the outage. A database growing toward its storage limit is a Tuesday problem or a 3am problem, depending on when you notice.

Try this on a throwaway database: create some disposable data, record a recovery point, then drop a table on purpose. Restore or clone it following the current official instructions. Time yourself. That number belongs in the runbook.