关键在于调度、执行、验证、清理四环节闭环运转：明确用户级或系统级crontab主体，脚本需显式声明环境与绝对路径，按数据类型选用rsync/tar/mysqldump，日志、校验、清理缺一不可。
把 crontab 定时任务和系统级定时备份真正用起来，关键不是堆命令，而是让调度、执行、验证、清理四个环节闭环运转。它不是“设完就不管”，而是每个动作都可查、可验、可退。
明确调度主体：用户级 vs 系统级 crontab
用户级 crontab（crontab -e）适合单角色、单路径的备份，比如 root 备份 /etc 或普通用户备份个人目录；系统级配置（/etc/crontab 或 /etc/cron.d/）则支持显式指定执行用户，适合混合场景——例如同时以 www-data 同步网站、以 mysql 用户导出数据库、以 root 归档系统配置。
注意格式差异：
- 用户级任务无需写用户名，直接写时间+命令；
- 系统级 /etc/crontab 每行必须含“分 时 日 月 周 用户名 命令”，且命令要用绝对路径（如 /usr/bin/rsync 而非 rsync）；
- /etc/cron.d/ 下的文件命名不能含点或空格，权限建议设为 644，且每行同样需指定用户。
脚本必须独立：环境、路径、权限全显式声明
crontab 执行环境极简，PATH 通常只有 /usr/bin:/bin，不加载 ~/.bashrc。脚本开头必须固定写：
#!/bin/bash PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin export PATH
所有工具调用写全路径：/usr/bin/tar、/usr/bin/rsync、/usr/bin/mysqldump。变量全部用绝对路径定义，比如：
- SOURCE="/var/www/html"
- DEST="/backup/www-$(date +\%Y\%m\%d)"
- LOG="/var/log/backup.log"
脚本保存后务必 chmod +x，并用 sudo -u 用户名 ./script.sh 模拟 cron 环境手动测试一次。
按数据类型选工具：rsync、tar、mysqldump 不混用
不同数据形态对应不同备份逻辑，混用会埋下恢复盲区：
- 活跃文件目录（如网站根目录）→ rsync：用 -avz --delete --exclude={logs/,cache/,tmp/} 实现带过滤的增量同步；
- 静态配置与关键路径（如 /etc、/opt）→ tar：加 --one-file-system 防跨分区，用 -zcpf 直接压缩归档；
- MySQL 数据库 → mysqldump：避免直拷 data 目录，优先用 --single-transaction --routines --events 保证一致性，输出 SQL 文件再压缩。
闭环保障：日志、校验、清理一个不能少
没日志=看不见失败，没校验=不知道备份是否有效，没清理=磁盘迟早爆满。
- 日志重定向要完整：crontab 条目末尾加 >> /var/log/backup.log 2>&1，脚本内也建议用 echo "$(date) ..." >> "$LOG" 记关键节点；
- 轻量校验可落地：同步后远程执行 ssh user@ip "ls -l $DEST | wc -l" 检查文件数，或本地比对 find $SOURCE -type f | wc -l 与 find $DEST -type f | wc -l；
- 清理策略写进脚本：用 find /backup -name "*.tar.gz" -mtime +7 -delete 清理旧归档，或 find /backup -maxdepth 1 -name "www-*" -type d -mtime +30 -delete 清理快照目录。
不复杂但容易忽略。
