备份、分支与时间旅行

9.1 Turso 的默认备份

付费账户默认24 小时连续备份（Starter 层）或 30 天（Scaler 及以上）——无需你设置，底层每个 WAL frame 都存档到对象存储。可以 point-in-time restore 到窗口内任一秒。

免费层 没有自动备份——要依靠手动 db dump 或开付费版。

9.2 手动 dump

# dump 成 SQL 文本（含 CREATE + INSERT）
turso db shell my-app ".dump" > backup.sql

# dump 成二进制 .db（更快）
turso db shell my-app ".backup out.db"

SQL 文本适合 diff、git-friendly；二进制 .db 适合快速还原。

恢复 dump

# 从 SQL 还原
turso db create restored --from-file /dev/stdin < backup.sql

# 从 .db 还原
turso db create restored --from-file out.db

9.3 Point-in-Time Restore

付费账户能按时间戳创建 fork：

# 从 15 分钟前创建一个新数据库
turso db create rescue \
  --from-db production \
  --timestamp "2026-04-21T08:15:00Z"

得到的 rescue 是一个全新数据库，包含 production 在 2026-04-21 08:15 UTC 那一刻的全部数据。你可以：

1. 连上 rescue 确认需要的数据
2. 从 rescue dump 出感兴趣的行
3. 把行 INSERT/UPDATE 回 production

整个过程不影响 production 的读写。

9.4 Branch：数据库版本控制

Turso 把 fork 能力开放成常规操作——任何时刻可以"从 production 拉一个 branch"：

turso db create staging --from-db production
turso db create pr-123  --from-db production

# 临时数据库用完销毁
turso db destroy pr-123

常见用法

• PR 预览环境：每个 PR 拉一个 branch，跑集成测试，合并后销毁
• Staging：每周一早上 fork 一次 production，清洗敏感数据
• 数据分析师沙箱：fork 一个只读给 BI 团队，不拖累主库

9.5 灾备三板斧

1. 多区域副本

primary 所在区域挂，其他副本仍可读。primary 故障转移由 Turso 自动处理（分钟级）。

2. 24 小时 PITR

逻辑错误（误删表、误跑 DELETE without WHERE）24h 内可回。

3. 外部冷备

定时 turso db shell "." .backup 到 S3/R2——应对账号级灾难（账户被封、区域被整体干掉）。

9.6 自动化冷备脚本

#!/usr/bin/env bash
set -euo pipefail
DATE=$(date -u +%Y%m%d-%H%M)
DB=production

turso db shell "$DB" ".dump" | gzip > "/tmp/$DB-$DATE.sql.gz"

aws s3 cp "/tmp/$DB-$DATE.sql.gz" "s3://my-backups/turso/$DB/"

# 清理 90 天前的
aws s3 ls "s3://my-backups/turso/$DB/" \
  | awk '{print $4}' \
  | head -n -90 \
  | xargs -I {} aws s3 rm "s3://my-backups/turso/$DB/{}"

放进 cron 或 GitHub Actions schedule，每天跑一次。

9.7 恢复演练

备份不演练 = 没备份。至少每季度做一次：

1. 从 S3 拉最新 .sql.gz
2. gunzip 并 turso db create restore-drill --from-file
3. 用 staging 应用连到 restore-drill、跑 smoke 测试
4. 验证关键表行数、样本查询结果
5. 销毁 restore-drill
6. 记录本次演练到 runbook

9.8 数据误删的应对流程

假设你 10:30 跑了 DELETE FROM orders（忘了 WHERE）——标准操作流程：

1. 立刻停写——把应用入口 429，避免覆盖更多
2. 用 PITR 拉 10:29 的分支：turso db create rescue --from-db production --timestamp "2026-04-21T10:29:00Z"
3. 从 rescue 里 SELECT * FROM orders dump 到 SQL
4. 在 production 里 INSERT OR IGNORE 把数据恢复（注意主键冲突）
5. 恢复应用入口
6. 事后总结 + 加 DELETE 的双人审查

9.9 跨账号迁移

换 Turso 组织 / 甚至搬离 Turso 的流程：

# 1. dump 二进制
turso db shell source-db ".backup /tmp/dump.db"

# 2. 切组织
turso org switch new-org

# 3. 恢复到新账号
turso db create target-db --from-file /tmp/dump.db

# 4. 想彻底离开 Turso？dump.db 就是标准 SQLite 文件
sqlite3 /tmp/dump.db ".schema"

没有锁定——数据始终在你手上，这也是选 SQLite-based 方案的价值之一。

小结

Turso 的备份层次：自动 PITR（付费）、CLI dump（手动 + 自动化）、branch（任意点 fork）。灾备三件套是"多副本 + PITR + 外部冷备"。关键是演练——没跑过恢复的备份不叫备份。下一章总结生产清单。