备份体系的交付物不是一堆文件，而是“在约定时间内，把数据恢复到约定时间点”的确定能力。先定业务目标，再决定工具、频率、保留周期和演练方式。

一、先定义 RPO 与 RTO

指标要回答的问题会影响什么
RPO最多允许丢失多长时间的数据？备份频率、Binlog 保留与跨地域复制
RTO故障后多久必须恢复服务？恢复介质、自动化程度、数据量与预热方案

“每天备份一次”不是业务目标。如果 RPO 要求 5 分钟，仅有每日全量备份显然不够；还必须持续保留并保护 Binlog，或采用更合适的数据保护方案。

二、建立分层备份

  1. 物理全量：承担大数据量下的快速完整恢复。
  2. 增量或差异：缩短备份窗口与传输时间，但增加恢复链复杂度。
  3. Binlog：用于时间点恢复，必须与全量备份的坐标信息关联。
  4. 逻辑备份：便于对象级恢复、迁移与抽样校验，不替代物理备份。
  5. 异地副本：应对机房、账号、误删除和勒索等同故障域风险。

副本不是备份

主库误删除会复制到从库；主从复制能提升可用性，但不能替代具备独立保留周期和访问控制的备份。

三、演练前准备

  • 明确演练目标：完整恢复、单库恢复或时间点恢复
  • 准备与生产隔离、容量足够的恢复环境
  • 记录 MySQL 版本、参数、字符集、加密与密钥依赖
  • 确认全量、增量与 Binlog 链完整且校验值一致
  • 准备验收 SQL、业务抽样规则和计时表
  • 指定执行人、观察人、审批人和回滚边界

四、完整恢复演练 Runbook

步骤 1：选定恢复点并冻结证据

记录目标时间、目标事务或业务事件，保留所需备份文件清单、校验值、Binlog 起止位置和依赖配置。不要在演练过程中让保留策略自动清理这些文件。

步骤 2：恢复并准备物理备份

# 示例：命令参数应按实际版本与备份策略调整
xtrabackup --prepare --target-dir=/restore/full

# 确认目标 datadir 已清空且权限正确后再复制
xtrabackup --copy-back --target-dir=/restore/full

物理恢复前必须核对版本兼容性、目录、属主、磁盘空间和启动参数。任何会覆盖数据目录的操作都只在隔离恢复环境执行。

步骤 3：启动隔离实例并完成基础校验

  • 错误日志无崩溃恢复或表空间异常
  • 核心库表、账号与权限存在
  • 表数量、数据量和关键对象符合备份时间点
  • 实例只能被演练网络访问，不接入生产流量

步骤 4：应用 Binlog 到目标时间点

mysqlbinlog \
  --start-datetime='2026-08-07 01:00:00' \
  --stop-datetime='2026-08-07 01:28:30' \
  mysql-bin.000321 mysql-bin.000322 \
  | mysql --socket=/restore/mysql.sock

实际演练应优先使用备份记录的精确位置或 GTID 范围，并避开导致故障的事务。时间点只是便于理解的示例，时区和跨文件边界都必须核对。

步骤 5：做数据库与业务双重校验

校验层建议内容
实例启动状态、错误日志、版本与关键参数
对象库表、索引、视图、存储过程、账号权限
数据行数、校验和、最大时间戳、核心金额与订单数量
业务登录、查询、下单等只读或隔离验证流程

步骤 6：记录耗时并复盘

分别记录文件准备、数据复制、实例启动、Binlog 回放和业务验证耗时。把最长环节与人工等待找出来，才能判断实际 RTO 是否达标。

五、演练验收标准

通过条件

恢复点满足 RPO；总耗时满足 RTO；核心数据与业务校验通过；操作步骤可由非作者按文档复现；发现的问题已有负责人和截止时间。

六、建议的演练节奏

  • 每日：自动检查备份任务、大小、耗时、校验值与 Binlog 连续性。
  • 每周：抽取一份备份做自动化恢复与基础 SQL 校验。
  • 每月或每季度：按重要性完成端到端人工演练，验证 RPO/RTO 与业务流程。
  • 重大变更后：版本升级、存储迁移、加密调整或备份工具变更后立即专项验证。

七、一句话记忆

用业务 RPO/RTO 设计备份，用隔离恢复证明备份，用业务校验宣布成功，用定期演练保持这项能力有效。