备份是否完整，能否满足要求，关键还是要看所设计的备份策略是否合理，以及备份操作是否确实按照所设计的备份策略来进行的了。针对不同的用途，所需要的备份类型是不一样的，备份策略也各有不同。如为了应对在线应用的数据丢失问题，备份就需要快速回复，而热情最好是只需要增量回复就能找回所需数据。对于这类需求，最好是有在线的，且部分延迟回复的备用数据库。因为这样可以在最短时间内找回所需要的数据。甚至在某些硬件设备出现故障的时候，将备用库直接开放，对外提供服务都可以。当然，在资源缺乏的情况下，可能难以找到足够的备用硬件设备来

    备份是否完整，能否满足要求，关键还是要看所设计的备份策略是否合理，以及备份操作是否确实按照所设计的备份策略来进行的了。

    针对不同的用途，所需要的备份类型是不一样的，备份策略也各有不同。如为了应对在线应用的数据丢失问题，备份就需要快速回复，而热情最好是只需要增量回复就能找回所需数据。对于这类需求，最好是有在线的，且部分延迟回复的备用数据库。因为这样可以在最短时间内找回所需要的数据。甚至在某些硬件设备出现故障的时候，将备用库直接开放，对外提供服务都可以。当然，在资源缺乏的情况下，可能难以找到足够的备用硬件设备来承担这个备份责任，也可以通过物理备份来解决，毕竟物理备份的恢复速度要比逻辑备份快很多。

    而对于那些非数据丢失的应用场景，大多数时候恢复时间的要求并不是太高，只要能恢复出一个完整可用的数据库就可以了。所以不论是物理备份还是逻辑备份，影响都不是特别大。

    从我的个人经验来看，可以根据不同的需求、不同的级别通过如下的几个思路来设计合理的备份策略：

    1）对于较为核心的在线应用系统，必须有在线备用主机通过 MySQL的复制进行相应的备份，复制线程可以一直开启，恢复线程可以每天恢复一次，尽量让备机的数据延后主机的时间在一定时间段之内。这个延后时间多长合适主要根据实际需求决定，一般来说延后一天是一个比较常规的做法。

    2）对于重要级别稍微低一些的应用，恢复时间要求不是太高的话，为了节约硬件成本，不必使用在线的备份主机来单独运行备用 MySQL，可以通过一定的时间周期进行一次物理全备份，同时每小时（或者其他合适的时间段）都将产生的二进制日志进行备份。这样虽然没有第一种备份方法恢复快，但是数据的丢失会比较少。恢复所需要的时间由全备份周期长短决定。

    3）对于恢复基本没有太多时间要求，但是不希望太多数据丢失的应用场景，则可以在一定时间周期内进行一次逻辑全备份，同时也备份相应的二进制日志。使用逻辑备份而不使用物理备份的原因是因为逻辑备份实现简单，可以完全在线联机完成，备份过程不会影响应用提供服务。

    4）对于一些搭建临时数据库的备份应用场景，仅仅需要通过一个逻辑全备份即可满足需求，都不需要用二进制日志来进行恢复，因为这样的需求对数据并没有太苛刻的要求。

    上面的4种备份策略都还比较粗糙，甚至不能算是一个备份策略。目的只是希望能给大家一个指定备份策略的思路。读者可以根据这个思路根据实际的应用场景指定不同的备份策略。