备份计划怎么设计
备份计划是把任务按数据量、窗口与依赖关系排到时间轴上：大体量全量错峰、数据库一致性备份先于依赖它的文件备份、同一存储上的任务串行化避免 IO 互抢，并为失败任务预留重试时间片。计划设计的目标不是排满，而是每个任务都能在窗口内稳定跑完。
基本信息
| 输入 | 各系统数据量与变化率、存储吞吐实测值、可用的低峰窗口长度 |
|---|---|
| 输出 | 任务编排表、监控项、失败重试策略、超时与告警阈值 |
| 关键约束 | 备份窗口不能与业务高峰、批量作业、其他备份任务重叠 |
| 复查节奏 | 架构变更、数据量翻倍或演练发现问题后重新评估排布 |
典型使用场景
- 多系统共享一套备份存储：按吞吐实测值给任务分配时段，避免互相拖慢
- 数据库与文件依赖链：先做数据库一致性备份，再做依赖它的应用文件备份
- 节假日与发布日历联动：重大变更前加做一次全量，变更后复核增量链
- 跨机房任务编排：统一时钟与时区，避免先后顺序与预期不符
- 失败重试安排：为任务预留第二时间片，避免失败后只能等到第二天
任务编排要点（文字示例）
任务编排要点（文字示例）
周一至周五：增量，01:00-03:00 窗口，容器与 Web 目录先跑
周六：全量数据库（04:00 起），完成后跑文件全量（避开同一存储）
每日：日志与 binlog 归档，每 30 分钟一次，窗口独立且很短
发布日：发布前加做一次全量并登记到备份目录
失败策略：任务失败自动重试 1 次；连续两次失败触发告警并记录到目录编排要素检查表
| 要素 | 要确认的内容 | 常见问题 |
|---|---|---|
| 窗口 | 任务实际耗时是否留出余量 | 按理论速度估算，实际跑完时已挤进业务高峰 |
| 依赖顺序 | 数据库与其下游文件的先后关系 | 文件备份先跑，导致数据库副本对不上文件状态 |
| 并发度 | 同一存储上的并行任务数 | 多任务争抢 IO，集体超时 |
| 重试 | 失败后是否有第二时间片 | 失败只能等次日，RPO 直接翻倍 |
| 时钟 | 各调度器时区与 NTP 是否统一 | 跨机房任务先后顺序与预期不符 |
计划不是一次性的：每次演练与故障后都要复核调度是否仍满足 RPO，数据量增长是最常见的失效原因。
不要把多个大任务排在同一个启动时刻：看似节省窗口，实际是同盘争抢 IO，最终全部超时。