在恢复数据的这段时间内，服务是不可用的，所以RTO也是服务可允许的最大不可用时间。如果我们要求服务的最大不可用时间是30分钟，那么RTO就是30分钟。
RTO 越小，代表容灾系统的恢复能力越强。
RPO：Recovery Point Objective，数据恢复点目标。
指的是灾难发生后，数据可以恢复到的时间点。
譬如，我有一个系统，每天0点进行一次全备。当系统出现故障后，会基于上一次的备份来恢复。如果系统在凌晨3点出现故障，我们会丢失3个小时的数据。极端情况下，系统在23:59出现故障，我们会丢失24个小时的数据。这里的24小时就是这个系统的RPO 。
RPO越小，代表系统越能保证数据的完整性。
RTO、RPO与灾难在时间轴上的关系如下图所示：
可以看到，RPO针对的是数据丢失，RTO针对的是服务宕机时间，两者之间没有必然的联系。
最理想的情况是RTO和RPO都为0，这就意味着当灾难发生时，系统会立即恢复，而且数据不会丢失。当然，RTO、RPO越小，需要投入的成本也越高。
具体到MySQL中，为了降低RTO和RPO，我们可以从以下几个方面着手：
RTO
增加备份频率，缩短备份周期。
选择物理备份，而不是逻辑备份。
添加延迟从库。
恢复流程的自动化。
RPO
增加备份频率，缩短备份周期。
搭建Binlog Server备份Binlog。当出现故障时，我们可以基于备份和Binlog做基于时间点的恢复。
添加延迟从库。
总结从RTO的角度出发，应尽量选择物理备份，而不是逻辑备份。如果要使用逻辑备份，应尽量选择多线程备份工具和多线程恢复工具。
从RPO的角度出发，应尽量增加备份频率，缩短备份周期。
但 every coin has two sides，使用物理备份或者增加备份频率，无疑会增加存储成本。
所以，在确定备份策略和选择备份工具时，应从业务的RTO和RPO出发，结合存储成本综合考虑。
大多数公司会采取一个统一的备份策略，如一天一个全备。虽然灾难情况很少出现，开发和DBA童鞋也应充分理解到这里面的风险，并制定相应的预案及业务兜底方案。