backup-and-disaster-recovery

备份与灾难恢复

为最坏情况做好准备：数据库丢失、主机停机一周、部署包遭到污染、勒索软件加密了所有数据。关键在于提前准备，而不是事后应对。

---

适用场景

• 为新系统设置备份
• 审查并验证备份架构
• 制定 RPO（恢复点目标）和 RTO（恢复时间目标）
• 开展灾难恢复演练
• 事故发生后排查备份缺口
• 为勒索软件、数据损坏或内部威胁制定计划
• 迁移到新平台（灾难恢复规划应纳入迁移计划）

不适用场景

• 正在进行的事故响应（使用 incident-response）
• 常规部署回滚（使用 launch-runbook）
• 代码或内容版本控制（由 Git、CMS 修订历史记录负责）
• 常规数据库快照（使用此技能进行设置；常规审查纳入监控）

---

必需输入

• 涉及的系统（数据库、文件存储、代码、配置、密钥）
• 托管平台和服务提供商
• 现有备份工具及其覆盖范围
• 可接受的数据丢失量（以时间衡量）
• 可接受的停机时长（以时间衡量）
• 合规要求（某些法规规定了具体的备份标准）

---

框架：4 个问题

每份灾难恢复计划都应明确回答以下四个问题。

问题 1：哪些内容需要恢复？

列出所有保存状态的系统，并按关键程度分类。

第 1 级：必须恢复。 没有这些系统，业务就会停摆。（客户数据库、交易日志、主要内容存储。）

第 2 级：应该恢复。 丢失会造成严重影响，但并非致命。（分析数据、日志、辅助服务。）

第 3 级：最好恢复。 容易重建。（缓存、派生数据、临时状态。）

级别决定 RPO、RTO、备份频率和存储开销。

问题 2：可接受的数据丢失量是多少？（RPO）

RPO 是可接受丢失数据的最大时间范围，以时间衡量。

• RPO = 1 小时：需要每小时备份或持续复制
• RPO = 1 天：可接受每日备份
• RPO = 1 周：可接受每周备份

对于大多数生产数据，目标是将 RPO 控制在 1 小时以内。对于关键财务系统，目标是接近零的 RPO（持续复制）。

对于派生数据或可重建数据，RPO 为 1 天或更长也可以接受。

问题 3：可接受的停机时长是多少？（RTO）

RTO 是灾难发生后恢复服务所需时间的上限。

RTO 目标	意味着
< 5 分钟	热备，并自动故障转移
< 1 小时	温备，并手动故障转移；或从近期快照快速恢复
< 24 小时	冷备份，并有记录在案的恢复流程
数天至数周	尽力恢复，并接受长时间停机

RTO 决定架构开销。严格的 RTO（< 1 小时）成本高昂；宽松的 RTO（数天）成本低廉。

问题 4：可能发生什么灾难？

针对具体情景制定计划。不同情景的应对方式各不相同。

硬件故障。 磁盘损坏。标准备份即可解决。大多数现代主机都会自动处理。

服务提供商故障。 区域或供应商发生故障。若要实现较短的 RTO，需要跨区域或跨服务提供商冗余。

数据损坏。 错误的迁移、有缺陷的程序、意外删除。需要支持时间点恢复。最新备份可能已经损坏，因此需要保留历史备份。

勒索软件或系统遭入侵。 攻击者加密或删除数据。备份必须不可变或与网络隔离，否则攻击者也会攻击备份。

账户遭入侵。 攻击者获取管理员凭据并删除所有内容。防护方式与应对勒索软件相同：不可变备份、独立的访问控制。

供应商锁定账户。 账户被暂停、发生账单纠纷或供应商消失。需要在该供应商之外保存备份。

内部威胁。 心怀不满的员工删除或窃取数据。需要审计日志、职责分离和不可变备份。

只针对硬件故障设计的备份策略算不上真正的策略，只是应对最简单情形的方案。

---

工作流

步骤 1：盘点状态

将所有持有状态的系统列入清单：

系统	数据类型	层级	当前备份	已测试？

如果无法列出，就无法保护。盘点本身往往会暴露漏洞（比如突然发现“我们忘了那个数据库”）。

步骤 2：按层级设定 RPO 和 RTO

针对每个层级，商定 RPO 和 RTO。让灾难发生时会受到影响的人员签字确认。

对于缺乏基础设施投入支撑的理想化目标，应提出异议。没有热备的系统，RTO 设为 5 分钟并不现实。

步骤 3：验证或设计备份架构

对于每个系统，确保：

• 频率符合 RPO。
• 保留期限足以支持时间点恢复（生产数据通常至少保留 30 天）。
• 存储位置与源数据分离。相同磁盘、相同账户、相同区域都不够。
• **至少部分备份副本具备不可变性或采用一次写入存储。**这有助于防范勒索软件。
• **静态加密。**这是合规的标准要求。
• **恢复流程经过测试。**未经测试的备份不算备份。

“3-2-1 规则”是一个很实用的起点：数据保留 3 份副本，使用 2 种不同的存储类型，其中 1 份存放在异地（或不同账户、不同平台）。

