备份这件事的残酷之处在于：平时看不出问题，出事时才发现备份是不可用的。最近看到 Bytebase 升级文档里反复强调「升级前先备份元数据库，不支持原地降级」，联想到内网系统的备份实践，聊几个要点。
备份不是复制文件
很多人理解的备份是把数据目录复制一份。但一个可用的备份要满足三个条件：数据一致、可恢复、恢复时间可接受。
数据一致是最容易被忽略的。数据库在写入过程中复制文件，得到的是一份可能损坏的副本。要么停服务复制，要么用数据库自带的逻辑备份或一致性快照。
3-2-1 原则
至少三份副本，存在两种不同介质上，其中一份异地。
内网环境下「异地」常常做不到，退而求其次：至少一份在不同的物理机器上，最好是不同楼栋或不同机房。
要备份的不只是数据库
一份完整的恢复清单应该包括：
数据库数据和结构。
配置文件。这一项最常被漏掉，而系统的行为高度依赖配置。
证书和密钥。重新签发证书的流程可能要几天。
上传的文件和附件。这些通常不在数据库里。
部署脚本或镜像信息。没有它，你得从零重建运行环境。
演练比备份更重要
没验证过的备份等于没备份。建议每季度做一次真实恢复演练：
随机选一个时间点，在一个隔离环境里完整恢复到那个时间点，然后跑一遍冒烟测试。
记录整个过程的耗时。这个数字就是你的真实 RTO，写进方案里。
演练中经常暴露的问题：备份文件损坏、备份不完整（漏了某个库）、恢复脚本路径写死、依赖的外部服务不可用。
监控备份本身
备份任务失败要告警。静默失败的备份是最危险的——你以为有，实际没有。
要监控的指标：备份是否按时执行、备份文件大小是否合理（突然变小通常意味着失败）、备份是否成功传输到目标位置。
一个具体的建议
在内网系统里，把恢复演练做成例行事项而不是应急事项。出事时的压力环境下，第一次执行恢复流程的成功率很低。提前跑过几次，真出事时才有把握。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。