需监控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 中的数据文件大小与备份目录实际占用，防漏盘