只靠 cron mailto 会静默失败，因其仅转发 stdout/stderr，而 mysqldump 关键错误走 stderr；若脚本中重定向为 > backup.sql 2>/dev/null，则失败彻底消失；且 cron 环境 path 极简，mail 命令常不可用，须在脚本内显式调用 /bin/mailx 并校验其存在，同时禁用 --force、用 $? 和 head -c1 验证真实失败，告警内容须含主机名、时间、版本、磁盘空间、最近5行脱敏 stderr 等可定位信息。
只靠 cron MAILTO 会静默失败
cron 的 MAILTO 只转发 stdout/stderr，但 mysqldump 关键错误默认走 stderr —— 一旦你在脚本里写了 > backup.sql 2>/dev/null，整个失败过程就彻底消失。更糟的是，cron 环境 PATH 极简，mail 命令常根本找不到。
必须在脚本内显式调用：/bin/mailx -s "MySQL Backup FAIL on $(hostname)" admin@example.com
- 优先用
mailx，它不依赖交互配置，在 cron 下更稳定；避免mutt，容易卡住 - 发送前加校验：
which mailx >/dev/null || { echo "mailx not found"; exit 1; } - 别把 stderr 重定向到
/dev/null，至少保留到临时文件供后续分析
判断失败只能看 $?，不能看文件大小
mysqldump 成功返回 0，失败返回非 0 码（常见：2=连接失败、3=权限不足、4=找不到表、11=临时 I/O 错误）。if [ $? -ne 0 ] 是唯一可靠依据。
用 ls -l 或 stat -c%s 判断文件大小 >0 完全不可靠 —— gzip 头信息会让空文件也有 20+ 字节；--force 参数会让 mysqldump 忽略错误继续执行，生成空 SQL 却返回 0。
- 删掉所有
--force参数 - 若用了管道压缩（如
mysqldump | gzip），退出码是gzip的，需用${PIPESTATUS[0]}捕获mysqldump真实状态 - 验证 SQL 文件是否真有内容：
head -c 1 backup.sql | wc -c，结果为 0 才说明首字节不可读
告警内容必须带可立即定位的上下文
“备份失败”四个字毫无价值。运维凌晨三点爬起来，需要的是“在哪台机器、哪个库、因何失败、现在磁盘还剩多少、上一次成功是什么时候”。
钉钉/邮件正文固定包含：
-
$(hostname)和$(date) mysqldump --version-
df -h /backup（尤其关注/backup分区） ls -lh /backup/*.sql | tail -3- 最近 5 行 stderr（先过滤敏感字段：
sed '/-p\|password\|@/d'）
错误日志截取要精准：从最后一次 mysqldump 开始，到下一个时间戳前为止，避免混入旧日志。
密码和路径必须脱敏再发
直接把 mysqldump -u root -p123456 或完整报错日志发到钉钉，等于把数据库凭据贴在群里。第一责任在告警脚本本身。
- 改用
--defaults-file=/root/.my.cnf，并确保该文件权限为chmod 600 - stderr 过滤再发送：
sed '/-p\|password\|@/d' - 钉钉 payload 中禁止出现任何明文密码、IP 后缀（如
@10.0.2.5）、绝对路径（如/root/.my.cnf）
真正容易被忽略的不是怎么发告警，而是告警里有没有暴露不该暴露的东西 —— 很多团队的告警流程，恰恰是第一个泄露面。
