Backup and recovery
D1 Time Travel, exports, R2 lifecycle, and master-key custody.
D1 is Tasuku's durable source of truth; R2 holds the blobs D1 references. A usable recovery set requires the database and its exact master key — the master key is never stored in D1 or R2.
D1 Time Travel
D1 keeps a 30-day continuous change history automatically, with no explicit backup step required for point-in-time recovery within that window:
bunx wrangler d1 time-travel info tasuku
bunx wrangler d1 time-travel restore tasuku --timestamp=<ISO-8601-timestamp>Time Travel restores the database to a bookmark or timestamp; it does not touch R2 or the master key, and it does not run as a copy — read wrangler's output carefully before restoring against a database still receiving traffic.
Manual exports
For a portable snapshot outside Time Travel's 30-day window, or before a risky migration:
bunx wrangler d1 export tasuku --output=tasuku-backup.sqlStore the exported SQL somewhere outside the Cloudflare account (D1 already durably replicates within Cloudflare; the value of an export is an independent copy and a longer retention window than Time Travel provides).
R2 lifecycle
The tasuku-artifacts bucket holds run artifacts, workspace-changes diffs, output files, and sealed run requests. Sealed run requests (runs/{run}/{attempt}/request.enc) are working state for an in-flight attempt, not something to back up — Tasuku does not configure any R2 lifecycle rule itself, so set a 24-hour expiration rule for the runs/*/*/request.enc prefix yourself (wrangler r2 bucket lifecycle or the dashboard) if you want them cleaned up automatically. Everything else in the bucket (published artifacts, output files kept for the work item's lifetime) is durable object storage and does not need a separate backup step beyond R2's own durability; configure a bucket-level lifecycle policy only if you want to prune old artifacts.
Master key custody
Back up, separately from the D1 export:
- the exact active
TASUKU_MASTER_KEY; TASUKU_MASTER_KEY_VERSION;- every entry in
TASUKU_PREVIOUS_MASTER_KEYS.
Git repositories remain in GitHub — Tasuku never stores repository content — but review history, workflow events, sealed credentials, repository settings, feedback, and learnings exist only in D1 and R2.
Key mismatch is not recoverable from ciphertext
If a restored database was encrypted under a different master key, Tasuku cannot reconstruct the plaintext credentials. Restore the correct key rather than replacing encrypted rows with guesses.
Restore
- Restore D1 with Time Travel (fastest, within 30 days) or by re-importing a manual export.
- Restore the matching active and previous master-key ring exactly, as secrets on the Worker.
- Redeploy the Worker so the
MigratorDurable Object re-checks migration state (GET /readyz). - Verify
/healthzand/readyz. - Verify OAuth, GitHub App identity, repository synchronization, secret fingerprints, and one controlled workflow run.
In-flight work
Job leases and workflow attempts are recoverable by design: the Scheduler Durable Object reclaims expired leases and RunAttemptWorkflow retries or restarts an attempt automatically. Before manually replaying a command after a restore, inspect the run's workflow events for an external effect — a GitHub comment, review, branch, or pull request — that already completed before the point you restored to.