MySQL 备份组合策略是什么
生产环境通常不依赖单一手段：周期性物理全量打底，用来快速重建整个实例；每日逻辑导出补充跨版本迁移与单表恢复能力；日志持续归档提供恢复到任意时间点的能力。三者职责清晰、互相补位，而不是任选其一。
组合示例
| 层次 | 频率 | 工具 | 作用 |
|---|---|---|---|
| 物理全量 | 每周 | 物理热备工具 | 快速重建整实例 |
| 逻辑导出 | 每日 | mysqldump 或官方 shell 工具 | 跨版本迁移与单表恢复 |
| 日志归档 | 持续 | 文件同步或存储层复制 | 恢复到任意时间点 |
基本信息
| 设计顺序 | 先定 RTO 与 RPO，再选手段组合 |
|---|---|
| 保留对齐 | 归档侧保留多久，时间点恢复窗口就有多久 |
| 存储分离 | 备份与日志不放在数据文件同一磁盘 |
| 验证方式 | 试恢复配合时间点回放演练 |
计划任务骨架
计划任务骨架
# 每周日 02:00 物理全量（脚本内含准备阶段）
0 2 * * 0 /opt/backup/xtra-full.sh
# 每 15 分钟把新增日志同步到归档盘
*/15 * * * * rsync -a --ignore-existing /var/lib/mysql/binlog.* /backup/binlog/
# 每日 03:00 逻辑导出
0 3 * * * /opt/backup/logical-dump.sh设计要点
- 规模决定主干：数据量到几百 GB 后逻辑恢复耗时会明显超过目标，应保留物理备份
- 恢复目标决定频率：丢失窗口按分钟要求时，日志归档必须持续运行且可监控
- 存储位置分散：备份放独立磁盘或对象存储，避免与数据文件共命运
- 任务错峰：物理全量与逻辑导出不要挤在同一时段，互相争夺磁盘带宽
- 演练到位：至少每季度走一次完整恢复，包括日志回放到指定时间点
保留策略要与日志过期时间对齐：归档侧保留多久，时间点恢复窗口就有多久，两者不一致会让恢复能力名不副实。
常见配置错误
- 物理全量与逻辑导出都放在同一块盘，一次故障损失全部手段
- 日志归档任务与日志清理任务时间冲突，清理先于归档执行
- 备份任务集中在同一时段，磁盘带宽被互相抢空导致超时
- 只检查任务是否启动，不检查产物是否可用，失败被长期忽略