备份日志全是 OK，恢复时才发现库只到凌晨 3 点：MySQL 备份有效性验证的 5 个必做动作

一、现象与背景：一份"绿色"的备份，救不了一次真实的故障

先给一组扎心的数字。我们是一套 3 节点业务（MySQL 5.7.36 主从 + 应用双机），主库数据量约 48GB，每天 03:00 跑一次逻辑备份 mysqldump --single-transaction，凌晨 04:12 结束，脚本 exit 0，日志里 Dump completed successfully，监控面板一片绿。

去年 8 月一个下午，主库磁盘 controller 故障，整盘挂掉。我们按 SOP 拉起从库、把昨天的备份恢复到新主。结果一查：备份里的 orders 表只到 03:00，而当天 00:00–03:00 之间业务还在写——从库的 GTID 比备份多了 21 万条事务，binlog 又因为磁盘故障前的一次 PURGE BINARY LOGS 被清掉了 6 小时。最终我们靠从库 + 应用侧 4 小时的订单补偿对账才把数据追平，事后统计：如果备份里那 3 小时数据丢了，直接损失约 1.7 万笔订单。

更讽刺的是：备份"成功"了。日志、告警、面板，全是绿的。

这就是我想讲的核心问题：备份的可靠性不在"备份成功"那一刻，而在"恢复成功"那一刻。备份作业的成功率 100% 和备份的可用率 100%，完全是两回事。

二、根因分析：为什么"成功"的备份会不可用

拆开看，这次事故背后有四个机制性问题，每一个都独立成立：

1. mysqldump 的"成功"语义太弱。它只保证把 dump 流写到文件、exit 0，不保证文件可读、可导入、行数对得上。我们的 dump 文件 1.2GB，如果最后一行是半截 SQL（磁盘写满、进程被 OOM killer 杀掉但脚本没感知），exit 0 依然是可能的——因为 tar/管道缓冲的退出码传导在 shell 里很容易断。
2. 单事务快照的起点被误读。--single-transaction 给的是事务开始那一刻的一致性视图。03:00 开始 dump，视图就锚在 03:00 左右，不是 04:12 结束时间。我们之前一直按"结束时间"算 RPO，把 03:00–04:12 这段当作"有备份覆盖"，实际上这 72 分钟里新写入的数据只能靠 binlog 补——而 binlog 的保留窗口只有 24h，故障时恰好不够。
3. binlog 保留策略和备份窗口是脱钩的。binlog_expire_logs_seconds=86400，看着够长，但没考虑"备份失败后的下一次恢复"场景：如果连续两天备份都静默失败（见下条），第三天恢复时，需要的 binlog 已经被自动清了。
4. 从库不是第二份备份。从库的数据是"当前态"，不是"任意历史点"。主库挂了，从库只能顶到主库故障那一刻之前的状态；主库和从库同时挂（同一机房、同一存储域），从库救不了任何历史数据。

一句话根因：我们只有"备份动作"，没有"备份有效性"的度量。

三、具体做法：5 个必做动作，全部可复现

下面这套流程在我们环境跑了 8 个月，恢复演练成功率从"没测过"到 5/5 全通过。

动作 1：备份完成后，立即做"文件级"校验

不要只信 exit 0。在备份脚本里追加：

#!/usr/bin/env bash
set -euo pipefail
DUMP=/backup/mysql/prod_$(date +%F).sql.gz
mysqldump -h 10.0.1.11 -u backup_user --single-transaction \
  --routines --triggers --events \
  prod_db | gzip > "$DUMP"

# 校验 1：gzip 完整性
gzip -t "$DUMP"

# 校验 2：文件非空且大小在预期区间（历史基线 1.15–1.35GB）
SIZE_KB=$(stat -c%s "$DUMP" / 1024)
if (( SIZE_KB < 1_100_000 || SIZE_KB > 1_400_000 )); then
  echo "ALERT: dump size ${SIZE_KB}KB out of baseline range" >&2
  exit 1
fi

关键点：大小基线不是拍脑袋的，是拿最近 30 天备份文件大小的 p10/p90 算出来的。数据量稳定时，大小突变（±15%）是最早、最便宜的异常信号。

动作 2：每周一次"影子恢复"，不碰生产

开一台 8C16G 的临时机器（或 K8s Job），把最新备份 + 最近 48h binlog 完整恢复一遍：

# 1. 解包导入
gunzip -c $DUMP | mysql -u root --binary-mode

# 2. 行数对账（关键表）
mysql -e "SELECT COUNT(*) FROM prod_db.orders;"
# 与主库同一时刻的 COUNT(*) 比对，允许 ±0.5%（单事务快照差异）

# 3. binlog 补放验证
mysqlbinlog --include-gtids-set='$(cat /tmp/gtid_purged)' \
  /backup/binlog.000123 | mysql -u root
# 补放后 GTID 应追平主库故障模拟点

