备份策略：从 3-2-1 规则到经过测试的恢复

仅有副本，不能恢复业务流程

周一发现项目文件夹丢失，但同步已经将周末的删除传播到所有位置。另一家企业虽然保留数据，却因缺少许可证文件、数据库配置和管理员访问，在服务器故障后无法重新运行库存管理。两个例子都说明，策略不能只解释副本存放在哪里。

目标应是：特定流程在约定时间内，以可接受的数据状态重新工作。小型手工业企业可能需要与全天候订单系统不同的方案。经济性规划应从这种差异开始。

先决定可接受的数据丢失，再安排备份频率

恢复点目标（RPO）以时间界定可接受的数据丢失。四小时 RPO 意味着故障时，必须拥有距故障不超过四小时的可恢复数据点。恢复时间目标（RTO）描述服务恢复前允许的目标时间。只做夜间备份无法满足四小时 RPO，下载很快也不能证明满足 RTO。

这些目标必须由业务团队同意。从邮件重新录入订单可以弥补部分数据丢失，但仍消耗人员时间。等待硬件、供应商可用性以及最终业务验证，都属于实际中断时间。以下案例是规划示例，不是普遍适用的建议。

• 项目文档：RPO 四小时、RTO 一个工作日；每天多个恢复点，并能有针对性地恢复文件夹。
• 当前订单：RPO 一小时、RTO 四小时；需要数据库保护及立即可用的恢复环境。
• 公共网站：RPO 24 小时、RTO 八小时；内容、应用、配置和域名管理应一并保护。

3-2-1 需要真正独立的副本

经典规则是：包括生产数据在内共三份副本，两种介质，一份异地副本。还应检查共同故障原因。同一台 NAS 上两个目录并不是独立保护。第二个云账户只有在主管理员也无法修改其保留策略和数据时，才有帮助。

实用组合包括生产数据、用于快速恢复的本地备份，以及应对站点损毁的独立外部副本。离线或在一定时间内不可变的副本，进一步限制非预期修改。RAID 能承受部分硬盘故障，却不提供独立历史版本。

不可变保护存在产品特定限制。S3 Object Lock 在规定期间保护特定对象版本，但仍可以创建新版本。应测试保留机制，并与存储预算及恢复流程对齐。

文件、数据库和云服务需要不同方法

文档通常需要恢复某个过去版本，数据库则要求相关变更保持一致；任意时刻复制仍打开的文件，可能无法做到这一点。应用感知备份会与受支持的应用协调恢复点。应核实具体数据库支持，不要假定所有备份都具备应用一致性。

对于云服务，应盘点账户、权限、保留策略和导出能力。回收站和版本历史有帮助，但不自动等于独立备份。确认账户丢失或历史到期后，所需数据是否仍可取得。只有目标能够导入时，导出才有意义。

计算完整恢复路径的成本

计入许可证、数据增长、外部副本、恢复容量、监控和演练时间。供应商可能对取回、最低保留期或传输收费。如果每天有大量新数据，延长保留期不会降低成本。应用真实数据衡量去重与压缩效果，而不是假设固定折扣。

以下带宽计算仅作示例：使用十进制单位、忽略协议开销，并假设 100 Mbit/s 连接始终完全可用，传输 1 TB 约需 22.2 小时。解包、启动数据库和验证还需要更久。若要四小时内恢复，就需要更快路径，或让副本预先靠近恢复环境。

方案应列明受保护系统与排除项、副本、保留期、目标、可联系人员、记录在案的访问方式，以及第一次成功恢复的计时结果。恢复单个项目和重启整个服务，应分别验收。

开展结果可验证的演练

选择完整但可控的流程，例如订单管理。在隔离测试环境中恢复指定时间点，验证登录、订单搜索、文档检索和无害的测试交易。防止真实通知或订单发往外部系统。开始前记录起始状态、依赖和预期结果。

测量范围不能只包括复制：应记录模拟事件开始、凭据可用、应用启动、业务检查完成及恢复数据的时间戳。将真实恢复时间与数据损失，对照 RTO 和 RPO。为每项偏差指定负责人和期限，而不是修改报告让结果看起来成功。数据库、加密或托管发生重大变化后，应重新测试。

告警必须引发实际行动

任务失败只是其中一个信号。缺少备份、数据集异常偏小、持续增长，以及恢复点超过约定时限，也同样重要。应对告警分类，并发送给能够在约定支持时段采取行动的人。

关键系统可以在最近确认的恢复点达到内部预警时龄时告警，从而在违背 RPO 之前，留出调查和核查其他副本的时间。应测试报告渠道，并确认替岗人员收到同样信息。

交接也是验收的一部分

即使故障服务器无法使用、某位人员不在场，恢复计划也必须能够访问。应记录联系人、产品与版本、依赖启动顺序，以及安全取得密钥和凭据的方法。密码应存入具备受控应急访问的适当管理器，而不是暴露在通用手册中。

第二个人应只依据文档完成范围明确的恢复，并记录知识缺口。演练频率应随变更速度与关键程度制定：每年一次有记录的复核可以作为起点，频繁变动的核心系统或未达到的目标则需要更密切检查。