需监控mysql备份状态，包括退出码是否为0、备份文件非空且含CREATE table语句、写入时间戳标记并定时校验，物理备份还需检查xtrabackup关键文件及prepare结果。
要监控 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 中的数据文件大小与备份目录实际占用，防漏盘