RTO 与 RPO – 有什么区别？
只要您的生产系统和基本功能运行良好，您的部门就是成功的。 但是，在给定的时间点，您的运营发生了不可接受的中断，这构成了重大威胁。 通常，在很少或没有警告的情况下，灾难确实会出乎意料地发生。 这促使您进行风险计算并确定恢复优先级，这是两者的基本要素 业务连续性 和 灾难恢复 (DR) 规划过程。如果发生重大中断，您的系统需要恢复，您不能忽视它。 在潜在中断期间反映贵公司数据丢失容忍度的两个关键决策是 恢复时间目标 (RTO) 和 恢复点目标 (RPO). RPO 与 RTO 的目标必须与业务连续性保持一致。 这些参数是必不可少的业务指标，在确定调度备份运行的频率方面起着关键作用。
虽然 RPO 和 RTO 的含义是相关的，但公司的这两个组成部分 灾难恢复计划 和业务连续性战略在核心目标、目的、数据优先级和使用方面有所不同。 在灾难事件期间，每一分钟的停机时间都可能导致数以千计的收入损失，并逐渐削弱客户对您业务的信心。 今后，要构建可靠的灾难恢复 RTO 与 RPO 策略，了解什么是 RTO、RPO 及其区别至关重要。 使用 RTO 和 RPO 值，您可以开发一个可靠的 灾难恢复 和 业务连续性计划 概述了您的企业应整合到位的风险、恢复需求和备份解决方案。
RTO 解释
组织在灾难发生后恢复其应用程序和流程所需的目标时间称为恢复时间目标 (RTO)。 恢复时间表是确定企业停机时间容忍度的关键参数。 RTO 回答了这样一个问题：“应用程序在灾难发生后多久可以停机才能重新启动并运行，而不会造成重大的业务损失和客户的愤怒”。 此关键指标可以帮助您计算恢复和可接受的数据丢失之间的持续时间。然而，RTO 目标不仅仅是确定灾难发生和恢复之间的持续时间。 它还解释了定义 IT 团队为恢复其应用程序和数据而应采取的恢复步骤。 如果 IT 已投资故障转移服务来恢复高优先级应用程序，您只需几秒钟即可实现 RTO。
要根据业务应用程序的优先级计算 RTO，使 RTO 尽可能准确至关重要。
- RTO 接近于零：需要为关键任务应用程序提供故障转移服务
- 4 小时的 RTO：从裸机恢复的本地恢复，以完整的应用程序和数据可用性结束
- 8 小时以上的 RTO：对于可以停机数天而不会对业务造成任何严重损害的非必要应用程序
- 如果可能的最短恢复时间为 2 小时，则无法满足 XNUMX 小时的 RTO。
- 在另一种情况下，如果您将 RTO 设置为 4 小时，并且在下午 12 点出现系统故障，那么服务器将在下午 4 点前修复并启动并运行，这意味着达到目标 RTO。
- 如果您的 RTO 设置为 2 周，则投资会低得多，因为您有足够的时间在中断发生后恢复数据。
RPO 解释
简而言之，恢复点目标 (RPO) 是企业可以承受的丢失并继续运行而不会对企业造成任何重大损害的数据量。 RPO 在停机期间以可接受的数据丢失容忍持续时间确保业务连续性。 定义贵公司“可接受”的时间量在您的业务连续性计划中极为重要。 RPO 越长，由于停机时间延长而丢失数据的可能性就越大。 RPO 试图回答这个问题：“企业可以承受多少数据丢失？” 换句话说，RPO 确定您必须恢复以恢复正常业务运营的数据的年龄。RPO 为确定您的 灾难恢复 (DR) 计划. 因此，评估数据的重要性以决定需要恢复哪些应用程序、流程或信息非常重要。 根据严重程度，您应该恢复数据。 由于 RPO 列在上次备份的指定时间范围和备份类型中，因此 RPO 完全取决于您的备份系统。 使用单个 RPO 的数据备份通常可以每小时、24 小时、12 到 8 到 4 小时或每 10 分钟自动执行一次。 这意味着对于 1 小时的 RPO，您可能会丢失一小时的数据，或者如果您可以丢失 24 小时的数据，那么您的 RPO 设置为 20 小时。
虽然通过故障转移/故障恢复策略保持接近零的 RPO 是可能的，但这是一项昂贵的工作。 根据关键任务应用程序的优先级，您可以安排 RPO 平衡您的预算：
- 接近零的 RPO：使用连续数据保护 (CDP) 或复制（关键任务数据）
- 4 小时的 RPO：使用 近乎连续的数据保护 (CDP) 使用计划的快照复制
- 8-24 小时的 RPO：使用现有备份解决方案（可能从其他存储库备份的数据）
- 如果系统在下午 2 点中断，系统会在上午 11 点自动执行备份，则信息会以可用格式保存在最近的备份中。 RPO 应该是上午 11 点，这意味着企业可以在不中断业务连续性的情况下丢失 2 小时的数据。
- 同样，如果您的 RPO 是 6 小时，考虑到每 6 小时可能会造成数据丢失的风险，您必须每 24 小时执行一次备份。 但是，如果您每 1 小时安排一次备份，则可能会花费很多。
RTO 和 RPO 区别的要点
实际上，深入了解恢复时间目标与恢复点目标可以缩小知识差距，并帮助您按预算、资源，当然还有应用程序优先级来设定目标。 看一看。- RTO 从中断开始测量，而您可以在服务中断后测量 RPO。
- RTO 确定未来恢复要备份和运行的应用程序和进程的时间。 RPO 处理的是过去数据丢失前的时间，即数据保存到最近一次备份时，公司可以恢复数据恢复正常运营。
- RTO与数据丢失无关，主要处理灾后IT系统恢复的目标时间。 而 RPO 是可接受的业务停机时间，从中断到上次备份期间导致数据丢失。
- RTO 包括 IT 为减轻或从不同灾难中恢复而采取的步骤。 但是，RPO 决定了 IT 团队必须回溯到最后一个时间点，以及必须采取哪些措施才能将操作恢复到灾难前的状态。
- RTO 具有不同的恢复时间，这些时间依赖于多种因素，例如线性时间范围、事件发生日期等，这使得其计算更加复杂。 RPO 更容易计算和实施，因为数据使用在很大程度上是一致的，并且包含的变量更少。
- 由于 RTO 包括恢复整个基础设施，因此在满足接近零的 RTO 要求时恢复成本会急剧上升。 但是，由于可以更快地恢复孤立的信息，因此粒度接近零的 RPO 复制简化了恢复的成本和效率。 此外，与恢复整个基础架构不同，更长的 RPO 是可以承受的。
实现 RTO 和 RPO：Zmanda 的不同之处
保持运营高度可用和 24/7/365 可访问是每个商业梦想。 但是计算 RTO 和 RPO 要求可能涉及相当大的数据丢失风险和缓解成本。 此外，在较长的停机时间内，如果 RTO 和 RPO 目标不切实际，这可能会严重打击您的业务。 结果？ 失去声誉、客户信任和数百笔交易！ 因此，选择合适的恢复合作伙伴对于实现您的恢复目标至关重要。 这是您需要通过改进 RTO 和 RPO 指标来评估成本收益等式的地方 灾难恢复计划.Zmanda 全面的多合一云原生服务让一切尽在不言中 灾难恢复解决方案，它统一了备份、灾难恢复和安全网关访问支持解决方案，以跨地域和任意数量的工作负载扩展备份。 Zmanda 的本机代码架构可以帮助您即时恢复关键任务应用程序和数据以及多种类型的备份存储，同时将恢复时间降至最低。 此外，该 亚马逊冰川存储架构 还提供了更快的存储架构，可促进无缝混合备份。 此外，借助多层安全性，Zmanda 客户可以在恢复和备份期间获得增强的安全性，从而减少 数据管理 成本而不影响他们的业务。
想要更深入地了解我们如何帮助您确定实际的恢复目标并实现业务连续性？ 联系我们 欲了解更多信息或只是访问我们的 容灾解决方案 页面上发布服务提醒。
免费试用Zmanda 4.0 试用申请RTO 与 RPO – 有什么区别？
只要您的业务应用程序和系统正常运行，您的部门就会取得成功。 但是，在特定时间点，如果发生不可接受的中断，则可能构成重大威胁。 通常，在很少或没有警告的情况下，灾难确实会出乎意料地发生。 这促使您进行风险计算并确定恢复优先级，这是 业务连续性 和 灾难恢复 (DR) 规划过程。
在中断期间，您的系统必须立即恢复，而不会造成任何重大业务损失。 恢复时间目标 (RTO) 和 恢复点目标 (RPO) 是两个关键参数，您可以通过它们来估算您的企业可以承受的数据丢失量。 您必须调整 RPO 与 RTO 目标，以在节省业务的时间范围内恢复关键任务应用程序。 如果恢复值不切实际，则实现 DR 目标的风险和费用可能会对您的业务造成影响。 因此，RTO 和 RPO 是关键的业务指标，从长远来看，它们在确定业务连续性和灾难恢复方面发挥着关键作用。
现在的问题是：RTO 和 RPO 目标是否相关？
您可能认为 RPO 和 RTO 指标是相关的。 但是这两个组成部分 灾难恢复计划 它们的核心目标、目的、数据优先级和用途各不相同。 在灾难事件期间，每一分钟的停机时间都可能导致数以千计的收入损失。 在最坏的情况下，它会降低客户对您业务的信心。 今后，要构建可靠的 RTO 与 RPO 策略，了解什么是 RTO、RPO 以及它们的主要区别至关重要。 如果您正确设置 RTO 和 RPO 值，您可以开发一个可靠的 灾难恢复 和 业务连续性计划 概述风险，满足恢复需求，并提供备份解决方案以随时恢复数据。
什么是RTO？
恢复时间目标 (RTO) 是您的组织在灾难发生后恢复其应用程序和流程所需的目标时间。 恢复时间表是确定企业停机时间容忍度的关键参数。
RTO 回答了以下问题：“灾难事件后应用程序可以关闭多长时间？ RTO 还回答了在不造成重大业务损失的情况下启动和运行需要多长时间。 使用此关键指标，您可以计算恢复和可接受的业务数据丢失之间的持续时间。
但是，RTO 目标不仅仅是确定灾难发生和恢复之间的持续时间。 您还需要定义 IT 团队为恢复其应用程序和数据而应采取的恢复步骤。 如果 IT 已投资故障转移服务来恢复高优先级应用程序，您只需几秒钟即可实现 RTO。 如果您将 RTO 时间范围设置为 2 小时，您必须在 2 小时内将业务运营恢复正常，以防发生灾难事件。
如何计算 RTO
要准确设置 RTO 目标，您必须首先定义基于三层 DR 模型的高优先级业务应用程序：
| 1级 | 关键任务应用程序接近零 | 为了实现接近零的 RTO，应用程序必须切换到故障转移功能。 |
| 2级 | 需要 4 小时 RTO 的关键业务应用程序 | 要实现 4 小时 RTO，您必须至少每 4 小时执行一次本地恢复。 这将确保您的业务的数据可用性。 |
| 3级 | 需要 8 小时 RTO 的非关键应用 | 要实现 8 小时以上的 RTO，您可以使用现有的备份解决方案来恢复非必要的应用程序。 |
如何使用 RTO 的示例：
让我们举一个银行系统在灾难事件期间的业务连续性场景的例子：
- 鉴于 1 小时的停机时间可能是灾难性的，如果最短恢复时间为 2 小时，则您无法满足 XNUMX 小时的 RTO。 因为，RTO 旨在在中断一小时内恢复一切。
- 如果您将 RTO 设置为 4 小时，并且在下午 12 点出现系统故障。 您必须在下午 4 点之前恢复服务器数据以满足 RTO 目标。
- 对于设置为 2 周的 RTO，您对灾难恢复的投资将大大降低。 这是因为您有足够的时间在中断发生后恢复数据。
现在您知道如何为您的业务应用程序规划 RTO 目标，让我们了解什么是 RPO。
什么是 RPO？
恢复点目标 (RPO) 是您的企业在不造成任何重大损失的情况下可以承受的最大数据丢失量。 您必须在业务连续性计划中定义贵公司“可接受”的时间量。 RPO 越长，由于停机时间延长而丢失的数据就越多。 RPO 试图回答这个问题：“企业可以承受多少数据丢失？” 换句话说，RPO 确定您必须恢复以恢复业务运营恢复正常的数据的年龄。
为什么要关心 RPO？
RPO 为确定 灾难恢复 (DR) 计划. 第一步是定义确定备份频率的 RPO 时间范围。 这个想法是为了确保在灾难发生之前总是有可用的备份。 但是，您必须评估需要恢复的数据的价值。 您需要根据数据关键程度设置持续备份的 RPO。 很明显，企业在停机期间会丢失数据。 但是，通过定义 RPO 时间范围，您可以将数据备份的频率设置为丢失的数据量是相当可容忍的。
您还可以使用各个 RPO 自动执行数据备份。 这意味着，您可以每小时、24 小时、12 小时、8 到 4 小时或每 10 分钟设置一次 RPO。 因此，对于 1 小时的 RPO，企业可能会丢失一小时的数据。 同样，如果您可以丢失 24 小时的数据，您可以将 RPO 设置为 20 小时。
尽管通过故障转移/故障恢复策略可以保持接近零的 RPO，但这是一项昂贵的工作。
如何计算 RPO
对于高优先级应用程序，确定组织可以承受丢失多少数据很重要。
如何使用 RPO 的示例：
- 假设您的企业在下午 2 点遇到系统中断，系统在上午 11 点执行备份。 由于您已将信息保存在最近的备份中，因此 RPO 应为上午 11 点。 在这里，企业可以承受损失 2 小时的数据，而不会中断业务连续性。
- 同样，如果 RPO 为 6 小时，则必须每 6 小时执行一次备份。 这是因为每 24 小时可能会造成数据丢失的风险。 但是，如果您每 1 小时安排一次备份，则可能会花费很多。
RTO 和 RPO 之间的差异
深入了解恢复时间目标与恢复点目标可以帮助您实现恢复目标。 快速浏览一下 RTO 和 RPO 之间的关键差异点。
- 使用 RTO，您可以测量业务应用程序在停机期间可能停机的时间。 而 RPO 衡量的是停机期间可接受的数据丢失的可变数量。
- 您可以通过获取中断的起点来衡量 RTO。 但是，要衡量 RPO，您必须及时进行衡量，以确定企业可以容忍的上次创建的备份造成的数据丢失。
- RTO 包括 IT 必须采取的步骤，以减少停机时间并使应用程序恢复运行。 RPO 确定 IT 愿意通过从上次备份恢复来恢复数据的时间。
- 在计算 RTO 时，由于需要考虑几个因素，RTO 的恢复时间会有所不同。 例如，线性时间范围、灾难事件发生的日期等进一步使其计算复杂化。 当您采用最后的数据使用情况和备份变量时，RPO 更容易计算和实施。
- 由于 RTO 包括恢复整个基础设施，因此在满足接近零的 RTO 要求时恢复成本会急剧上升。 但是，通过粒度接近零的 RPO 复制，您可以连续复制数据以实现接近零的数据丢失。 这将简化成本并为需要高可用性的应用程序执行更快的恢复。 此外，与恢复整个基础设施不同，更长的 RPO 是可以负担的。
实现 RTO 和 RPO：Zmanda 的不同之处
保持业务运营 24/7/365 在线是每个企业的梦想。 但恢复时间和目标点 (RTPO) 并非一刀切。 在停机期间，如果 RTO 和 RPO 目标不切实际，这可能会严重打击您的业务。 结果？ 失去声誉、客户信任和数百笔交易！ 因此，选择合适的恢复合作伙伴对于实现您的恢复目标至关重要。 这是您需要通过改进 RTO 和 RPO 指标来评估成本收益等式的地方 灾难恢复计划.
包起来
因此，您已经根据应用程序优先级建立了 RTO 和 RPO 目标。 伟大的！ 现在，是时候采用正确的灾难恢复策略来满足 RTO 和 RPO 目标了。 别再看了。 Zmanda 的一体化云原生灾难恢复解决方案统一了备份、灾难恢复和安全网关访问，可以跨任意数量的工作负载扩展您的备份。 借助 Zmanda 的本机代码架构，您可以涵盖所有可能的故障场景，即使在重大中断期间，也可以为工作负载实现近乎实时的 RPO。
兹曼达的支持 亚马逊冰川存储 可以大幅降低您的存储成本，同时为您的所有关键数据提供无缝数据备份。 此外，借助多层安全性，您可以期待增强的数据安全性，同时减少 数据管理 成本而不影响您的业务底线。
想要更深入地了解我们如何帮助您实现 RTO 和 RPO 目标并实现业务连续性？ 联系我们 欲了解更多信息或只是访问我们的 容灾解决方案 页面上发布服务提醒。
