Crontab 任务冲突处理：如何避免多个备份任务并发执行

关键在于让备份任务天然互斥：用flock文件锁（crontab中加-n非阻塞参数）、systemd timer（RemainAfterExit+Persistent）、脚本幂等（唯一ID、原子操作、状态文件）及错峰超时策略。

避免多个备份任务并发运行，关键不是调得更准，而是让任务“天然互斥”——哪怕调度时间重叠、脚本意外重启、系统重启后补跑，也绝不会同时执行两个实例。

flock 文件锁：最简可靠的防并发手段

在 crontab 调度层直接加锁，不改脚本，上线快、风险低。它用内核级文件锁保证同一时刻最多一个进程持有锁。

• 写法示例：0 2 * * * flock -n /var/run/backup.lock -c '/opt/scripts/backup-db.sh' || echo "Backup skipped"
• -n（非阻塞）必须加上：抢不到锁就立刻退出，不排队、不堆积，避免后续任务全部卡住
• 锁文件路径要用绝对路径，且所有同类备份任务共用同一个锁文件（推荐 /var/run/ 下，比 /tmp/ 更稳定）
• 切勿在脚本内部调用 flock —— 异常退出时锁可能残留，导致后续所有任务永久失败

systemd timer：适合重要备份的长期方案

当备份涉及生产数据库或需跨系统重启持续保障时，systemd timer 比 crontab 更健壮，它从设计上杜绝并发。

• 定义 backup.service（Type=oneshot，RemainAfterExit=yes），再配 backup.timer（OnCalendar=02:00，Persistent=true）
• systemd 天然保证：前一次执行未彻底结束，下一次绝不会触发 —— 不依赖脚本判断，也不靠外部锁
• 可直接设置资源上限（如 MemoryMax=512M）、超时（RuntimeMaxSec=1800）、失败重试策略
• 执行状态一目了然：systemctl status backup.timer 查下次时间，journalctl -u backup.service 看详细日志

脚本自身要“幂等”：多跑一次也不能出错

即使调度层防护到位，脚本仍应具备容错能力——这是故障恢复或手动触发时的底线。

• 每次生成唯一标识（如 $(date +%Y%m%d_%H%M%S)_$$），临时文件、日志、归档路径都带该 ID，避免覆盖或冲突
• 导出前检查目标文件是否存在且时间有效；若距今不足 24 小时，直接跳过（与 cron 周期配合兜底）
• 用 mysqldump --single-transaction 保障一致性；落盘用 mv tmp.sql final.sql 原子操作，防止部分写入
• 关键步骤写入状态文件（如 /var/lib/backup/status），含开始/结束时间、成功标记，供下次启动校验

错峰 + 超时：降低冲突发生概率

再强的锁机制，也挡不住大量长耗时任务在同一秒启动造成的 IO 或 CPU 尖峰。主动错开是成本最低的减压方式。

• 同类备份任务不要全设在 0 2 * * *，可分别设为 7 2 * * *、15 2 * * *、22 2 * * *
• 对每小时执行的任务，避免统一用 0 * * * *，改用 3 * * * *、17 * * * * 等偏移分钟
• 脚本中设置硬性超时（如 timeout 3600 /opt/scripts/backup-db.sh），防止挂起任务长期占锁
• 宝塔面板用户可在“计划任务”备注栏标注资源特征（如“高IO/长耗时”），便于后续维护时识别调度风险