第4章：让备份类型服务于恢复路径

不同分类回答不同问题

逻辑备份保存建表语句和数据表达，恢复时重新执行；物理备份保存数据库文件及配套日志，恢复方式与版本和存储布局关系更紧。完整与增量描述覆盖范围，在线与离线描述取得备份时是否继续服务。这些维度可以组合，不能听到“在线”就推断恢复更快，也不能把“增量”理解成天然拥有时间点恢复能力。

本书选用mysqldump，不是因为它适合所有规模，而是因为SQL可读、恢复路径透明，便于在教学资源内核对业务状态。大库的逻辑恢复可能被建索引、事务日志和约束处理拖慢。这个局限不需要用空泛警告处理，应该通过容量演练比较实际导入时间、资源峰值和恢复预算。

物理备份需要对应工具对一致性、redo处理、版本兼容和加密的支持。仅复制正在变化的数据库目录通常不能得到可用备份。快照也需要知道存储层的一致性边界及数据库恢复条件。本书没有执行物理备份，因此不把逻辑实验的成功推广成物理方案可用。

一份备份是一组关联材料

数据文件之外，至少还要保留元数据、来源身份、取得时间范围、工具版本、选项、复制坐标或GTID信息、加密密钥获取路径和完整性指纹。对象权限、事件、触发器、存储过程是否在范围内，也应明确。随书dump显式包含routines、triggers和events，但教学业务没有创建这些对象，所以不能宣称已经验证复杂存储程序的兼容迁移。

备份摘要检查传输后的字节是否一致，不判断SQL是否完整表达了想要的数据。两个完全相同的损坏文件也会有相同摘要。我们把摘要与真实导入、对象检查和业务核对结合起来。报告中的dump_sha256能够标识哪份数据被测试过，state摘要则说明那份数据导入后的业务含义。

日志保留决定备份之间的空隙

假设凌晨完整备份成功，上午发生误删。若只有完整备份，就只能回到凌晨附近；想保留误删前的合法交易，需要从备份坐标开始的连续binlog。日志的保存位置必须独立于可能故障的源盘，否则源机不可读时，账面上的时间点恢复能力就会消失。

保留策略要覆盖最坏的发现延迟。误删可能当天没有被发现，审计周报才暴露差异。如果binlog已经按短周期过期，即使完整备份还在，也无法恢复到想要的时点。反过来，仅保留大量日志却没有合适基线，可能需要从很早的数据重放，导致恢复时间超出预算。

恢复环境也是备份的依赖

目标机器需要能获取镜像、启动数据库、读取备份密钥并容纳导入产生的临时空间。机房故障时，私有镜像仓库和密钥服务可能同样不可用。应把这些依赖纳入演练，而不是等导入当天才发现工具下载地址已经失效。本书固定镜像和客户端RPM，并记录hash，目的就是让软件来源也可以审查。

我们在干净容器恢复，不复用源实例的数据目录，也不把源端尚未导出的文件偷偷当作恢复输入。这样，备份的独立性才得到最基本的证明。生产中还应考虑账户授权、字符集、时区、插件和密钥版本，本书的小业务没有覆盖这些组合，只提供扩展检查的路径。

从失败清单倒推方案

如果主要风险是误删，应重视可定位的连续日志与隔离恢复；如果是主机损坏，应确保副本或备份不共享故障域；如果是应用逻辑批量写错，实时复制通常会忠实复制错误，需要延迟发现和历史恢复能力；如果是勒索或凭据失陷，备份删除权限和不可变保存同样关键。

这些场景可能需要多层保护，成本也不同。你可以从最重要的两类风险开始，为每类写出恢复输入、目标实例、验收条件和时间预算。随后跑一次实际恢复，得到的结果会比“采用业界通用方案”更能指导预算。工具名称不是恢复承诺，经过验证的输入到结果路径才是。