linux自动化备份需三重防护：调度层用flock或systemd timer防任务重叠，脚本层通过唯一id、状态文件和原子写入实现幂等，系统层用cpuquota、memorymax及ulimit限制资源消耗。
配置 Linux 自动化备份任务的并发与资源限制，核心目标不是“让多个备份同时跑”，而是“确保同一任务绝不重叠执行 + 关键资源不被耗尽”。这需要在调度层、脚本层和系统层三方面协同控制。
flock 文件锁：最简可靠的单任务排他保障
这是防止备份脚本并发执行的第一道防线，轻量、直接、无需改脚本。
- 在 crontab 中用 flock -n 包裹命令，例如：
0 2 * * * flock -n /var/run/backup.lock -c '/opt/scripts/backup-db.sh' || echo "Backup skipped: another instance running" - -n 表示非阻塞——抢不到锁就立即退出，避免任务排队堆积
- 锁文件必须用绝对路径（推荐 /var/run/ 而非 /tmp/），且所有同类备份任务共用同一个锁文件
- 切勿在脚本内部调用 flock，否则异常退出可能导致锁残留，后续所有任务永久卡住
systemd timer：替代 cron 的健壮调度方案
当备份任务重要性高、需跨重启持续运行，或要集成资源控制时，systemd 是更现代的选择。
- 定义一个 backup.service（Type=oneshot，RemainAfterExit=yes）
- 配一个 backup.timer（OnCalendar=02:00，Persistent=true）
- systemd 天然保证：前一次执行未彻底结束，下一次绝不会触发——无需任何脚本判断或外部锁
- 可直接设置内存上限：MemoryMax=512M；超时强制终止：RuntimeMaxSec=1800；失败后一小时内最多重试 3 次：StartLimitIntervalSec=3600、StartLimitBurst=3
脚本内资源约束与幂等设计
即使调度层已防并发，脚本本身也应具备“多跑一次也不出错、不爆资源”的能力。
- 每次执行生成唯一 ID（如 $(date +%Y%m%d_%H%M%S)_$$），临时文件、日志、归档路径全部带上该 ID，避免命名冲突和覆盖
- 数据库导出前检查目标文件是否存在且时间戳有效；若存在且距今不足 24 小时，直接跳过（作为 cron 周期的兜底）
- 关键步骤写入状态文件（如 /var/lib/backup/status），含开始时间、结束时间、成功标记，供下次启动校验
- 使用 mysqldump --single-transaction 保障一致性；落盘操作用 mv tmp.sql final.sql 实现原子写入，防止部分写入
系统级资源限制：防止备份失控拖垮整机
大型备份（如全库导出+压缩）可能瞬间吃光 CPU、内存或文件句柄，需提前设限。
- 在备份服务 unit 文件中配置：
CPUQuota=70%（限制 CPU 占比）
MemoryMax=1G（硬性内存上限）
TasksMax=50（限制进程数，防 fork 爆炸） - 若用 crontab 调度，可在脚本开头加 ulimit：
ulimit -v 1048576 # 限制虚拟内存 1GBulimit -n 4096 # 限制打开文件数 - 对长期运行的备份传输（如大文件 scp/rsync），可用 cpulimit 动态限频：
cpulimit -e rsync -l 30（将 rsync 进程 CPU 占用压到 30%）
