从没恢复过的备份

一句话总结

从未实际恢复过的备份，不是备份，只是一个被相信是备份的文件。备份价值只能通过恢复来证明。

为什么这是个问题

备份失败通常并不显眼：脚本报错却没人检查退出码，于是每天堆积 0 字节文件；备份表清单过时，新建的表被漏掉；备份文件与源数据放在同一块磁盘，磁盘损坏时一起消失。

在所有这些情况下，每日检查报告仍然写着“备份正常”。 因此，问题会在真正需要备份的那一天首次被发现。

最常被遗漏的是数据之外的对象。缺少序列、权限与触发器的备份，即使恢复完成，应用也无法启动。做过一次恢复演练，就能在演练当天发现；没做过，就会在事故当天发现。

备份价值只能通过恢复证明

运维会议上常听到“备份每天都正常运行”。接下来只应问一个问题：

“上一次真正从这份备份恢复是什么时候？”

如果回答是“从来没有”，它就不是备份，而只是被相信是备份的文件。现实中会发生以下情况。

• 备份脚本一直报错，却未检查退出码，每天都生成 0 字节文件
• 备份执行成功，但目标表清单过时，漏掉新建表
• 备份文件位于同一块磁盘，磁盘故障时一起消失
• 恢复需要 3 小时，却直到事故当天才知道
• 数据能恢复，但缺少序列、权限和触发器，应用无法启动

最后一种尤其常见。只有数据并不等于能够恢复。

备份的三个维度

维度	问题	指标
备份什么	只有数据？是否包含 schema、权限、序列？	备份对象清单
多久一次	最多允许损失多少数据？	RPO（恢复点目标）
多快恢复	最多允许停机多久？	RTO（恢复时间目标）

RPO 与 RTO 不是技术团队单独决定的值，而由业务要求决定。必须询问业务方：“允许损失一小时的数据吗？”答案会决定备份周期与方式。

• RPO 24 小时 → 每天一次全量备份即可
• RPO 1 小时 → 全量备份 + 增量／日志备份
• RPO 接近 0 → 复制（replication）+ 日志时间点恢复

多数 SI 项目没有进行这场对话。 因此只有“每天凌晨执行备份”这个技术事实，却没人知道它是否满足业务需求。

迁移中的备份——时间就是选择空间

上线迁移时，备份的性质不同，因为它必须能作为回滚手段。

凌晨 2 点开始、4 点前必须决策的工作中，需要 3 小时才能恢复的备份不是可用选项。因此迁移计划必须包含以下两行。

백업 소요 시간 : 실측 __분
복구 소요 시간 : 실측 __분   ← 이 값이 롤백 판단 시한을 결정한다

如果恢复耗时过长，就要准备其他方式。

• 存储／虚拟化层快照——通常快得多
• 只备份要变更的表——如果无需回滚全部数据
• 设计可回滚的 schema 变更（扩展—迁移—收缩）

备份清单中常遗漏的对象

只备份数据库并不能保证恢复。

• 数据库账户与权限——恢复后的数据库没有账户，应用无法连接
• 序列／自增当前值——值回退会造成主键冲突
• 视图、触发器、存储过程、函数
• 应用配置文件——迁移章节反复强调的内容
• 批处理调度定义
• 证书与密钥

因此，备份对象清单必须作为文档维护，新对象出现时还要有更新流程。自动备份若覆盖“整个 schema”会解决许多问题，但也只有实际验证过才知道。

恢复演练流程

演练应当在非生产服务器上，只依赖备份文件完成。

1. 백업 파일을 별도 서버/디렉터리로 가져온다 (운영에서 직접 복구하지 않는다)
2. 빈 상태에서 복구를 수행한다 — 시작·종료 시각을 기록
3. 검증
   - 테이블 수, 주요 테이블 행 수
   - 시퀀스 현재값
   - 계정·권한·인덱스·제약
   - 애플리케이션 기동과 로그인 (가능하면)
4. 결과를 문서로 — 소요 시간, 발견된 누락, 조치
5. 발견된 누락을 백업 대상 목록에 반영

第 3 步的最后一项才是演练的真正价值：在演练中，而不是事故当天，发现“恢复完成了，但应用无法启动”。

自动验证备份

每次都由人做完整演练不现实，但至少应自动完成以下检查。

# 매일 백업 직후 자동 검증
1. 백업 파일이 생성됐는가 (존재 + 크기 > 최소 기준)
2. 백업 명령의 종료코드가 0인가        ← 놀랍게도 이걸 안 보는 곳이 많다
3. 파일이 열리는가 (압축이면 무결성 검사)
4. 예상 객체가 포함돼 있는가 (테이블 목록 grep)
5. 주 1회: 실제 복구 후 행 수 비교

必须特别强调第 2 项。备份脚本失败，而 cron 吞掉错误，就不会有人知道。必须检查退出码，并在失败时发送告警。“从没收到过备份失败通知”不一定表示“备份一直成功”，也可能表示根本没有通知机制。

保留与删除

备份会无限积累，因此必须制定策略。

일 백업: 14일 보관
주 백업: 8주 보관
월 백업: 12개월 보관

保留数量就是可回退范围。 14 份日备份意味着可以回到两周内的某一天。如果业务可能提出“恢复三个月前的数据”，就要保留相应期限，这同样需要与业务方达成一致。

删除也应自动化，但必须有安全措施。现实中发生过“删除旧备份”脚本因缺陷清空全部备份的事故。只能按日期条件删除，设置最小保留数量下限，并在删除前把清单写入日志。

备份还必须放在别处

位于同一服务器、同一磁盘的备份，会在服务器故障时一起消失。至少要复制到其他存储，最好位于其他物理地点。

封闭网络无法使用外部云时，可使用内部专用备份存储、磁带或外接介质，同时必须制定介质出入流程并加密。这也是上线前需要整理的事项。

在实际项目中

制定迁移计划时，备份有时会直接变成时间计算。恢复需要 3 小时，就必须在作业结束前 3 小时做出回滚决定。没有提前算清楚，凌晨四点才发现“现在回滚，早晨业务开始前来不及”，就已经没有选择。

因此，备份项不能只写“备份完成”，而要写明文件路径与恢复耗时。迁移结果报告中要求记录实际文件名，也是为了避免真正需要时还要花时间寻找。