数据库备份怎样监控才稳

要保证数据库备份“稳”，核心不是某一条命令，而是可观测 + 可告警 + 可恢复验证的一整套机制。下面按“监控什么 → 怎么监控 → 常见坑”来说。

一、先明确：备份监控要管 4 件事

1. 备份是否发生（没跑比跑失败更可怕）
2. 备份是否成功（退出码 / 日志）
3. 备份是否完整可用（能恢复才是真备份）
4. 备份是否合规（保留期、异地、加密）

二、监控“备份是否发生”

1. 定时任务层监控

• 如果用 crontab / 调度系统：
  • 监控上次成功执行时间
  • 超过 N 小时未执行 → 告警

示例（伪逻辑）：

now - last_success_time > 25h  → 告警

2. 元数据监控（最稳）

备份完成后，写一条记录到监控表或日志系统：

INSERT INTO backup_log(db, type, start_time, end_time, status)
VALUES ('order', 'full', now(), now(), 'success');

然后监控：

• 最近一条 status=success 的时间

✅ 比“看文件存不存在”可靠得多

三、监控“备份是否成功”

1. 退出码必须有

• mysqldump / pg_dump / xtrabackup 必须检查 $?
• 任何非 0 → 失败

2. 日志集中化

• 备份日志统一采集到：
  • ELK / Loki / 云日志
• 关键词告警：
  • ERROR
  • failed
  • timeout
  • Lock wait

四、监控“备份是否真的能用”（最关键）

✅ 定期恢复演练（强烈建议）

• 每周 / 每月：
  • 随机挑一个备份
  • 恢复到沙箱库
  • 校验：
    • 表数量
    • 行数
    • 关键业务数据

✅ 自动校验（轻量）

• 文件级：
  • md5 / sha256 一致性
• 逻辑级：
  • 备份后跑 CHECKSUM TABLE
• 物理备份：
  • xtrabackup --prepare 必须成功

五、备份留存与合规监控

监控以下指标：

• 备份文件是否存在
• 是否超过保留天数
• 是否异地副本（对象存储 / 异地机房）
• 是否加密（尤其云上）

告警示例：

• 本地有，异地没有 → 高危
• 90 天没清理 → 成本 & 风险

六、推荐监控架构（实战可用）

数据库
  ↓
备份脚本（退出码 + 日志 + 状态表）
  ↓
日志系统 + 监控系统（Prometheus / Zabbix / 云监控）
  ↓
告警（钉钉 / 企业微信 / 电话）
  ↓
定期恢复演练（人工 or 自动化）

七、常见“看起来稳其实很危险”的坑

❌ 只监控“文件生成了”
❌ 备份成功但从不恢复
❌ 从库备份，主库挂了才发现数据不全
❌ 备份写了盘，但磁盘满了没人知道
❌ 云快照 ≠ 逻辑备份（一致性问题）

八、一句话总结

数据库备份稳不稳，不看它“有没有跑”，而看它“能不能恢复，且你知不知道它没跑”。

如果你愿意，我可以：

• 按 MySQL / PostgreSQL / Oracle 给具体监控方案
• 或直接帮你写一套 备份 + 监控 + 告警脚本模板