RTO 和 RPO 都是企业灾难恢复（Disaster Recovery, DR）需要考虑的关键指标，这两个指标可以用来指导企业来制定合适的业务系统服务或数据的恢复方案。
RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。
如果以定期计划的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（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期，此两点之间的时间段称为RTO。
RTO不仅仅是业务损失和恢复之间的持续时间。这个目标还包括IT部门必须采取的步骤来恢复应用程序及其数据。如果IT已经投入高优先级应用程序的故障转移服务，那么它们可以在几秒钟内安全地表达RTO(IT部门必须恢复本地环境，但由于应用程序正在云中进行处理，因此IT部门可能需要一些时间)。
企业的RTO任务是根据优先级和潜在业务损失对应用程序进行分类，并相应地匹配企业的资源。
例如，接近零的RTO的典型计划将需要故障转移服务。4小时RTO允许从裸机恢复开始进行本地恢复，并以完整的应用程序和数据可用性结束。对于8小时以上的RTO，IT团队可以与本地系统集成商签署维护合同。
1.相同点与不同点
RTO 和 RPO 都是使用时间来度量。
- 对于 RTO 时间，是指灾难发生到服务恢复的时间，这个时间也包含了数据恢复的时间。
- 对于 RPO 时间，是指灾难发生到数据上一次备份的时间。
虽然 RTO 和 RPO 都使用时间来度量，但是使用它们的目的却不相同。
- RTO 关注于应用或系统的可用性，RTO 虽然包含数据恢复的时间，但更多地是描述应用停机的时间限制。
- RPO 关注于数据的完整性，描述所能容忍的最大数据丢失限制。业务系统服务不可用会带来经济损失，但如果丢失的是客户交易数据则导致的损失更是灾难性的。
2.备份策略
在制定企业的容灾计划时，需要考虑 RTO 和 RPO 目标，然而 RTO 和 RPO 目标的成本存在差异。维护一个高要求的 RTO 目标的成本可能比 RPO 目标的成本要高，这是因为 RTO 涉及到整个业务基础架构，而不仅仅是数据。
要实现 RPO 目标，只需要以正确的时间间隔执行数据备份，数据备份可以很容易地自动化实现，因此自动化的 RPO 策略很容易实现。
另一方面，由于 RTO 涉及恢复所有 IT 操作，因此完全自动化的 RTO 策略实现更复杂。
RTO 和 RPO 对于制定容灾计划时都很重要，各个企业业务场景不同，这需要我们根据实际情况来选择合适的 RTO 和 RPO 目标，以达到经济效益的最大化。
3.备份场景实例
1.单一文件恢复：
例如，一家公司员工意外删除一个时间敏感的电子邮件，然后清空回收站和文件夹的内容。
由于Microsoft Exchange是这家公司的业务关键型应用程序，因此IT部门不断支持Exchange中的增量更改。而且由于他们的备份应用程序能够进行精细的备份和恢复，他们可以在5分钟的RTO内恢复单个文件，而不用为单个文件恢复整个虚拟机。
2.电子商务网站：
例如，一家零售商店的自营电子商务网站使用三种不同的数据库：
- 存储产品目录的关系数据库
- 报告历史订单数据的文档数据库
- 以及连接到其支付处理器网关的API数据库
文件数据库可以重建来自其他数据库的数据，因此其RTO和RPO是在24小时内。
该业务每周只向关系数据库添加一次产品，因此RPO并不重要。 其RTO是如果数据库关闭，则客户交易停止。
为了保持高可用性，这家商店采用了故障转移服务，因此数据库立即在虚拟服务器上运行。该公司将其在一周内进行的少量更改复制到其提供商的灾难恢复平台。API数据库包含订购信息，并且需要几秒钟才能完成RPO和RTO。 IT部门不断地将数据复制到故障转移站点，如果API数据库停机，该站点将立即接管处理。