要监控 MySQL 备份任务的状态，核心是掌握备份是否成功、是否按时执行、以及备份文件是否完整可用。不能只看脚本有没有跑完，得验证结果。
检查备份脚本的退出状态和日志输出
MySQL 备份（如 mysqldump、mydumper 或物理备份工具）执行后会返回退出码。0 表示成功，非 0 通常代表失败。在定时任务（crontab）中务必捕获并记录这个状态：
用 && 连接命令，确保只有前一步成功才执行后续操作（例如压缩或上传） 把标准输出和错误重定向到日志文件，比如：mysqldump -u user -p'pass' db_name > /backup/db_$(date +\%F).sql 2>> /var/log/backup.log 在脚本末尾加 echo $? >> /var/log/backup.log，明确记录退出码验证备份文件是否有效且非空
备份文件存在 ≠ 备份成功。常见问题包括权限不足导致写入空文件、网络中断导致 dump 中断、或 mysqldump 因锁表失败而提前退出。
检查文件大小：test -s /backup/db_$(date +\%F).sql 可判断是否为空 快速验证结构：用 head -n 20 /backup/db_$(date +\%F).sql | grep -q "CREATE TABLE" 确认开头有建表语句 对关键库可定期抽样导入测试库（不需全量），确认 SQL 可被解析执行建立轻量级状态追踪机制
不需要上整套 Prometheus+Grafana，用简单方式也能实现可观测性：
每次备份完成后，写入一个状态标记文件，如 /backup/last_success.timestamp，内容为时间戳 用另一脚本定时检查该文件是否在预期窗口内更新（例如 24 小时内），超时即告警 配合邮件或企业微信 webhook，在失败时推送简明信息：“db_name 备份失败，退出码 2，日志见 /var/log/backup.log”区分逻辑备份与物理备份的监控重点
mysqldump 属于逻辑备份，关注 SQL 文件完整性；XtraBackup 等物理备份则要额外确认：
备份目录下是否有 xtrabackup_binlog_info 和 xtrabackup_checkpoints 文件 执行 xtrabackup --prepare 是否能顺利完成（可选轻量 prepare 验证） 对比 innodb_data_file_path 中的数据文件大小与备份目录实际占用，防漏盘
