MySQL的备份恢复是一直想要改进的地方，其中恢复是重中之重，这部分的工作要做成平台化的工作，算是有了前期的很多铺垫和延迟，最近在和同事的共同协作下，总算有了一些眉目出来。

首先备份恢复是两类工作，如果一个相对来说完整的备份，从规划来说，是分为三层：全量备份，增量备份和binlog备份，恢复同理也是三类，即全量恢复，增量恢复和binlog恢复。

关于备份的选型，如果选择了逻辑备份，那么增量备份就是难点，但是恢复的灵活性会很便捷高效，如果选择了物理备份的方式，那么增量备份就很自然了，对于表级别的恢复来说，代价相对较高。

备份的工作，总体来说，看板还是hi需要的，零零散散收集了一些需求，最后对Redis的备份做了下面的看板，MySQL的备份看板略有差别，看板指标是类似的。

来进入平台自动化的设计中，首先从架构设计上，我是把这个阶段做了拆分，前后端分离的方式，后端的逻辑完全通过API的方式来交互，views层只做简单的逻辑和数据映射。

在API的设计上，通用是使用了Token的安全认证，而在效率上，本地调用了改造成了免token的反复调用。

在接口调用中，使用了ansible_adhoc来实现，脚本化的工作则相对来说会更加灵活，shell还是python怎么合适怎么来，只要脚本符合基本的标准，标准是什么，参数的描述，要有明确的输出。

在产品的设计中，我是通过CMDB提供的元数据来作为备份或者恢复的入口。为了保证功能的快速迭代和最低粒度，目前只保证单个实例的备份可行，如果有多个备份并行的情况，是优先考虑异步的，这里的优选方式是celery.

当然从任务调度从一个更高的角度来说，可以拆分为任务和调度两个模块，设置是两个独立的系统，任务系统和调度系统。比如备份就是一个任务。

前端的设计会分为6个主要的页面，备份/恢复各有一个入口页面，通过这个页面能够跳转到全量或者是增量备份，备份恢复个有两个页面。

先来说备份，备份的入口页面是这样的。可以选择自己的需求来过滤。

如果是全量备份，则会收集到概要信息和MySQL实例的明细信息，当然还有一个更直接的按钮，开启备份任务。

上面的是一个tab页面，如果按照目前的方式，可以查看到近7天的备份情况，所以我们要做全备，全量恢复，增量恢复，这些基本信息都是需要的。

增量的备份目前是使用binlog的方式来处理，后续继续完善xtracbackup的功能，满足一定频率的增量备份，来大幅度降低手工运维带来的痛苦。

全量恢复的入库哦页面如下：

如果选择了全量恢复，即异机恢复的场景，我们只需要输入两个参数，一个是备机的IP信息，另外一个是选择备份的日期。

如果是增量备份，则稍微复杂些。里面的亮点在于如果要恢复某一个库，指定了备机的IP，然后会得到binlog层面的反馈，能够把数据恢复到秒级。当然改进之处一个是基于偏移量的恢复，一个是基于时间范围。

如果把整个过程要贯穿起来，也是一个不断摸索的状态，代码不够优美，逻辑不够清晰，数据存在诸多问题，要从这些基于目前的情况来看，只能说解决了一些现实的问题。