RTO：恢复时间目标
RTO是指应用程序可以关闭多少时间而不会对业务造成重大损害。某些应用程序可能会停机几天，而不会造成严重后果。某些高优先级的应用程序只能停机几秒钟，而不会引起员工的不满，客户的愤怒和业务的损失。
RTO不仅仅是损失和恢复之间的持续时间。该目标还说明了IT部门必须采取的还原应用程序及其数据的步骤。如果IT投资了用于高优先级应用程序的故障转移服务，那么他们可以在几秒钟内安全地表示RTO。 （IT部门仍必须还原本地环境。但是，由于应用程序是在云中处理的，因此IT部门可能会花一些时间。）
您的RTO任务是按优先级和潜在业务损失对应用程序进行分类，并相应地匹配您的资源。例如，接近零RTO的典型计划将需要故障转移服务。 4小时的RTO允许从裸机还原开始到本地还原，并从完整的应用程序和数据可用性结束。对于8小时以上的RTO，IT可以与本地系统集成商签订维护合同。
RPO：恢复点目标
恢复点目标是指公司的损失容忍度：在对业务造成重大损害之前可以丢失的数据量。该目标表示为从丢失事件到最近的先前备份的时间度量。
如果您以预定的24小时增量备份全部或大部分数据，那么在最坏的情况下，您将丢失价值24小时的数据。对于某些应用程序，这是可以接受的。对于其他人来说绝对不是。
例如，如果您的应用程序有一个4小时的RPO，则备份和数据丢失之间的最大间隔为4小时。拥有4小时的RPO并不一定意味着您会损失4小时的数据量。如果文字处理应用程序在午夜关闭并在上午1:15之前启动，则可能没有太多（或任何）数据丢失。但是，如果繁忙的应用程序在上午10点关闭，并且直到2:00 pm才恢复，那么您可能会丢失4个小时的有价值的，可能是不可替代的数据。在这种情况下，安排更频繁的备份，使您可以达到应用程序特定的RPO。
根据应用程序的优先级，各个RPO的范围通常为24小时至12小时，8至4小时；下降到接近零（以秒为单位）。只要对生产系统的影响降到最低，超过8小时的RPO便可以利用您现有的备份解决方案。 4小时的RPO将需要计划的快照复制，而接近零的RPO将需要连续复制。如果RPO和RTO都接近于零，则将连续复制与故障转移服务结合使用，以实现近100％的应用程序和数据可用性。