RPO 描述你准备接受的数据丢失窗口；RTO 描述你力求控制在其中的中断时间。为有用的业务功能定义两者，然后在演练中证明恢复序列。仅凭备份计划或服务器规格无法确立任一目标。
从人们可以使用的服务开始
当恢复目标描述业务功能而非孤立机器时，它们才有用。服务器可以启动，但客户仍无法登录、检索文件或完成请求。用普通语言写下结束条件：授权用户可以访问应用程序，并且所需数据是一致的。这使目标可由基础设施团队之外的人测试。
询问应用程序负责人，中断会阻止什么，数据缺失会造成什么代价。每周出版物和事务处理应用程序可能有不同答案。将由此产生的目标视为规划目标，而不是根据硬件目录编造的承诺。记录谁批准了这些目标，以及计划涵盖哪些故障场景。
区分两个时钟
RPO 关注恢复的数据相对于中断可以回溯多远。RTO 关注功能可以保持不可用多长时间。较新的备份可以改善数据丢失窗口，但缓慢的恢复仍会错过恢复时间目标。反之，快速重启可以恢复对某个应用程序的访问，但其最新数据并未幸存。
明确参考点。确定事件时钟何时开始、什么算作已恢复运行，以及如何识别可用数据点。将目标与测量结果分开：目标是你要追求的结果；演练显示当前流程实现了什么。当应用程序或数据集发生变化时，重新审视任一者。
为恢复的每一步编制预算
实际的 RTO 预算包括检测、评估、授权、访问恢复环境、恢复、应用程序验证和重新开放。文件复制时间只是其中一个组成部分。如果持有恢复密钥的人不可用，理论上快速的备份仍可能无法使用。列出依赖项，并确保恢复团队在所考虑的故障期间能够联系到它们。
为每个步骤分配暂定时间，然后用观察结果替换估计值。在这个示例性的两小时预算中，恢复获得最大配额，但验证仍有受保护的时间。这些数字描述的是规划示例，而非 SwissOctet 服务交付。如果总时间没有余量，设计需要在目标可信之前改进。
| 恢复步骤 | 示例性配额 | 要收集的证据 |
|---|---|---|
| 检测和评估 | 15 分钟 | 警报到达和事件决策 |
| 准备恢复环境 | 20 分钟 | 访问和配置可用 |
| 恢复数据和服务 | 50 分钟 | 完成恢复且数据一致 |
| 验证并重新开放 | 25 分钟 | 用户旅程成功 |
| 应急余量 | 10 分钟 | 记录意外工作 |
检查真实的数据丢失窗口
每小时调度的作业不会自动实现一小时 RPO。作业失败、上传延迟或副本不可用，都可能使最新可恢复点比预期旧得多。观察成功完成情况以及实际可恢复的状态。对于有多个数据存储的应用程序，确认它们的恢复点相互兼容，而不是孤立地读取每个时间戳。
在演练期间选择一个参考事件，例如在已知时间创建的授权测试记录。恢复后，识别最新的有效记录并测量差距。使用无害测试数据。这会给出实际结果，并暴露仅显示作业成功的仪表板可能隐藏的假设。
在预算内选择策略
备份和恢复、预备的待机环境以及复制的应用程序设计，会在成本、复杂性与恢复速度之间权衡。复制可以减少某些延迟，但也可能复制意外删除或应用程序错误。已偏离工作配置的待机环境会带来自身风险。根据你记录的故障场景和目标选择策略。
考虑一个目标为四小时的小型服务，以及一个仅恢复在演练中就需六小时的较大数据集。购买更快的网络端口只是一个假设：存储读取、接收写入和应用程序恢复可能占主导。改进测量到的限制步骤、减少恢复集或更改策略，然后再次演练。
在不危及生产环境的情况下演练
使用隔离的恢复环境和定义的演练窗口。确保恢复的作业不能发送真实通知、接受公开付款或写入生产集成。在认为演练完成之前，测试访问、数据完整性和代表性用户旅程。让未编写原始程序的人参与，以暴露缺失的说明。
保留演练时间线、实现的恢复点以及因信息不可用造成的每次中断。有用的报告应说明测量结果、与目标的差距以及具体纠正措施。在发生有意义的变化后，以及按适合项目重要性的间隔重复。
在故障期间保持计划可用
将恢复程序存储在团队可以访问的位置，而不必仅依赖已失败的应用程序。将凭据和加密密钥保存在受保护位置，并采用经过测试的访问流程。随着项目发展，更新联系人、数据集大小和依赖项。过时的计划可能在恢复甚至开始之前就消耗掉时间余量。
比较 SwissOctet 配置时，将你的恢复架构与目录的可选备份选项分开。确认某个选项涵盖什么、恢复数据保存在哪里以及由谁执行恢复。目录并不确立应用程序 RPO 或 RTO。你测量到的流程和实际服务条款为该决策提供依据。
您的实用清单。
- 定义恢复后的业务功能。
- 批准单独的 RPO 和 RTO 目标。
- 为检测、访问、恢复和验证编制预算。
- 测量最新可用数据点。
- 在隔离环境中演练。
- 记录差距，并在相关变化后重复。
重要细节。
RTO 与正常运行时间相同吗？+
不同。RTO 是中断场景的恢复目标。正常运行时间衡量一段时间内的可用性；一个不能确立另一个。
每小时备份能保证一小时 RPO 吗？+
不能。检查已完成、可用的副本以及应用程序的一致性要求。作业失败和传输延迟可能扩大可恢复数据的差距。
每个项目都必须使用待机服务器吗？+
根据项目的恢复目标和测量到的恢复流程选择策略。待机增加成本和运营复杂性，并不自动必要。
前往来源。
这些参考资料支持本指南中的技术概念。在更改生产系统之前，请遵循当前文档。
- NIST SP 800-34 Rev. 1：应急规划指南 nvlpubs.nist.gov
- AWS Well-Architected：定义恢复目标 docs.aws.amazon.com
- Microsoft Learn：业务连续性、高可用性和灾难恢复 learn.microsoft.com
由 SwissOctet 提供编辑指导。示例仅作说明。服务规格、可用选项和合同条件必须单独核实。