如果沒有恢復場景，備份就失去了業務價值，畢竟單純靠業務價值一把尺子就衡量系統建設其實是不公平的，但是如果數據沒有恢復成功，備份就失去了任何價值。

數據庫這個圈子，其實比較垂直，能叫出名字的就是那么些人，所以數據恢復是一個很差的標簽，而且刪庫跑路也是行不通的。

我們可以以退為進，把一些工作轉變為主動。假設我有1000臺數據庫實例，其中從庫和單實例節點有500個，那么如何保障這500個數據庫實例的數據可以恢復，在可以恢復的前提下，如何提高恢復效率，然后整體上來看，如何綜合提升備份效率，備份任務調度，如何通過增量來落實“一次全量，永遠增量”的設計模式，這些措施都會有改進，但是對于數據恢復效率還是很難保證的。

比如下面的場景：

1)數據庫參數配置不規范，/etc/my.cnf和/data/mysql_xxx/my.cnf的配置不匹配，導致實例啟動失敗

2)數據庫版本差異化，比如主流支持是5.7，突然冒出來一個5.6的版本

3)binlog解析出錯，導致后續恢復失敗

4)備份集恢復出錯，導致整體恢復失敗

如此種種的案例數不勝數，稍有不慎，就難以恢復，而像配置類的問題，雖然可以解決，但是在緊急情況下，恢復流程失敗，很難保證有良好的心態能夠快速解決，所以對于恢復質量的檢驗是過去我們一直在犯的錯誤：我們一直在完善備份，但是對于恢復側卻少有關注，認為應該是可以的，恰恰是這個應該會把我們拖入被動局面。

所以我冒出來一個隨機恢復的想法，還是假設有500個實例，那么這些實例如果我們一一恢復，每天的工作量是很龐大的，而且對系統的負載也很高，所以如果我們把風險和成本做一個綜合，這個工作的效率和意義就會很明顯。

目前的恢復主要有基于備份集恢復，基于時間點恢復，對象粒度的恢復和表結構恢復，我們通常所說的系統層恢復主要是基于備份集恢復和基于時間點恢復。

為此我設計和實現了如下的基本流程：

需要補充的是，隨機時間是在備份集的時間周期內，而隨機時間戳，則是按照近24小時內的一個隨機時間點。

所以多次隨機，能夠讓這個事情的判斷會更加明確，恢復質量一目了然。

在這個基礎上還需要一系列的事情：

1)隨機需要保證在一定的時間范圍內，所有實例都能夠覆蓋到

2)對恢復機進行線性擴展，比如提供一個恢復服務器組，可以在上面并行的跑一些恢復任務，提高恢復響應效率

3)對恢復結果進行日報可視化，恢復了哪些，效率如何，對一定時間周期內的恢復結果進行匯總和復盤

4)根據推斷統計的思維，采取一定樣本的數據，通過假設檢驗，建立相應的數據模型來進行檢驗和分析

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。