MySQL 备份策略需以 RPO 和 RTO 为基准设计，采用“全量 + 增量 / 日志 + 变更校验”三层结构，按数据活跃度分级设定周期，并强制自动化验证与清理。
MySQL 备份策略的核心是平衡数据安全、恢复效率和资源开销，不能只看“多久备一次”，而要结合业务特性、数据变更频率、RPO（恢复点目标）和 RTO（恢复时间目标）来设计。
明确恢复目标（RPO 与 RTO）
RPO 决定最多能容忍丢失多少分钟 / 秒的数据，直接影响备份粒度；RTO 决定故障后必须多快恢复服务，影响备份类型选择（如是否需物理热备 +binlog 实时应用）。例如：金融 类业务 RPO 通常要求≤1 分钟，就必须启用 GTID+ 基于位置的 binlog 实时归档；内部管理系统 RPO 可放宽至 24 小时，每日全量 + 每周差异即可满足。
- 查清业务方能接受的最 大数据 丢失量（如“最多丢 10 分钟订单”）→反推 binlog 保留时长和备份频率
- 测试实际恢复耗时：从备份集 解压、导入到校验完成，记录全流程时间→验证是否满足 RTO
- 避免默认套用“每天全备”，若表极少更新（如字典表），可延长全备周期，改用逻辑导出 +checksum 校验
分层组合备份类型
单一备份方式无法兼顾速度、空间与恢复灵活性。推荐采用“全量 + 增量 / 日志 + 变更校验”三层结构：
- 全量备份：使用mysqldump（逻辑）或 xtrabackup（物理），建议每周日凌晨低峰期执行；物理备份优先，恢复更快且支持部分库 / 表恢复
- 增量依据：开启 binlog（ROW 格式），每 6–12 小时滚动归档一次，保留至少 7 天；若用 xtrabackup，可搭配 –incremental 参数做增量物理备份
- 轻量校验层 ：对高频更新表（如用户登录表），每天用 SELECT COUNT(*) + MIN(id)/MAX(id) 生成快照，存入独立监控库，快速识别逻辑损坏
备份周期动态调整规则
固定周期易造成资源浪费或保护不足。应按数据活跃度分级设定：
- 核心交易库（订单、支付）：每日全备 + binlog 每 15 分钟同步一次 + 每日验证一次恢复流程
- 分析类历史库（归档数据、报表宽表）：每月全备 + binlog 关闭（或仅开启但不归档）+ 每季度抽样校验
- 配置类小表（系统参数、权限表）：每次上线变更前手动 mysqldump 导出，存入 Git 版本库，不走自动备份通道
- 所有备份文件须添加时间戳与实例标识（如 backup_orderdb_20240520_030000.sql.gz），避免混淆
验证与清理必须自动化
未验证的备份等于无效备份；不清理的备份会撑爆磁盘。两者必须脚本化并纳入监控：
- 恢复验证：每周随机选一个备份集，在隔离环境自动执行“解压→导入→连通性查询→行数比对”，失败立即告警
- 生命周期管理：全量备份保留 3 份（最近 3 次），binlog 保留 7×24 小时，过期文件由 cron 调用 find + rm 自动清理，同时记录清理日志
- 关键动作留痕：备份脚本中加入 set -e 和 log 输出，确保任意步骤失败即中断，并写入统一日志中心（如 ELK）供审计
不复杂但容易忽略。
