恢复时间目标 (RTO) 是您的企业在不造成重大财务损失的情况下可以容忍的最大停机时间。RTO 与恢复点目标 (RPO) 一起使用，或者您的企业可以从中断造成的数据丢失中恢复的时间间隔。合理的 RTO 和 RPO 目标有助于在灾难后更平稳地恢复到正常状态，并且应该成为灾难恢复计划的一部分。
恢复时间目标 (RTO) 的定义
RTO 是灾难发生后恢复业务和 IT 基础设施所需的目标时间。例如，两小时的 RTO 意味着您给负责人员两个小时来重新恢复您的服务。数据恢复属于 RTO 的范畴。
设置 RTO 时，您应确保它反映您业务的性质和状态。例如，如果您的业务依赖于在线交易，那么停机时间过长可能会严重影响您的生存能力。因此，您的 RTO 应该足够短，以尽量减少影响。在这种情况下，一个好的 RTO 是在一两个小时（最多）内让您的操作恢复正常。
相比之下，能够负担得起使用纸质订单和人工开票运营一两天的组织，在极端情况下也能够承受 1 天或 2 天的 RTO，甚至一周的 RTO。
在某些情况下，由于自然灾害导致您的基础设施、您的服务提供商的基础设施和您周围的人的基础设施瘫痪，长时间停机可能是不可避免的。如果您的企业无法承受此类停机时间，您可能需要花费更多资金来让您的 IT 基础设施为这些类型的灾难做好准备。
一种选择是将您的 IT 服务外包给更有信誉的提供商。不要放弃尽职调查以确保您获得最有能力的供应商。与供应商协商以获得最好的条款，并确保支持可用性、响应时间和解决时间在您的服务级别协议中规定。
您还可以根据中断的严重程度设置不同的 RTO。例如，如果服务器崩溃，1 小时的 RTO 可能就足够了。在自然灾害等最坏情况下考虑更长的 RTO。
理想情况下，您的 RTO 不应超过最大时间点，在此时间点您的企业仍然可以承担收入和其他损失而不会产生实质性的运营影响。您可能需要缓解措施来避免 RTO 失败。测试这些过程应该是您的灾难恢复计划的一部分。
当灾难袭来时，您的 IT 团队在满足 RTO 方面的表现可能取决于您的恢复程序。如果您的团队计划和排练良好，RTO 可能会更短或等于实际恢复时间 (RTA)，或者您的团队从停机时间中恢复所需的实际时间。在这种情况下，祝贺您的团队出色地完成了工作。
恢复点目标 (RPO) 的定义
RPO 是您在不显着影响业务的情况下可以承受的丢失数据的最长时间。超过 RPO 的数据丢失可能对您的业务有害。例如，两小时的 RPO 意味着您应该每小时安排一次备份，以便在停机时恢复数据。定义 RPO 有助于避免在您的任何应用程序出现故障时丢失任何数据。
计算 RPO 时，请考虑您的组织可以接受的数据丢失。不同的应用程序可能具有不同的 RPO，具体取决于它们对您的运营的重要性。数据备份包含在 RPO 中。
与 RTO 一样，RPO 取决于您的业务性质。RPO 可能从接近零到 24 小时不等。接近零是出于监管目的需要维护数据完整性的大型企业的理想选择。较长的 RPO 可能是小型企业的理想选择，它们可以在不需要记录的情况下运营长达一天。其他组织可以使用介于这些极端之间的 RPO。
在灾难恢复计划中设置数据备份过程时，RPO 是一个重要的考虑因素。例如，如果您的企业在灾难来袭时无法承受丢失任何数据的后果，则可以包括用于数据备份和复制的云存储解决方案。在这种情况下，即使发生数据丢失，它也会保持在最低限度，因为故障转移策略会自动启动。
对于数据要求不太严格的组织，数据备份可以包括定期和持续的生产快照。对于那些最多可以存在一天而没有记录的情况，外部存储备份或传统磁带备份可能就足够了。
在任何情况下，较短的 RPO 都会导致使用更昂贵的数据备份选项。无缝故障转移和故障回复的成本高于生产快照和存储备份。
设置灾难恢复计划时，请确保您的 RPO 反映了您对数据丢失的容忍度。在规划灾难恢复时，应同时考虑 RTO 和 RPO。
数据恢复过程应该是灾难恢复演练的一部分。努力使实际恢复点 (RPA) 或恢复数据所需的实际时间短于或等于您的 RPO。如果 RPA 证明比你的 RPO 长，你可能需要修改你的灾难恢复计划。
RTO与RPO的异同
关于 RTO 和 RPO 的含义以及它们的组成可能有些混淆。让我们通过展示这两个概念之间的异同来澄清这一点。
首先，让我们讨论一下两者的相似之处。
- RTO 和 RPO 都处理时间。RTO 处理灾难后恢复业务和 IT 基础设施所需的时间，而 RPO 则关注恢复中断期间丢失的数据量所需的最长时间。
- RTO 和 RPO 失败都可能导致重大的收入损失。管理层必须与 IT 协调，平衡两者以将风险降至最低。
- OptimalRTO 和 RPO 分别需要 100% 的正常运行时间和零数据丢失。两者都只能通过高可用性解决方案来实现，例如包含连续数据复制的故障转移策略。
RTO和RPO也有区别。
- RTO 比 RPO 涵盖的范围更广。在灾难期间，RTO 会处理您的整个 IT 基础设施。另一方面，RPO 只处理数据。因此，RTO 可能比 RPO 更昂贵。
- RTO 更为复杂，因为它可以使用范围更广的手动和自动化技术来恢复整个 IT 基础架构。RPO 只需要定期自动备份数据。
如何计算 RTO 和 RPO
RTO 涉及您的应用程序和系统的整体。通常，RTO 会考虑 RPO，因为数据恢复是 RTO 的一部分。实现 RTO 的大部分成本可能用于 RPO。
计算 RTO 时考虑以下因素：
- 停电成本
- 系统重要性
- 恢复程序的复杂性
- 缓解成本
由于 RPO 只处理数据，因此比 RTO 更容易计算。如前所述，较短的 RPO 可能需要更多的时间和金钱。虽然更长的 RPO 可能更便宜，但您有丢失更多数据的风险。
计算 RPO 时，请考虑以下因素：
- 最大可容忍的数据丢失量
- 丢失数据给您的运营带来的成本
- 缓解成本
在计算 RTO 和 RPO 时，贵组织的 IT 人员、财务资源和声誉是其他考虑因素。必须对用户、应用程序和系统进行调查，目的是了解系统及其中驻留的数据的重要性。
调查结束后，计算停机成本及其对收入和其他财务的影响，然后运行灾难发生时发生的最坏情况。应不断评估灾难恢复计划的整体有效性。在此期间，您还应该审查您的 RTO 和 RPO 的有效性并进行相应的修改。
