恢复演练与月度报告 早期试点

大屏回答「现在怎么样」。这一页回答另外两个问题：数据丢了能不能找回来，以及这个月到底怎么样。

备份可用，只认真恢复

「备份可用」只有一条判据：把备份真的恢复出来，再逐表核对行数。

以下几样都不算：备份文件存在、压缩包校验通过、能列出备份内容的目录。

为什么这么严

我们亲历过一次：数据库恢复后，关键表恢复成 0 行，而退出码仍是 0。原因是目标镜像在初始化时预建了同名但字段较旧的表，导入时建表被跳过、写数据撞上缺列。只看退出码，这次恢复会被记成成功。

演练怎么做

每月自动执行一次：

1. 期望值从备份文件本身数。 逐表统计备份文件里的数据行数，不经过恢复路径。
2. 恢复进一次性的隔离容器。 无网络、不映射端口；跑完连同数据目录一起删除，因为备份里有个人信息。
3. 实际值逐表 count(*)。 只数期望清单里的表。
4. 附件单独核对。 附件本体不在数据库导出里，另行核对「异地附件文件数 = 恢复库里的附件元数据行数」。
5. 全部相等才算通过。 结果写成一行状态：通过 / 失败、表数、行数、附件数、耗时。

期望清单为空不算通过——期望值是 0，说明判据本身失效了，而不是全对。

对账本身也会出错

• 逐表计数的循环里，如果某条命令吞掉了循环自己的输入，只会数到第一张表就静默结束。所以计数循环跑完后，会断言「实际行数的条目数 = 期望清单的条目数」。
• 两份清单比对前，用同一个区域设置各自重新排序，避免排序规则不一致导致的静默错配。

负对照：判据要能报失败

演练脚本带一个负对照开关：故意用有缺陷的恢复流程再跑一遍，判据必须报失败。

如果有缺陷的流程也报通过，说明判据测不出问题，那么正常流程的「通过」也不作数。一个从来没见过它报失败的检查，不能当作证据。

外部视角探测

服务器自己探测自己，整机宕机时探针一起停，那段时间会被记成「正常」——测量与被测同源。

所以可用性从另一台机器上测：

• 每 5 分钟访问一次，每次都落一行样本：时间、目标、HTTP 状态码、耗时。
• 按对齐的 5 分钟时隙统计；同一时隙多次采样只算一格，任一成功即成功。
• 哪些状态码算「可达」，是一张写死在代码里的显式清单。
• 自首个样本起算，没有样本的时隙记为「未采样」，不计为成功。

报告里这一行会同时写出成功、失败、未采样三个数。

月度证据报告

一页纸，给客户看。原则只有一条：每个数字旁边写着它是怎么测的。

项目	测量方式
可用率	本机每 5 分钟访问首页；另一台机器每 5 分钟外部访问，未采样不计为成功
数据库每日备份	每日全量导出；异地副本逐文件 SHA-256 校验
附件异地备份	附件增量同步到异地；报告最近一次的结果
备份恢复演练	异地备份真实恢复到隔离环境，逐表核对记录数
HTTPS 证书	现场握手，读取线上实际在用的证书
域名到期	WHOIS 查询

• 指标全部在生成报告时现场采集，不含人工填写的数字。
• 人工部分只有三段文字：本月完成、下月计划、需要贵方配合。
• 最近一次演练超过 35 天，报告标为异常，而不是留空。

为什么要写测量方式

客户可以不看这一列。但我们自己不能交出一个说不清来源的数。 同一个「可用」，本机探测和外部探测含义不同；同一个「备份成功」，文件存在和恢复成功含义也不同。写出测量方式，读者才能自己判断这个数字值多少。