步骤 4：编写恢复操作手册

为每个系统编写操作手册：

1. 如何检测灾难（交叉引用监控信息）
2. 如何决定是否恢复（决策标准、授权人）
3. 具体的恢复步骤（命令、截图、操作顺序）
4. 如何验证恢复是否成功
5. 如何切回流量
6. 通信模板（状态页面、客户通知）

这份操作手册是为某人职业生涯中最糟糕的夜晚准备的。写给那个疲惫又惊慌的自己看。

步骤 5：开展演练

绝不能等到真正发生灾难时才进行首次恢复。

演练可以分为：

• **桌面演练：**在纸面上过一遍操作手册，有助于发现计划中的漏洞。
• **部分演练：**恢复到非生产环境。验证数据，并确认步骤有效。
• **全面演练：**模拟灾难。进行生产故障转移或完整恢复。信心最高，风险也最大。

对于大多数团队：每季度进行一次桌面演练，每年进行一次部分演练，并在重大上线前或重大架构变更后进行全面演练。

步骤 6：记录演练结果

每次演练后，记录：

• 测试了什么
• 哪些环节有效
• 哪些环节出错
• 实际 RPO 和 RTO 是多少（与目标相比）
• 后续行动项

如果目标 RTO 是 1 小时，实际却用了 6 小时，那么这个目标就是空谈。要么弥补差距，要么修订目标。

步骤 7：安排下一次演练

将演练列入日历，并指定负责人。备份如果不经过演练，最终会变得毫无用处。

---

专题

数据库时间点恢复

许多托管数据库都支持在保留期限内进行时间点恢复（PITR），保留期限通常为 7–35 天。这通常可以实现数秒到数分钟的 RPO。

如需更长的保留期限，应定期将数据导出到不可变存储。

仅靠 PITR 并不足够。如果数据库服务本身遭到入侵，PITR 也会一并失效。务必至少保留一份位于源服务之外的备份。

文件存储备份

对象存储（S3、GCS、Azure Blob）通常提供：

• 版本控制（恢复被覆盖的对象）
• 复制（跨区域）
• 对象锁定或不可变性（防止删除）

对于生产关键存储桶，应同时启用这三项功能。不要依赖存储提供商的默认保留设置。

代码和配置备份

代码存放在 Git 中。Git 托管平台（GitHub、GitLab 等）可以作为备份，但单一托管平台也是单点故障。

对于关键性较高的代码：

• 镜像到第二个托管平台或自己的服务器
• 定期导出到离线介质

配置和密钥需要单独处理：

• 基础设施即代码：存放在 Git 中，并进行镜像
• 运行时配置：与系统一同备份
• 密钥：存放在密钥管理器中，并为其单独制定备份方案

备份的备份

备份系统本身也可能发生故障。备份元数据、备份凭据、加密密钥：所有这些都必须备份。

如果备份使用的密钥丢失了，这份备份就毫无用处。

合规备份

某些法规要求特定的保留期限（例如，财务数据需保留 7 年）。请遵守适用的最高标准。

不要将合规保留与运营备份混为一谈。合规通常允许更慢的恢复速度（只需最终能够提供数据）。

---

故障模式

未经过测试的备份。 这是最常见的故障。备份看起来正常，但恢复失败。请进行测试。

备份与源数据位于同一账户或区域。 账户遭到入侵或区域发生故障时，两者都会受影响。

没有不可变性。 勒索软件也会加密备份。请使用对象锁定或隔离存储。

RTO 和 RPO 未经测量。 目标写着“1 小时”，但没有人验证过实际 RTO。除非证据证明并非如此，否则应假设实际耗时会超过目标。

恢复操作手册只存在于某人的脑海中。 此人离职或无法联系时，操作手册也就没了。请记录下来。

有备份，但没有灾难恢复计划。 “我们有备份”不算计划。计划包括操作手册、架构和演练。

过度乐观。 “这种事不会发生在我们身上。”它会发生。请按它会发生来制定计划。

备份太旧或太新。 需要保留某个时间点的历史记录（以防数据损坏未能立即发现）。每日快照，保留 30 天以上。或者采用持续复制，并定期单独创建快照以留存历史记录。

因为“太忙”而跳过演练。 灾难发生时，你会更忙。

没有沟通计划。 恢复数据只完成了一半工作。告知客户、利益相关方和内部团队当前情况，则是另一半。

---

输出格式

灾难恢复计划文档包括：

• 清单： 每个有状态系统
• 分级： 每个系统的关键程度
• 目标： 每个级别对应的 RPO 和 RTO
• 架构： 备份工具、频率、存储和不可变性
• 操作手册： 每个系统的恢复流程
• 演练计划： 何时测试哪些内容
• 演练记录： 以往演练的结果
• 沟通模板： 发生实际灾难恢复事件时的沟通内容

---

参考文件

• references/restore-runbook-template.md：可填写的恢复操作手册模板，涵盖检测、授权、步骤、验证和回滚。