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層面的回報，能夠把資料恢複到秒級。當然改進之處一個是基于偏移量的恢複，一個是基于時間範圍。