备份任务列表全绿，每日成功汇总准时推到群里，连续几百天零失败——真出事那天，恢复出来的库是空的：导出账号权限不足，只导走了表结构；或者更糟，备的根本是另一台测试实例。任务从没失败过，因为它从来没被要求过"恢复"。
由此得到本文唯一要立的判据："备份成功"的定义是恢复成功，不是任务返回零。退出码、文件大小、校验和都是内部工序的合格证，它们共同证明的只是"这个进程按预期跑完了"。验证要付的成本很高，所以它必须是有层次、有优先级、可以按场景裁剪的工程动作，而不是一句"我们定期演练"。
1. 验证的四个层次
| 层次 | 判据 | 能证明 | 不能证明 | 单次成本 |
|---|---|---|---|---|
| L1 能读到 | 文件存在、能打开、摘要与记录匹配 | 文件没损坏、没被覆盖 | 内容是不是有效数据 | 极低，可自动化 |
| L2 能解出结构 | 恢复到临时实例、能列出对象与表、位点可读 | 格式正确、链能解开 | 数据是否完整、是否是对的库 | 低，需环境与密钥 |
| L3 能到可用状态 | 应用能连、关键事务能跑、一致校验通过 | 恢复出来的东西业务可用 | 来不来得及 | 中，需业务参与 |
| L4 能在业务时限内 | 全流程计时结果落在承诺的恢复窗口内 | RTO 主张成立、分工可用 | 不覆盖 RPO，需另一路验证 | 高，需时间窗与人力 |
大多数团队的验证停在 L1——它最便宜、最容易自动化、也最容易让人安心。L2 的失败原因高度集中：密钥在另一个人手里、链上某一环缺凭据、恢复账号读不到全部对象。L3 才撞上真意外：少了三张业务表、外键引用破碎。
演练与验证是两件事：演练问"这个流程能不能走通、谁在什么时候做哪一步"，验证问"这次恢复出来的数据能不能用、时长是多少"。演练可以不带数据、可以只走角色与顺序；验证必须落到真实数据与计时，才能产出可以写进承诺的数字。
2. 恢复耗时由哪些环节拼成
| 阶段 | 内容 | 常见低估点 |
|---|---|---|
| 找备份 | 定位正确版本、确认链、从归档层取回 | 冷层取回耗时，被默认成"本地就有" |
| 传输 | 从备份存储搬到恢复环境 | 跨区域带宽与并发上限 |
| 解密解压 | 密钥可用性、CPU 开销 | 密钥保管人在休假，链路停在这里 |
| 回放日志 | 追平到目标时间点（binlog / WAL） | 回放常是单线程，量大时是主要瓶颈 |
| 校验 | 行数、校验和、业务抽样 | 被当成零成本直接跳过 |
| 索引与统计 | 大表重建索引、更新统计信息 | 忘了算，恢复后性能不达标 |
| 切流量 | 域名、配置、连接池、决策 | 需要人决策，不在技术流程内 |
把实测值与口号对齐时，差距往往来自三处：测的是空库（数据量小，回放飞快）、测的是拷贝时间（没算校验与切流量）、没算决策时间（谁签字确认可以切）。后两项不属于工程环节，但它们确实在 RTO 里。
RPO 的可验证形式也不是"备份频率多高"，而是恢复点时间与故障时刻的差：恢复出来的数据最后一条业务记录停在什么时候，那个差就是真实 RPO。
3. 两种隐性失效：链断了、隔离假了
| 隐性失效 | 触发条件 | 发现时机 | 预防 |
|---|---|---|---|
| 基准备份先过期 | 全量保留期短于增量保留期 | 恢复日 | 保留期必须覆盖最长链，而不是按容量定 |
| 链中一环静默失败 | 任务报成功但文件为空或截断 | 恢复日 | 定期按序试解，验证链首尾相接 |
| 备份与源同故障域 | 同宿主、同云盘、同账号、同凭据 | 故障同时命中 | 独立账号、独立区域、独立凭据 |
| 源侧凭据可删备份 | 勒索或误操作删源时顺手删备份 | 需要恢复时 | 备份侧保留删除保护 / 对象锁 |
| 备份落在临时卷 | 容器重建、节点下线即消失 | 下次调度才发现 | 备份目标必须是持久存储 |
| 与源共用密钥管理 | 故障时密钥同样不可得 | 恢复时卡在解密 | 密钥与凭据的可用路径独立 |
增量链的脆弱性是结构性的：全量是根，后续增量都挂在它上面。根被生命周期策略删掉，后面所有增量在数学上都还在，但没有一条能单独恢复。链的可验证信号不是"文件数对得上"，而是"能按序 apply 进去，且相邻两个备份的位点区间首尾相接、没有缺口"。
隔离性同理：备份写在同一个存储桶、用同一个密钥、挂在同一个账号下，在故障谱系上就不算第二份数据。判断隔离程度的问句只有一个——如果源侧凭据今天被误用或被勒索，备份还在不在？
// 隔离性核对清单：每份备份都要能回答
// ─── 存储凭据与源系统凭据是否同源？
// ─── 备份落在哪个账号/区域/介质，能否独立访问？
// ─── 删除备份需要哪个权限，谁能删（含自动化任务）？
// ─── 解密密钥的获取路径，是否依赖源系统的组件？
// 四项里有一项与源共享，这份备份的可用性就打了个折
4. 恢复目标、校验与验证频率
| 恢复目标 | 适用场景 | 代价 | 判据 |
|---|---|---|---|
| 原地覆盖 | 实例已不可用，必须尽快恢复服务 | 最快，风险最高，覆盖期间无退路 | 有回滚预案才算可用 |
| 旁路新实例 | 演练、比对、并行验证 | 需要一份等价环境与地址 | 环境可复用才谈得上高频 |
| 只读挂载 | 取数据、核对、导出补丁 | 不能承接写入 | 用于补数据而非接管流量 |
恢复后的校验分三类，缺一类就有一类事故看不见：结构性（表数、索引数、约束、主键范围）、数量性（行数、最大 ID、时间窗覆盖）、业务性（关键查询可用、金额合计对得上、最近若干笔单据可查）。
// 恢复后的第一件事：证明不是空库，也不是错的库
$ mysql -h "$RESTORE_HOST" -e \
"select count(*) from information_schema.tables where table_schema='$DB';"
$ mysql -h "$RESTORE_HOST" -e \
"select max(id), max(created_at) from $DB.orders;"
// 表数为 0 或位点停在很久以前 → 导的是结构，或导错了实例
// 校验通过率要连同"未通过的明细"一起记录，只报一个百分比等于没报
// 链完整性：按序能解开、位点首尾相接，链才算可用
$ for f in $(ls inc/* | sort); do
preparer --apply-log-only --target-dir="$f" ; done
// 只数文件个数不够：静默失败也会留下一个文件
// 缺口检测：比较相邻备份的位点/LSN 区间是否连续
// 恢复验证清单：L2 与 L3 的分界线就写在这里
// ─── 密钥可用：本次备份的加密凭据在谁手里、路径是否独立
// ─── 结构可比：表、索引、约束、分区数与源库一致
// ─── 位点可用：GTID / LSN / WAL 位置能对上目标时间点
// ─── 业务可用：三条关键查询在可接受时间内返回
// ─── 一致可比：抽样比对通过，差异有解释而不是"大概是缓存"
| 层次 | 建议频率 | 单次代价 | 失败由谁判定 |
|---|---|---|---|
| L1 可读 | 每次备份后自动 | 近零 | 监控 |
| L2 结构 | 每周或每次策略变更后 | 一份临时实例 | 值班 |
| L3 可用 | 每季度，参与发布的人员轮流做 | 一份环境 + 半天人力 | 业务方 |
| L4 时限 | 每半年并结合架构变更 | 时间窗 + 决策演练 | 业务 + 技术共同签字 |
// 演练计时：每个阶段单独记，缺一段的结论无效
$ t0=$(date +%s) ; locate_backup "$TARGET_TS" ; t1=$(date +%s)
$ restore_full "$RESTORE_DIR" ; t2=$(date +%s)
$ replay_log --until="$TARGET_TS" ; t3=$(date +%s)
$ verify_counts && verify_checksums ; t4=$(date +%s)
// 输出四个数：找备份 / 恢复 / 回放 / 校验
// 结论只认"能承接读写的那一刻"，不认"文件复制完的那一刻"
| 指标 | 定义 | 反向信号 |
|---|---|---|
| 恢复成功率 | 达到 L3 及以上的次数 ÷ 验证次数 | 只统计 L1 |
| 实测恢复时长 | 各阶段耗时之和，报 P50 与 P95 | 只报最好一次 |
| 校验通过率 | 结构与数量校验通过的比例 | 只报百分比不报明细 |
| 增量链完整率 | 链可完整回放的备份组占比 | 用文件数代替连续性 |
| 环境复用率 | 验证用的环境能被下一次复用 | 每次都要重新搭，于是频率掉到年 |
5. 排错：六种"备份在、恢复不了"
| 现象 | 根因 | 处理 |
|---|---|---|
| 恢复出来是空库 | 导出账号缺权限，或备错了实例 | 校验表数与位点，别只看任务状态 |
| 解密失败 | 密钥轮换后旧备份没有对应密钥 | 密钥与备份同生命周期管理 |
| 恢复卡在某一环 | 增量链缺一段或基准备份已过期 | 保留期覆盖最长链；定期按序试解 |
| 恢复到一半磁盘满 | 恢复环境容量按压缩后估算 | 容量按解压后 + 临时空间计算 |
| 应用连上但报错 | 恢复未包含配置、凭据、序列、权限 | 恢复范围清单里要含配置类对象 |
| 恢复后性能很差 | 索引与统计信息未重建 | 把重建纳入计时与验收标准 |
6. 边界：这些数据不必做完整恢复验证
| 场景 | 做法 | 理由 |
|---|---|---|
| 数据可从外部源重建 | 只验证重建流程与耗时 | 备份不是唯一路径 |
| 丢失影响极小（缓存、派生索引） | 只验证 L1/L2 | 恢复的价值低于成本 |
| 系统即将下线 | 降为季度抽查 | 剩余生命周期短于验证周期 |
| 数据量极小（配置、字典） | 每次备份后自动 L3 | 成本可忽略 |
| 已有上游全量同步保障 | 验证同步链路而非备份链 | 避免为同一目标做两遍 |
一句话收束：备份的可用性不是靠任务成功率证明的，而是靠"最后一次真实恢复在什么时候、恢复了多少数据、花了多少时间"这三个事实证明的。
自测
- 为什么"退出码为零 + 校验和一致"仍然不能称之为备份成功？
- L2 与 L3 的分界线在哪，各自最典型的失败原因是什么？
- 恢复耗时里最容易被漏算的三个环节是哪些，为什么它们会进 RTO？
- 增量链的"完整"应当用什么信号验证，为什么文件数不够？
- 判断一份备份是否真的隔离，应该问哪一个问题？
- 数据可从外部源重建时，为什么可以把完整恢复验证降级？