MySQL 备份策略需以 RPO/RTO 目标为驱动：订单系统 RPO=0、RTO≤5 分钟，须启用 binlog+GTID 主从 + 定期物理全备；报表库 RPO= 1 小时、RTO=30 分钟，可采用逻辑备份 + 定时快照。
制定 MySQL 备份策略，核心是平衡 数据安全性、恢复时效性、存储成本和运维复杂度 。不能只靠 mysqldump 定期导出，也不能盲目上全套 高可用架构。得根据业务场景选对方法、设好节奏、留足验证环节。
明确备份目标与 RPO/RTO 要求
先问清楚：最多能丢多少分钟数据？故障后必须几分钟内恢复？比如订单系统要求 RPO=0（不能丢事务）、RTO≤5 分钟；而报表库可接受 RPO=1 小时、RTO=30 分钟。这些数字直接决定你用物理备份还是逻辑备份、是否启用主从延迟备库、要不要部署并行恢复 工具。
- RPO 极低（接近 0）→ 必须开启 binlog + 基于 GTID 的主从复制，配合定期物理全备
- RTO 严格（
- 开发 / 测试库 → 可用 mysqldump + 定时快照，保留 3 天即可
组合使用全量、增量与日志备份
单一备份方式风险高。推荐“物理全备 + binlog 持续归档”为主干，辅以按需逻辑导出：
- 全量备份：每周日凌晨用 Percona XtraBackup 执行一次压缩加密的物理备份，存至异地对象存储（如 S3 或 MinIO），保留 4 个周期
- 增量基础：每天凌晨基于上次全备做一次增量备份（xtrabackup –incremental-basedir），节省空间且加快恢复起点
- binlog 归档：开启 log-bin + expire_logs_days=7，配合脚本定时把 binlog 同步到备份服务器，确保能恢复到任意秒级时间点
自动化执行与可靠验证不可省略
备份脚本跑成功 ≠ 数据可恢复。必须加入自动校验和定期演练：
- 每次备份完成后，自动调用 xtrabackup –prepare 验证备份一致性，并记录 exit code 到监控系统
- 每月至少一次在隔离环境执行完整恢复流程：解压全备 → 应用增量 → 回放 binlog 至指定位置 → 连接应用验证查询结果
- 用 pt-table-checksum 对比主从表数据一致性，避免备份时主库静默损坏未被发现
权限、加密与生命周期管理
备份文件本身也是敏感资产，需同步管控：
- 备份账号仅授予 RELOAD, LOCK TABLES, REPLICATION CLIENT, PROCESS 权限，禁用 SUPER
- 所有备份包启用 AES-256 加密（xtrabackup 支持 –encrypt / –encrypt-key），密钥由 KMS 或 Vault 统一托管
- 设置分级保留策略：全备保留 4 周，增量保留 7 天，binlog 保留 7 天；超期自动清理并记录日志