影子恢复的价值不在"能不能导"，而在量化恢复耗时：我们这套 48GB 的逻辑备份，导入耗时 47 分钟，binlog 补放 9 分钟，全程 RTO ≈ 60 分钟。这个数字写进故障 SOP 里，比任何"我们会尽快恢复"的口头承诺都硬。

动作 3：binlog 保留窗口 ≥ 备份间隔 × 3

binlog_expire_logs_seconds 不是越大越好（磁盘），但必须覆盖"备份失败 N 次后的恢复窗口"。我们的公式：

binlog_expire_logs_seconds ≥ 备份间隔(86400) × 3 = 259200  (3 天)

理由：如果连续 2 天备份静默失败（动作 1 的告警没被处理），第 3 天恢复时，你需要的是"最后一次成功备份"到"故障点"之间的全部 binlog，这个跨度可能超过 48h，2 天保留会不够。3 天是"磁盘成本 vs 恢复可能性"的折中，48GB 数据量下 binlog 3 天约 2.3GB，成本可忽略。

动作 4：从库 + 备份的"故障域"分离

这次事故暴露了一个隐藏假设：主从在同一机房、同一存储域。我们后来把从库迁到另一可用区（跨 AZ），并且从库不做 PURGE（保留 binlog 只读副本），作为"第二份历史数据源"。成本是多一台 8C32G 的机器，换来的是：主库单盘挂掉时，从库有完整 binlog 可以回放；主从同时挂时，备份 + binlog 文件是唯一的救命稻草，而这份救命稻草已经被动作 2 验证过"真的能用"。

动作 5：把"恢复演练"排进季度 checklist，不是"有空就做"

我们现在的季度 checklist（贴在内网 wiki，每次演练后更新）：

| 项目 | 频率 | 通过标准 | |---|---|---| | 备份文件 gzip -t | 每次备份后 | 0 退出码 | | 文件大小基线检查 | 每次备份后 | 在 p10–p90 区间 | | 影子恢复 + 行数对账 | 每周 | 差异 < 0.5% | | binlog 补放验证 | 每周 | GTID 追平 | | 全链路 RTO 计时 | 每季度 | ≤ 90 分钟（48GB 基线） | | 跨 AZ 从库健康检查 | 每天 | 复制延迟 < 5s |

四、踩过的坑与反直觉之处

坑 1：--single-transaction 的快照点是"开始"不是"结束"。 我们之前 RPO 估算一直按 dump 结束时间算，实际快照锚点在开始时刻，中间差了 72 分钟。这个数字在故障时就是"丢数据的窗口"，必须明确写进 SOP，不能靠"大概"。

坑 2：exit 0 不等于"文件完整"。 shell 里管道 mysqldump | gzip > file 的退出码默认取最后一个命令（gzip），mysqldump 中途被 kill 你根本不知道。必须加 set -o pipefail，否则 gzip 会把半截流正常压缩完，exit 0，文件 1.1GB 看着很正常，实际最后一张表是空的。

坑 3：影子恢复用同一台机器跑，会污染基线。 我们第一次影子恢复直接跑在从库上，恢复期间从库负载飙升、复制延迟从 2s 涨到 40s，业务侧告警一片红。后来改成独立临时机器，恢复完即销毁，既干净又能测出"真实 RTO"（不受生产负载干扰）。

坑 4：行数对账 0.5% 容差不是随便拍的。 --single-transaction 的快照点在 dump 开始时刻，影子恢复的"当前时刻"比快照点晚了 47 分钟（导入耗时），这期间新写入的数据自然不在备份里。0.5% 是 47 分钟写入量 / 总行数的经验值，如果差异超过 0.5%，大概率是备份本身有问题，而不是时序差异。

坑 5：备份账号权限给多了反而危险。 备份账号只需要 SELECT, RELOAD, SHOW VIEW, EVENT, TRIGGER, REPLICATION CLIENT 六项权限，不要给 SUPER。我们之前为了省事给了 SUPER，结果这个账号的密码被一个离职同事留在 wiki 里没删，安全审计时差点出事。最小权限不是"麻烦"，是"出事时少一个口子"。

五、结论与可复用清单

核心结论：备份的"成功"是一个动作，备份的"可用"是一个系统。 前者只需要脚本不报错，后者需要文件校验、恢复演练、binlog 窗口、故障域分离四件事同时成立。任何一件缺位，"备份"就只是"写了一堆文件到磁盘上"。

可复用清单（直接抄走）：

• [ ] 备份脚本加 set -o pipefail + gzip -t + 文件大小基线检查
• [ ] 影子恢复每周一次，独立机器，量化 RTO 并写入 SOP
• [ ] binlog 保留窗口 ≥ 备份间隔 × 3
• [ ] 从库跨 AZ 部署，保留 binlog 只读副本
• [ ] 备份账号最小权限（6 项，不要 SUPER）
• [ ] 恢复演练进季度 checklist，每次更新 RTO 基线
• [ ] RPO 估算用 dump 开始时间，不是结束时间

最后一句大白话：备份不是"做了"，是"验证过能恢复的"。 这两句话之间差的，可能就是一次 1.7 万笔订单的对账夜。