linux定时备份需构建可追溯信号链：日志必须结构化记录退出码、时间戳、产出大小；cron需重定向输出并用logrotate管理；结合prometheus+grafana实现分级告警。
Linux 定时备份失败，光靠“有没有生成文件”判断远远不够。真正关键的是把每次执行变成可追溯、可验证、可告警的完整信号链——日志记录是起点，排查逻辑才是核心。
备份日志必须包含的三项基础信息
不要只依赖脚本里零散的 echo，日志需结构化记录三类硬指标：
-
退出码（exit code）：脚本最后用
$?获取，0 表示成功，非0 均为失败，不同数值对应不同错误类型（如 mysqldump 的 2 是连接拒绝，11 是 I/O 错误） -
时间戳：用
date +%s记录精确到秒的完成时间，便于计算间隔、识别超时 -
产出大小：用
stat -c%s /path/to/backup.sql 2>/dev/null || echo 0获取文件字节数，大小为 0 或远低于基线值，往往比退出码更早暴露问题（比如权限不足导致空文件）
让 cron 日志真正可用的实操配置
默认 cron 不会把脚本输出写进系统日志，必须主动重定向：
- 在 crontab 条目末尾加
>> /var/log/backup/mysql.log 2>&1，确保 stdout 和 stderr 都落盘 - 避免日志爆炸：用
logrotate管理，检查/etc/logrotate.d/rsyslog中是否对/var/log/backup/目录启用create 644 root root，否则新日志可能因权限缺失无法生成 - 实时盯梢：运行
tail -f /var/log/backup/mysql.log，配合grep -E "(ERROR|fail|exit)"快速过滤异常行
从日志线索快速定位四类典型失败
看到日志里的某条记录，立刻对应到根源：
-
“No such file or directory”：脚本中路径写错，或 cron 环境变量缺失（PATH 不含 /usr/bin），建议在脚本开头显式声明
PATH=/usr/local/bin:/usr/bin:/bin -
“Permission denied”：不是用户没权限，而是目标目录（如 /mnt/backup）挂载选项含
noexec或属主不匹配；用ls -ld /mnt/backup和id -un对照确认 -
日志有成功记录但文件大小为 0：大概率是并发冲突——多个相同任务同时启动，后一个覆盖前一个临时文件；检查 crontab 是否被 Ansible 多次写入，或用
ps aux | grep backup查看进程数是否异常 -
完全无日志输出：先确认
systemctl is-active crond是否 running；再检查该用户 crontab 是否生效（crontab -l），以及任务时间格式是否合法（如星号间多空格会导致整行被忽略）
用 Prometheus + Grafana 把日志变成监控信号
日志文本只是原始数据，要让它驱动告警，得转化成指标：
- 在备份脚本末尾追加：
echo "mysql_backup_last_exit_code $(echo $?)" > /var/lib/prometheus/textfile_collector/backup.prom，同理写入时间戳和大小 - Prometheus 抓取该文件后，在 Grafana 中建面板：用
mysql_backup_last_exit_code != 0显示失败趋势，用time() - mysql_backup_last_success_timestamp > 86400标红超期任务 - 告警规则分级：exit_code == 2 触发电话告警；size_bytes
