1 为什么不要 cp 运行中的 db
WAL 模式下，热拷贝文件 可能得到 不一致三元组 （主库、-wal、-shm）；即使用 备份 API ，也应理解 一致性快照 由引擎协调。
2 sqlite3_backup 流程（逻辑）
- 打开 目标 空库或覆盖策略明确的库；
sqlite3_backup_init(pDest, "main", pSrc, "main")；- 循环
sqlite3_backup_step(pBackup, nPage)，分页 step 可把备份打散到事件循环，降低长尾阻塞； sqlite3_backup_finish，检查错误码；失败路径仍要 释放。
3 .backup / .restore（交互 sqlite3）
text
.backup dest.db适合运维脚本 sqlite3 main.db ".backup backup.db"（注意引号与路径）。restore 思路对称：从备份文件 attach/导入视版本而定，生产多用 应用侧重新指向备份文件 恢复。
4 增量备份「思路」
SQLite 无通用 binlog；所谓增量通常是：
- 文件系统级增量 （ZFS/btrfs/块设备快照）叠在 周期全量 之上；
- 应用层变更日志（CDC）另行存储------已超出 SQLite 内核。
对嵌入式：每日全量热备 + 异地拷贝 往往比过度设计增量更可靠。
5 跨版本恢复注意事项
- 低版本 sqlite 打开高版本生成的新格式 可能失败；
- 迁移路径：老版本打开 →
VACUUM INTO或导出 SQL → 新版本导入（以官方迁移指南为准）； - integrity_check 与 业务冒烟 必经。
6 生产备份策略骨架
- RPO/RTO 数字写进 Runbook；
- 备份文件校验 ：sha256 + 定期 演练恢复；
- 密钥与 PII ：备份副本 加密与权限；
- WAL ：热备仍推荐 backup API，不要裸拷。
7 与 GitOps
backup.yml作业：cron + 告警 + 留存周期；- Artifact 命名含 SQLite 版本号，便于追溯。
8 错误码与排障（backup_step）
sqlite3_backup_step 返回 SQLITE_BUSY 或 SQLITE_LOCKED 时，勿无限循环硬顶：应 退避 并记录 当前 remaining 页数 （若 API 可查）。返回 SQLITE_OK 且 仍有剩余 时继续 step；DONE 后务必 finish 并检查 目标库 PRAGMA integrity_check 。运维脚本要对 非零退出码 触发告警，而不是「备份文件生成了但为空」。
9 与对象存储、合规
备份上传到 S3 兼容存储 时，开启 服务端加密 与 生命周期策略 （冷存储降本）。个人数据场景注意 GDPR/个人信息保护法 ：备份副本 最小权限 + 定期销毁，与业务库同等级审计。
10 与 VACUUM INTO 的协同（发行线）
当目标不仅是 一致副本 还要 收缩文件 时，可在 副库 上先 VACUUM INTO packed.db 再上传对象存储，作为 只读发行 artifact ；主库仍用 backup API 保业务连续。两条链路 不要混用同一文件名，避免演练时覆盖冷备。
总结
热备靠 sqlite3_backup_* ，演练靠 定时 restore 。把「增量」留给 基础设施 ，把「一致」留给 官方 API。