携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第29天，点击查看活动详情

恢复点目标

恢复点目标（RPO）描述了在发生破坏性事件（例如网络攻击、自然灾害或通信故障）后必须恢复企业运营的时间段。

它是灾难恢复计划的重要组成部分，通常与恢复时间目标（RTO）（在发生中断事件后恢复关键功能的最长时间）配合使用。数据恢复（RPO）和最长恢复时间（RTO）

企业的每个不同流程（包括通信网络和基础结构）都应具有唯一的 RPO，具体取决于其功能和重要性。在这里，我们将介绍如何根据您的法规遵从性需求和业务目标定义用于数据恢复的 RPO。

通常，RPO 是根据文件更新的频率设置的。这可确保在服务中断后，还原的操作包含最新版本的数据。

例如，经常更新的文件需要一个简短（不超过几分钟）的 RPO。这意味着在发生中断事件后，可以在最小的数据丢失的情况下恢复操作。

可能影响您的 RPO 的因素包括：

行业 – 处理高度动态或敏感信息（例如，健康记录或财务交易）的企业比处理静态文件的企业更新其文件的频率更高。
数据存储 – 数据的存储方式（例如，在物理设备、云等中）会影响服务中断后检索数据的速度。
合规性注意事项 – 许多合规性方案都包含处理灾难恢复和数据可用性的条款。例如，SOC 2 认证需要一定程度的数据可用性和处理完整性，这可能会影响服务中断后可能丢失的可接受的数据量。

定义后，RPO 应成为业务连续性计划]的基石，作为其详细流程的目标。

在您的计划中，应为各个业务部门设置不同的 RPO。例如，任务关键型数据流程（如财务交易）需要比更新频率较低的文件（如员工记录）更短的 RPO。

以下是在为业务部门设置所需 RPO 时可以使用的示例层：

0-1 小时

这些是关键操作，不能丢失超过一个小时的数据。业务和数据事务通常数量更高，动态性更强，由于涉及的变量数量众多，因此通常无法重新创建它们。

此层的示例包括银行交易、CRM 系统和患者记录。

1-4 小时

能够承受长达四小时的数据丢失的业务部门本质上是半关键的。示例包括客户聊天记录和文件服务器。

4-12 小时

属于此类别的业务部门不能容忍丢失超过 12 小时的信息。示例包括营销和销售数据。

13-24 小时

构成此类别的业务部门处理半重要数据，并要求 RPO 最长可追溯到 24 小时。这可以包括人力资源和采购部门，它们更新数据的频率低于企业的出站部门。

故障转移是在中断事件或计划内系统停机（例如，日常维护）期间在主系统和备份系统之间切换的过程。

选择故障转移解决方案时，请务必考虑组织的 RPO，以避免在切换到备份服务器时丢失不可接受的数据量。

例如，十分钟的 RPO 意味着故障转移解决方案必须在该时间范围内做出响应，以确保丢失的数据不超过十分钟。

故障转移方法包括：

DNS 服务 – DNS 服务将流量从硬件解决方案路由到异地数据中心。这对于跨数据中心恢复非常有用，以防整个数据中心出现故障。但是，此过程具有许多潜在的缺点，包括与TTL相关的延迟和服务降级，这可能会增加数据恢复时间。此外，路由过程可能会使故障转移不均匀，因为 ISP 可能会继续将流量路由到错误的服务器，直到其 DNS 缓存更新。
硬件解决方案 – 物理设备保留在现场。如果一个出现故障，流量会自动重新路由到备份服务器。此解决方案不存在与 DNS 故障转移关联的延迟问题。但是，它需要将备份站点托管在与源服务器相同的物理位置。这通常被认为是一种不好的做法，因为它会使备份站点暴露于许多可能影响主服务器群集的威胁（例如，本地电网故障或自然灾害）。
边缘服务 – 故障转移由第三方在异地管理，在发生中断事件期间可以无缝路由数据。边缘故障转移充分利用了 DNS 和基于硬件的解决方案 - 没有与维护物理设备相关的 TTL 相关延迟或额外成本。这可确保最小的数据丢失，从而使您能够保持 RPO 目标。