RTO和RPO （摘抄）
RTO（Recovery Time Object)恢复时间目标
恢复时间目标，指在故障或灾难发生之后，一台电脑、系统、网络或应用停止工作的最高可承受时间。该参数定义了最大可容忍时限，必须在此时限内恢复数据。如果说系统需要在灾难发生的12个小时内恢复，那么RTO数值就是12小时。RTO具体时间长短只是从故障发生后，从系统宕机导致业务中断的那一刻开始，到系统恢复至可以支持各业务正常运作之时，这两个节点之间的时间段。RTO是反映系统业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间，RTO数值越小，代表容灾系统的数据恢复能力越强。RTO=0就意味着在任何情况下都不允许目标业务有任何运营停顿。
RPO（Recovery Point Object)恢复点目标
恢复点目标，指一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到的时间点，是业务系统所能容忍的数据丢失量。例如每天00：00进行数据备份，那么如果今天发生了宕机事件，数据可以恢复到的时间点（RPO）就是今天的00：00，如果凌晨3点发生灾难或宕机事件，损失的数据就是三个小时，如果23：59发生灾难，那么损失的数据就是约24小时，所以该用户的RPO就是24小时，即用户最大的数据损失量是24小时。所以RPO指的是用户允许损失的最大数据量。这和数据备份的频率有关，为了改进RPO，必然要增加数据备份的频率才行。RPO指标主要反映了业务连续性管理体系下备用数据的有效性，即RPO取值越小，表示系统对数据完整性的保证能力越强。
RTO和RPO指标并不是孤立的，而是从不同角度来反映数据中心的容灾能力。
RTO和RPO
概述：恢复时间目标(RTO)和恢复点目标(RPO)，故障后需要RTO恢复业务到正常状态。丢失数据到最近一次数据备份对应的时间则是RPO。
在理想的情况下，企业的数据保护基础设施可以立即在故障点时间恢复所有的应用程序和数据。以下讨论一下它们定义，它们的异同，及为什么需要分析应用程序的优先级来平衡资源和应用程序的可用性。
(1)RTO：恢复时间目标
RTO指的是可以中断或关闭多少时间而不会对业务造成重大损害。有些业务可能会停机数天而不会产生严重的后果。而一些高优先级的业务只能停下来几秒钟，就会导致巨大损失。
RTO不仅仅是业务损失和恢复之间的持续时间。这个目标还包括IT部门必须采取的步骤来恢复应用程序及其数据。如果IT已经投入高优先级应用程序的故障转移服务，那么它们可以在几秒钟内安全地表达RTO(IT部门必须恢复本地环境，但由于应用程序正在云中进行处理，因此IT部门可能需要一些时间)。
企业的RTO任务是根据优先级和潜在业务损失对应用程序进行分类，并相应地匹配企业的资源。例如，接近零的RTO的典型计划将需要故障转移服务。4小时RTO允许从裸机恢复开始进行本地恢复，并以完整的应用程序和数据可用性结束。对于8小时以上的RTO，IT团队可以与本地系统集成商签署维护合同。
(2)RPO：恢复点目标
恢复点目标是指企业的损失容限：在对业务造成重大损害之前可能丢失的数据量。该目标表示为从丢失事件到最近一次在前备份的时间度量。
如果以定期计划的24小时增量备份全部或大部分数据，那么在最坏的情况下，企业将丢失24小时的数据。对于某些应用来说，这是可以接受的，对于其他人来说并不是这样。
例如，如果企业的应用程序具有4小时RPO，那么备份和数据丢失之间的间隔时间将为4小时。拥有4小时的RPO并不一定意味着企业将失去4小时的数据。例如一个文字处理应用程序在午夜停止运行并在凌晨出现故障，那么可能没有丢失太多(或任何)数据。但是如果一个任务繁忙的应用程序在上午10点关闭并且直到下午2点才恢复，那么企业可能会失去4个小时的高价值并且可能无法替代的数据。在这种情况下，需要进行更加频繁的备份，以便访问特定于应用程序的RPO。
这取决于应用优先级，单个RPO的范围通常为24小时、12小时、8小时、4小时。以秒为单位测量到接近零。只要对生产系统的影响最小，8小时以上的RPO就可以利用现有的备份解决方案。4小时的RPO将需要计划的快照复制，而接近零的RPO将需要连续复制。在RPO和RTO都接近于零的情况下，将连续复制与故障转移服务结合使用，以实现接近100%的应用程序和数据可用性。
RTO和RPO如何相似以及不同的原因
(1)RTO和RPO的几个特征
恢复时间和恢复点目标因应用程序和数据优先级而异。即使是大公司也不能为所有应用程序提供接近零的RTO或RPO，也不应该这样做。
确保100%正常运行时间(RTO)和没有丢失数据(RPO)的唯一方法是投资连续数据复制功能的故障转移虚拟环境。
IT优先处理应用程序和数据以匹配所实现的RTO和RPO的费用。请注意，优先事项不仅取决于收入，还取决于风险。企业可能不经常使用应用程序，但如果其数据受到管制，那么数据丢失可能会导致巨额罚款。
RTO和RPO均以时间为单位进行测量。对于RTO来说，其度量标准是应用程序失败和包括数据恢复在内的完整可用性之间的时间量。RPO也以时间单位来衡量。度量标准是数据丢失和前一次备份之间的时间间隔。对于RTO和RPO来说，其应用程序/数据优先级可直接转换为更短的时间单位。
(2)RTO和RPO的目标存在巨大的差异
尽管它们有相似之处，但RPO和RTO服务于不同的目标。RTO涉及应用程序和系统，但主要描述应用程序停机时间的限制。
RPO主要与失败事件后丢失的数据量有关。但是，损失数十万美元的客户交易将是灾难性的后果。
RTO和RPO在行动中的实例
单一文件恢复：例如一家公司员工意外删除一个时间敏感的电子邮件，然后清空回收站和文件夹的内容。由于Microsoft Exchange是这家公司的业务关键型应用程序，因此IT部门不断支持Exchange中的增量更改。而且由于他们的备份应用程序能够进行精细的备份和恢复，他们可以在5分钟的RTO内恢复单个文件，而不用为单个文件恢复整个虚拟机。
电子商务网站：例如，一家零售商店的自营电子商务网站使用三种不同的数据库：存储产品目录的关系数据库，报告历史订单数据的文档数据库，以及连接到其支付处理器网关的API数据库。文件数据库可以重建来自其他数据库的数据，因此其RTO和RPO是在24小时内。该业务每周只向关系数据库添加一次产品，因此RPO并不重要。其RTO是如果数据库关闭，则客户交易停止。
为了保持高可用性，这家商店采用了故障转移服务，因此数据库立即在虚拟服务器上运行。该公司将其在一周内进行的少量更改复制到其提供商的灾难恢复平台。API数据库包含订购信息，并且需要几秒钟才能完成RPO和RTO。 IT部门不断地将数据复制到故障转移站点，如果API数据库停机，该站点将立即接管处理。
以上内容来自网络，如有侵权，请留言以便删除。
