What Backup and Disaster Recovery Looks Like for a Shared Database
17 apps and roughly 41 Workers share one D1 database — here's specifically what happens if it goes down, and what's actually been tested versus what's designed but unproven.
"What happens if your database goes down" is a fair question to ask any vendor whose product your business depends on, and it's a sharper question than usual for Piskes specifically, because the answer touches all 17 apps at once — they share one D1 database, not 17 separate ones. A single incident there isn't a one-app outage. That's exactly why the honest, specific answer matters more here than it would for a platform where each product has its own isolated datastore.
The mechanism, specifically
Backup for the shared D1 database runs on three layers, not one:
Daily export to R2. A dedicated backup worker runs a daily job that exports the database to compressed JSONL and writes it to R2 object storage, with a 90-day retention window. This is the durable, off-database copy — if D1 itself had a catastrophic failure, this is the backup that exists independent of D1's own infrastructure.
D1's own Time Travel. Separately, D1 has a built-in point-in-time recovery feature with a 30-day window, maintained by Cloudflare at the platform level rather than by Piskes's own backup worker. This covers a different failure mode than the daily export — a bad migration or an accidental bulk delete that needs to be rolled back to a specific point in time, not necessarily a full disaster.
R2 versioning. A separate worker handles versioning for the R2 bucket the backups themselves land in, which protects the backups from being silently overwritten or corrupted at the storage layer — a backup system that can lose its own backups isn't actually a backup system.
What's been tested, and what that means
A backup system nobody has ever restored from is a backup system with an unknown failure mode — the export could be silently malformed, the restore process could be broken, and nobody would know until the day it matters most. Piskes has run one documented restore drill against this system — an actual practice restoration, not a design review of whether the restore process should work in theory. That's a meaningfully stronger claim than "we have backups configured," but it's also honest about being one data point, not a routine, repeatedly-exercised muscle yet. A single successful drill demonstrates the mechanism works; it doesn't yet demonstrate it reliably works every time, across every kind of failure the system might face.
A separate system that's worth not confusing with this one
There's a second, entirely different backup path in this platform, and conflating the two would be a mistake a careful reader should be able to catch: the Go backend, which still serves some domains directly rather than through D1, has its own backup mechanism for its own SQLite database — a daily snapshot via VACUUM INTO, uploaded to a dedicated R2 bucket, with its own retention pruning. It's gated on its own set of environment variables, and without them configured, the scheduler logs a warning and does nothing rather than failing loudly.
These are two different systems protecting two different datastores for two different parts of the platform. The D1 backup path above covers the shared database that 17 apps and most Workers write to. The Go-backend path covers only the SQLite database behind the domains still served by the Go API. A deployment where one is configured and the other isn't is a real, plausible state — and a diligence question aimed at "is Piskes's data backed up" needs to be specific about which datastore it's asking about, because the answer isn't the same for both.
What this means for an evaluator
The shared D1 database — the one that matters to essentially every app — has real, layered backup: a daily off-platform export with 90-day retention, native point-in-time recovery for 30 days, and versioned storage for the backups themselves, validated by at least one real restore drill. That's a concrete, checkable answer, not a bullet point. What it isn't yet is a routinely rehearsed disaster-recovery process with multiple proven drills behind it — worth asking about directly if backup maturity is part of your evaluation, rather than assuming either extreme.