Cloudflare D1 Backup vs Restore: Check Bookmark and Retention Before You Touch

For Cloudflare D1 backup, the first decision is whether one small example can be reviewed by a person. Cloudflare D1's Time Travel keeps 7 days of retention on the Free plan and 30 days on the Paid plan — and a restore cancels every query in flight, so the decision table you fill out before you click restore matters more than the restore itself.

Three-line answer first: Time Travel is not a backup, it’s a point-in-time rewind built into D1. A restore replaces your current database state and can be undone with the bookmark it returns. Retention length decides how far back you can go — 7 or 30 days, nothing more, nothing less. If you need something that survives past that window, or a copy that lives independently of the live database, Time Travel is the wrong tool.

I have not run an actual production restore on a live D1 database. This article documents the mechanism from Cloudflare’s own reference page (checked 2026-09-09) and gives you a decision table to fill in before you touch anything. Anyone advising you to just try it on production without checking the bookmark first is skipping a step that costs nothing.

Verified run

Command: npx --yes wrangler d1 time-travel info builderlog-mailbox
Environment: Darwin 25.5.0 / python 3.14.7
Ran at: 2026-09-12T00:31:01+09:00
Exit code: 0

⛅️ wrangler 4.129.0 (update available 4.131.1)
───────────────────────────────────────────────
Resource location: remote 

🚧 Time Traveling...
⚠️ The current bookmark is '00000150-00000000-000050e3-e07c569c42b5f42f6ca338dc20e6e6d3'
⚡️ To restore to this specific bookmark, run:
 `wrangler d1 time-travel restore builderlog-mailbox --bookmark=00000150-00000000-000050e3-e07c569c42b5f42f6ca338dc20e6e6d3`

The block below is the captured output of that run, pasted unchanged. A different environment can produce a different result.

What Time Travel actually does

Cloudflare enables Time Travel automatically on supported D1 databases. No setup, no toggle. It’s always running in the background, capturing enough history to rewind the database to a previous point.

Two plan tiers, two retention windows:

That’s the entire ceiling. This is the first thing to check before you plan anything else — not the restore command, not the target time, the retention window.

Time Travel restores state, it doesn't preserve a copy — check retention before you assume you have options.

Why a restore is not the same as a backup

This distinction sounds pedantic until you’re mid-incident. A restore against D1 with Time Travel:

• Affects the current database directly — there is no separate destination
• Cancels in-flight queries the moment it executes
• Can be reversed using a previous bookmark returned by the restore itself

None of that resembles a backup-and-clone workflow. A backup implies a second, independent copy sitting somewhere safe. Time Travel is a rewind mechanism for one database, not a duplication mechanism. If your mental model is “I’ll restore into a clone to test it first,” that’s not what this does per the official reference. If you need an actual duplicate for testing or migration, that’s a separate mechanism entirely — check current Cloudflare docs for what that looks like in your setup, because this article isn’t the place to guess at it.

The decision table

Here’s the table I’d fill in before running any restore command, on paper or in a doc, before touching the CLI:

Six fields. None of them require code. All of them require you to stop and write something down instead of running the command from memory.

Writing down the current bookmark before you restore is the only rollback plan you get.

Where this fits with “Cloudflare D1 backup” as a search term

Google autocomplete surfaced the exact query “Cloudflare D1 backup” on 2026-09-09. That’s a wording signal — people are searching for backup and finding Time Travel documentation instead, because D1 doesn’t currently ship a separate named backup product in the way some databases do. If you came here searching “D1 backup” and expected a distinct backup feature, this is the honest answer: Time Travel is the built-in mechanism, and it’s a restore/rewind tool, not a clone-and-store tool.

That gap between what people search for and what the product actually offers is worth sitting with for a second. If your operating requirement is “I need an independent copy I can query without touching the live database,” Time Travel’s retention table doesn’t answer that. You’d be looking at exporting data separately, on whatever cadence your reliability requirement demands — and that’s outside the scope of what’s verified here.

Failures and limits, stated plainly

• I have not performed a live restore test on a production D1 database. Nothing here is a report of “it worked” or “it broke.”
• Retention numbers (7 days Free, 30 days Paid) come directly from Cloudflare’s Time Travel reference page, checked 2026-09-09. Confirm current numbers against the live docs before you rely on them — plans and limits change.
• Autocomplete matching a query wording does not tell you volume, difficulty, or how many people actually need a separate backup vs. a restore.
• This table doesn’t cover multi-region, multi-database, or CI/CD-triggered restore scenarios. Your runtime and project configuration are yours to verify.

Final decision, and where the Saju license fits (or doesn’t)

If you run D1 and haven’t hit an incident yet, the decision is simple: know your plan tier, know your retention window, and keep the decision table somewhere you’ll actually find it during an incident — not buried in a wiki you haven’t opened in months.

Separately, and only as an aside: the Saju web-app source license I maintain (a Korean fortune-telling web app, sold as source for one project) runs on infrastructure choices a buyer makes independently — D1 usage, retention plan, and backup strategy aren’t part of what the license configures for you. If you’re evaluating that product, check the product page for current deliverables and installation requirements rather than assuming this article’s D1 mechanics apply automatically to that stack.

Related build logs

• Cloudflare Workers Compatibility Date Upgrade: A Checklist Before You Change It
• AI Table Totals Need a Human Review Before You Compare

Limits and stop rule. This bounded example cannot establish every tool, data, permission, or maintenance condition. Stop when the input is sensitive, the expected output is unclear, or a person cannot review the result.

Reusable checklist.

• State the input and expected output.
• Mark the source, uncertainty, and human check.
• Keep a manual fallback and a stop condition.