数据库备份失败的处理

备份为什么重要

数据是 MES 最核心的资产。硬件可以换、软件可以重装，数据丢了就是真丢了。

备份失败最可怕的不是失败本身，而是失败了很久没人发现——等到需要恢复时才发现最近的备份是三个月前的。

常见失败原因

一、磁盘空间不足

最常见的失败原因。备份文件持续增长，磁盘满了，备份就失败了。

排查：看备份目录所在磁盘的剩余空间。

解决：

• 定期清理过期备份
• 备份到独立磁盘或网络存储
• 监控磁盘空间，提前告警

注意：备份文件本身的增长可能超出预期。数据库 10GB，备份文件可能也是 10GB，且每天一份，一个月就是 300GB。

二、权限问题

• 备份脚本使用的数据库账号没有导出权限
• 备份目录没有写权限
• 以系统服务方式运行时，账号权限与手工执行不同

常见坑：手工执行成功，但配置成定时任务后失败——因为运行账号不同。

三、数据库连接问题

• 数据库服务未启动
• 连接数达到上限
• 网络问题（如果备份到远程）

四、备份时间窗口不够

数据库很大时，备份耗时长。如果在下一次任务开始前没跑完，会被中断。

解决：

• 选业务低峰期
• 增量备份替代全量备份
• 优化备份参数（比如压缩）

五、锁表影响业务

某些备份方式会锁表，导致业务阻塞。如果系统检测到长时间阻塞主动终止，备份就失败了。

解决：用支持在线备份的工具。

六、任务被误停

有人手工停掉了备份任务，或者服务器重启后任务没自启。

排查步骤

1. 看备份日志，找具体的错误信息
2. 检查磁盘空间
3. 手工执行一次备份，看是否成功
   • 手工成功、定时失败 → 调度或权限问题
   • 手工也失败 → 备份本身有问题
4. 检查备份文件：最新的一份是什么时候的、大小是否正常
5. 尝试恢复（在测试环境）

备份策略建议

3-2-1 原则

• 3 份副本
• 2 种不同介质
• 1 份异地存放

对 MES 来说，最低要求是：

• 本地一份（快速恢复）
• 异地/云端一份（防灾难）

备份频率

保留策略

不要只保留最近一份。建议：

• 保留最近 7 天的每日备份
• 保留最近 4 周的每周备份
• 保留最近 12 个月的每月备份

这样既能应对"昨天误删"，也能应对"三个月前数据被改错"。

备份的验证

没有验证过的备份不算备份。

验证方法

"完整恢复演练"最重要：模拟数据库完全损坏，用备份恢复整个系统，记录耗时。

这个时间就是真实灾难时的恢复时间（RTO）。如果演练下来要 8 小时，就要评估业务能否接受。

自动验证

建议做自动校验：

1. 备份完成后，自动尝试恢复到临时库
2. 检查关键表的记录数是否合理
3. 校验通过才标记为"可用备份"
4. 失败立即告警

监控与告警

备份必须监控，且要监控到"结果"而非"是否执行"：

"文件大小为 0"要单独告警：脚本执行成功了，但生成了空文件，这种情况容易漏过。

除了数据库，还要备份什么

经常被忽略的备份对象：

• 配置文件（应用配置、Nginx 配置）—— 重装时要靠它
• 上传的附件（图纸、报告）—— 这些在文件系统里，不在数据库
• 证书（SSL 证书、密钥）
• 定时任务配置（crontab）
• 部署文档（当时怎么装的、什么版本）

附件特别容易漏。数据库恢复回来了，但图纸全没了，业务照样瘫痪。

一个务实的检查清单

每月检查一次：

• 最近的备份文件存在且大小正常
• 备份任务没有被意外停止
• 磁盘空间充足
• 备份文件能成功恢复（在测试环境）
• 异地备份仍然同步
• 附件目录也有备份
• 恢复所需时间在可接受范围
• 有明确的恢复操作手册
• 有明确的恢复责任人

最后一句

备份是那种"平时看不出价值，出事时决定生死"的工作。

建议把"每季度做一次恢复演练"写进运维制度，并保留演练记录。这既是技术要求，也是合规要求（很多审计会查这一项）。

备份策略与恢复手册模板，[待补充：百华智造 MES 数据备份与恢复指南]。