crontab是调度器而非备份工具，长效归档依赖脚本设计、定时触发与策略落地三者配合：脚本须自包含（指定解释器、绝对路径、时间戳命名、mkdir -p建目录、tar校验），用find自动清理旧文件，并在crontab中显式声明path/home、重定向日志以便可追溯、可验证。
Crontab 本身不是备份工具，而是调度器。真正实现长效归档，靠的是“脚本设计 + 定时触发 + 策略落地”三者配合。关键不在多复杂，而在每一步都稳得住。
备份脚本必须自包含、可独立运行
脚本不能依赖你的登录环境，它得在 crond 的极简上下文中也能跑通：
- 开头写死解释器：#!/bin/bash
- 立即设置 PATH：PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin; export PATH
- 所有命令用绝对路径，比如 /bin/tar、/usr/bin/find、/usr/bin/mysqldump
- 时间戳用 date +%Y%m%d_%H%M，避免分钟级重名
- 目标目录用 mkdir -p 创建，不假设已存在
- 备份后加校验：tar -tzf $backup_file >/dev/null 2>&1 || { echo "Corrupted backup"; exit 1; }
归档生命周期要主动管理
自动备份若不清理，迟早撑爆磁盘：
- 用 find 命令按时间删旧文件，例如：find /backup -name "backup_*.tar.gz" -mtime +30 -delete
- 若需保留不同粒度（如7天全量+30天日志），建议按命名规则分类存放，再分批清理
- 删除前加 -maxdepth 1，防止误删子目录下同名文件
- 清理动作也记日志，方便回溯“谁删了什么、什么时候删的”
定时任务要带环境、有痕迹、可验证
crontab 条目不是写完就完事：
- 在 crontab -e 中显式声明 PATH 和 HOME，例如：
PATH=/usr/local/bin:/usr/bin:/bin
HOME=/home/app
0 3 * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1 - 日志重定向必须写全，>> 是追加，2>&1 是把错误也写进去
- 不要依赖系统 mail，多数服务器没配本地邮件服务，输出不重定向就等于丢失
- 每次改完 crontab，执行 crontab -l 确认内容已生效
长效靠的是机制，不是一次配置
- 每月手动检查一次 /var/log/backup.log 最近10条，看有没有 “failed” 或 “No such file”
- 每季度抽一个备份包，tar -tzf 验证可读性，再随机解压一个文件确认内容完整
- 节点多时，统一脚本路径（如 /usr/local/bin/backup.sh）、统一日志位置（/var/log/backup.log），便于批量巡检
不复杂但容易忽略。
