这是学习笔记的第 1801篇文章
对于MySQL方向的备份恢复设计，其实是作为数据保障工作最基础的事情了，备份的重要性就不需要反复强调了。对于数据备份的必要性我在团队内的一个要求就是，如果没有从库，不需要备份，基本可以判定这个业务可以下线了。
所以在这个基准之内，备份是要有的，包括测试环境，哪怕备份粒度比较粗都可以。
对于备份恢复的全景设计，之前做了第一期的功能接入，基本能够实现MySQL备份恢复的平台化操作，但是离实际的应用和实践还存在一定的距离，也就意味着和生产实践要真正结合起来，我们还需要在细节上不断的改进，保障数据备份的有效性的前提下来补充。
整体来说，备份对标是恢复服务，对于备份恢复的整体目标来说，需要对应的是备份恢复的服务。
在这个地方我分为了两个层面，一个是基于备份集的数据备份恢复服务，另外一个是基于binlog的数据备份恢复服务。整体划分下来，分别有六类和四类，盘点下来，目前来看需要十类数据备份恢复相关的服务。
整个备份恢复的方案设计是分层来做的，首先为了减轻主库的压力，备份工作建议是在从库进行，在主从间需要控制好主从延迟等情况。
备份任务方向上需要考虑深入接入调度，能够完成两个维度的调度任务，一个是基于业务维度的并发调度，一个是基于时间维度的调度。
对于备份的部分，根据备份结果集的类型不同分为了数据备份服务器和日志备份服务器，也是考虑了备份机的可用性。
在备份的设置中，可以根据数量和业务优先级来设定不同的备份策略，比如测试环境可以设定备份策略为全库备份，备份频率为一天到三天。
对于线上优先级较高的业务需要考虑全库备份和增量备份，日志备份的粒度也要更细一些。
