New API 升级前备份了，怎样演练一次真正可用的恢复

备份目录里有一个数据库文件，只能说明“保存过一个文件”。New API 升级前更有用的证据是：能在隔离环境打开它、读出预期配置，并确认恢复的版本和时间点。这篇不重复安装命令，而是给一次恢复演练的验收路径。

配套SQLite 恢复演练脚本仅创建临时目录里的合成表，演示 Connection.backup() 与只读检查；它既不读取生产目录，也不备份真实 New API。运行需要带 sqlite3 模块的 Python 3，执行 python restore-drill.py 后应输出 integrity=ok; rows=2; total=30。

先确认你究竟用哪种数据库

当前 New API 官方部署文档优先推荐生产环境使用 PostgreSQL，同时保留 MySQL 兼容，SQLite 面向本地评估和临时测试。不要直接把 SQLite 文件复制方法套到所有部署；旧教程中的安装选择也不代表当前官方建议。已有环境的配置位置可结合部署实操核对，但演练必须以实际数据库类型为准。

建立一张恢复范围表，至少区分四项：数据库快照、应用版本或镜像摘要、运行配置、由配置引用的外部依赖。密钥只记录受控存放位置和恢复方式，不把内容贴进报告。Redis、外部数据库、文件挂载等是否需要恢复，依据你当前部署实际使用的功能确定，不能一律声称“只要一个 data 目录”。

一个可运行的最小演练

附件先创建名为 demo_channels 的合成表，放两条演示记录；它不是 New API 真实表结构。事务提交后，用 SQLite 备份接口复制到新文件，再以只读方式打开复制品，检查完整性、行数与整数合计。临时目录由脚本自己创建并在结束时清理，不接受生产路径参数。

这样做是为了把恢复验收逻辑先练通：预期两行却读出零行，要先怀疑选错快照或连接错库；完整性返回正常却少一条配置，说明“文件能打开”仍不等于业务配置恢复正确。SQLite 官方备份接口解决运行中数据库的一致复制问题，不能据此推断任意时刻直接复制主文件就同样可靠，尤其不要忽略可能存在的 WAL 状态。

把演练移到真实测试环境

先准备独立的数据目录和端口，限制测试实例的网络出口。恢复后不要立即放开真实上游渠道，也不要连回生产数据库；带着真实渠道凭据的克隆可能产生实际请求。可以先断开上游或替换为受控假服务，只核查配置与页面能否加载。

按清单逐项记录：

检查项	验收证据	不足以通过的结果
版本	原版本、目标版本、镜像摘要	只写 latest
数据	快照时刻、校验值、只读检查输出	只看文件大小
配置	渠道数量、分组及非敏感设置抽样	只看到登录页
运行	测试实例健康、假服务调用结果	用真实生产流量试错
恢复时长	开始、结束与人工步骤	根据文件尺寸估算

数据库迁移后还要保留“旧应用加旧快照”的成对回退材料。把旧镜像启动在已迁移的新库上，不能自动当成安全回退；兼容性需由对应版本说明和测试确认。

失败结果也属于演练产物

如果恢复后重新出现初始化向导，先核对数据库连接和挂载，不要随手新建管理员掩盖问题。如果配置能读出而无法解密渠道凭据，核对原部署有关密钥的配置，不要在公开日志中打印它。碰到检查报错、数据对不上或回退链条不完整，就把升级条件记为未满足。

最终报告应能回答“恢复到哪个时间点、丢失窗口多大、谁验证了哪些项目”。本文附件只验证合成 SQLite 数据的复制与读取，没有启动真实网关，也没有完成 PostgreSQL/MySQL 的恢复验收；对应数据库应使用其官方备份恢复工具另做演练。

常见问题

备份接口完成后为什么还要查行数？ 它证明数据复制流程完成，业务抽查还需要确认复制的是正确来源和预期时间点。

快照 SHA-256 相同就代表可以升级吗？ 不代表。摘要检查文件传输是否变化，不检查版本迁移、配置依赖或业务行为。

可以把线上库传到公共网盘给人帮看吗？ 不要。演练用受控副本；对外提供字段与计数即可，不上传渠道密钥或用户数据。

核对依据

核对日：2026-10-23。New API 部署文档用于数据库选择边界；系统更新指南用于升级准备；SQLite Online Backup API和Python sqlite3 备份接口用于附件方法。本文没有执行生产备份或升级。