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）供审计
不复杂但容易忽略。
