验证(VERIFY) - 针对载入MySQL的数据执行健康检查(Sanity check)。
重播(REPLAY) - 如果有必要，在已还原备份的基础上，下载二进制日志备份并进行事务重播。我们会使用 mysqlbinlog 程序筛选掉来自其他共置数据库以及 空事务 的Binlog事件，随后对同一个MySQL实例重播所需的事务。
每个步骤有自己对应的失败状态，因此如果某个作业在 DOWNLOAD 步骤失败，将显示为 DOWNLOAD_FAILED 状态，并且不会继续进入到 LOAD 步骤中。
Binlog的选择逻辑
还原过程中最具挑战的部分可能就是确定所要下载并重播的Binlog。完整和差异备份可以从主或从属数据库获取，然而我们只从主数据库创建Binlog备份。这意味着简单的时间戳对比已经无法用于确定要重播的Binlog。
我们于 2014年 在所有服务器上部署了 GTID ，因此每笔事务都可以获得一个全局唯一标识符。此外每台运行MySQL的服务器也维持了一个 gtid_executed (GTID集)变量，可将其作为对应实例目前已执行事务数量的计数器。
在具备GTID的情况下，从主数据库重播至从属数据库的事务可以维持自己的GTID，这也意味着我们可以清楚地知道每笔事务是否包含在某个GTID集中。此外还可以针对服务器的 gtid_executed 值进行超集/子集(Superset/subset)比较，因为该值实际上就是一种严格递增的计数器和数学意义上的函数。
通过配合使用这些技术，即可在创建转储时记录服务器的 gtid_executed 值，同时记录每个Binlog文件中包含的GTID集，借此执行一致的比较并确定Binlog中的哪些事务需要重播。此外一旦需要重播的第一笔事务确定后，无需重新对比其他GTID即可确定需要重播的所有后续事务。我们还会使用 mysqlbinlog 的 --stop-datetime 选项确定Binlog流要在何处停止。
结论
面对灾难性事件，备份是最后一重保障，备份的存在使得我们具备了更自信的故障恢复能力。然而仅仅创建备份是不够的。ORC可以帮助我们对备份进行持续不断的测试，借此验证备份的完整性，并让我们更清楚地确定成功还原数据所需提供的资源。
以Facebook的规模，打造一个类似ORC这样的系统还需要具备大量警报、监控，以及自动化的失败检测和补救机制。这些功能均是通过CRT实现的，我们将通过另一篇文章介绍如何将这种还原过程扩展至成千上万个数据库。
作者： Divij Rajkumar ， 阅读英文原文 ： Continuous MySQL backup validation: Restoring backups