README: backup section — every database needs its own backup, plus WAL and restore caveats

The What to Backup list named all six SQLite files, but nothing said
backup tools operate per-file — a single Litestream dbs: entry only
replicates one database. Add an explicit warning, a four-DB Litestream
example, a no-plain-cp-of-live-WAL-databases note, and a Restoring
subsection (align restore points across DBs; dicts are stored in-file
so each backup is self-contained). Also fix the sqlite3_rsync link to
the official SQLite utility page.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: dkam

README.md

@@ -582,17 +582,23 @@ Configure Uptime Kuma to send alerts via:
 
 ## Backup
 
-Splat uses SQLite databases. Two recommended backup strategies:
+Splat splits its data across **six separate SQLite database files**, and backup tools operate per-file — backing up `production.sqlite3` alone captures only projects and settings, not your errors, transactions, or logs. Every database you care about needs its own backup configuration.
+
+Two recommended backup strategies:
 
 **[Litestream](https://litestream.io/)** - Continuous replication to S3-compatible storage
 - Real-time backup with ~10-30 second lag
 - Supports AWS S3, Backblaze B2, Cloudflare R2, MinIO
 - Point-in-time recovery
+- Requires one `dbs:` entry per database file — a single entry replicates a single file
 
-**[sqlite3_rsync](https://github.com/cannadayr/git/blob/master/sqlite3_rsync)** - Efficient incremental backups
+**[sqlite3_rsync](https://sqlite.org/rsync.html)** - Efficient incremental backups (official SQLite utility)
 - Creates byte-for-byte clones of live databases
 - Works while database is in use
 - Smaller incremental transfers than full copies
+- Run it once per database file
+
+Do **not** back up a live database with plain `cp` or `rsync` — the databases run in WAL mode, and copying the `.sqlite3` file without a consistent snapshot of its `-wal` file produces a corrupt or stale copy. Use one of the tools above, or `sqlite3 <db> ".backup <dest>"`.
 
 ### What to Backup
 - `storage/production.sqlite3` - Application data: projects, settings, releases (critical)
@@ -602,6 +608,27 @@ Splat uses SQLite databases. Two recommended backup strategies:
 - `storage/production_cache.sqlite3` / `storage/production_cable.sqlite3` - Solid Cache / Cable (optional, regenerated at runtime)
 - `storage/tuber/` - Tuber's write-ahead log — only holds in-flight ingest jobs; not needed for a point-in-time restore
 
+Example Litestream config covering all four critical databases:
+
+```yaml
+# /etc/litestream.yml
+dbs:
+  - path: /app/storage/production.sqlite3
+    replicas: [{ url: s3://your-bucket/splat/production }]
+  - path: /app/storage/production_issues_events.sqlite3
+    replicas: [{ url: s3://your-bucket/splat/issues_events }]
+  - path: /app/storage/production_transactions_spans.sqlite3
+    replicas: [{ url: s3://your-bucket/splat/transactions_spans }]
+  - path: /app/storage/production_logs.sqlite3
+    replicas: [{ url: s3://your-bucket/splat/logs }]
+```
+
+### Restoring
+
+Restore all critical databases from (roughly) the same point in time. The issues/events, transactions/spans, and logs databases reference project IDs in the primary database, so wildly mismatched restore points leave rows pointing at projects that don't exist yet. There's no cross-file transaction to preserve, so second-level alignment is fine — just don't mix a week-old primary with today's events.
+
+Each backup is self-contained: the zstd compression dictionaries used for event and log payloads are stored inside the same database file as the rows they compress, so a restored file is always readable on its own.
+
 ## Model Context Protocol (MCP) Integration
 
 Splat exposes an MCP server that allows Claude and other AI assistants to query error tracking and performance data directly. As Splat has no authentication system, we'll use an environment set value for an authentication token.