與時間賽跑：微盟的數據恢複為什麼需要這麼長時間

　　微盟“删庫跑路“事件已經過去好幾天了，據悉，微盟的服務已經全部恢複，對于新用戶，已經能夠正常開始所有相關的業務活動了，但是對于老用戶，數據依然沒能全部恢複，根據其官網的信息，目前恢複了商家賬戶和權益數據，截止到2月28日晚上，大約會有七成的數據完成恢複。

　　作為B端用戶以及廣大吃瓜群衆，都會有這樣的好奇，現在的雲計算，容器化部署，彈性擴縮容，數據備份技術等技術已經非常先進了，為什麼整個恢複周期還會需要這麼長時間。那麼今天我就從技術的維度來聊聊我的理解。

　　正式聊技術前，我想先說說今年羅胖的跨年演講《時間的朋友》，羅胖談到“躬身入局”讓我這個常年和IT技術打交道的”我輩中人“深有感觸，很多時候當我們站在局外的時候，感覺很多事情都不複雜，但是當你投入其中之後，就會發現原來我們隻是看到了冰山一角，很多事情要遠遠比你想的要複雜和困難。

　　舉個很形象例子，人們通常喜歡采摘低垂的果實，因為就大腦的反饋來講，低垂的果實是很容易采摘的，但是一個果實看起來低，它未必是真的低，很有可能是你離它太遠了，當你走進一些，你會發現它比你最初看起來要高，當你再走進一些，你會發現根本高不可及。

　　這就像一座山，當你離它很遠的時候，會覺得山不高，隻有當你親自走到山腳下，才會認識到自己更本不可能爬上去。這裡我配了張圖，是我當年在珠穆朗瑪峰北坡登山大本營的照片，當時的海拔是5300米左右，我的身後就是傳說中海拔8848的世界之巅珠穆朗瑪峰，你也許看起來覺得似乎不高啊，那是應為我離得還足夠遠。換句話說，當你覺得一件事情很簡單的時候，往往不是真的簡單，而很可能是因為你不懂。

　　回到這次微盟事件，也是一樣的道理，現代的大型互聯網産品，無論是toC的還是toB的，站在用戶的角度來看，使用都很簡單，但是其背後的架構複雜性就是屬于冰山下面的部分，其複雜程度會遠遠超過你的想象，我就常說一句話“認知限制了你的想象力”。所以，我相信，此時此刻，微盟一定在冰山下面盡着自己的努力來推動數據早日恢複。

　　好了，接下來聊聊偏技術的話題。很顯然，目前微盟的主要問題是在數據庫的恢複上，由于官方并沒有公布具體的技術細節，我在網上也隻找到一張非常頂層的架構示意圖，并沒有能獲得系統基礎架構，尤其是數據庫架構方面的詳細信息，所以隻能從個人經驗的角度做一些可能的猜想，目的是想讓你能夠理解其中的技術複雜程度。

　　首先讓我們了解一下數據庫的運行環境，簡化來講主要有以下三種：

　　“不上雲” ：建立在自己的數據中心，完全自己管理硬件、軟件和數據，這是雲平台普及以前的主流實踐。在這種模式下，所有相關的數據庫高可用性，容量擴展，數據備份都要有自己非常專業的團隊(DBA團隊和運維團隊)來管理和維護，對企業的技術要求是比較高的。

　　“全上雲” ：完全建立在雲端環境之上。注意，這裡的雲可以是公有雲，也可以是私有雲。雲廠商會提供全套的解決方案來支持高可用性，容量擴展和數據備份等特性。可以說，随着雲計算的普及以及泛數據庫類服務( DBaaS)的快速發展，越來越多的新興企業會選擇這個方案。

　　“假上雲” ：這種方案是最奇葩的，有點像用Louis Vuitton的包來裝菜，但在行業内也不在少數，應該說這是一個過渡階段的産物。這種方式就是把雲方案當做虛拟機來使用。這種方式和上面的“不上雲”很類似，完全沒有用好雲端的優勢，隻是把數據中心的機器移到了雲端而已。雲方案所能提供的容災、擴容等功能都被閹割了。

　　對于上面三種方式，“不上雲”和“假上雲”對于數據的風險相比“全上雲”會更大，運維人員在“不上雲”和“假上雲”的情況下更容易有機會去執行類似“rm -rf /*”和“fdisk”類型的極端操作，而“全上雲”，就比較難有機會從操作系統層面執行此類命令，數據庫數據也就不會被rm -rf /給删掉。

　　如果删除操作不是發生在操作系統的數據文件層面(備份通常是以文件形式存在的)，那麼我們利用數據庫自身的特性來恢複誤删數據的效率會大大提高。

　　同樣，面對數據的誤操作問題(比如，錯誤地批量update表中數據的某個字段)，“全上雲”也比“不上雲”和“假上雲”有明顯的優勢。這個我是有切身經曆的，以前有個項目使用自建數據庫，由于某個DBA的誤操作，在生産環境的數據庫上執行了一條沒有加where條件的update語句，直接造成競拍商品的出價記錄字段全部丢失，而後就是艱難的全量回滾和binlog重放，最終耗時4個多小時才恢複。後來同樣的誤操作發生在了雲端數據庫，回滾恢複的時間隻花了幾分鐘。

　　從之前騰訊雲對外的回應中，我們可以大概看到微盟被删的數據不在騰訊雲上，再結合目前數據恢複的速度來看，我們幾乎可以判定很大概率微盟沒有采用“全上雲”的架構，或者是隻有部分數據在雲端，而且很可能發生了比較極端的“rm -rf /*”和“fdisk”情況。那麼在這種情況下，所有的主從庫文件，全量備份文件，增量備份文件以及binlog都一起丢失了。這裡的技術挑戰主要在于傳統IT廠商如何進行磁盤恢複，已經不是任何一個雲廠商的技能點所在。

　　要在這種情況下恢複全部數據，可想而知技術難度是很大的。根據我的粗略理解，至少要跨過下面這些技術的檻。

　　獲取全量備份，如果存在異地的冷備或者災備，那是比較理想的情況，但是由于全量備份通常非常龐大，所以需要較長的時間完成文件的傳輸和校驗。如果沒有異地的全量備份可供使用，那麼就必須采取更耗時，而且不能保證一定全量成功的磁盤恢複手段。為什麼說磁盤恢複會更加耗時，我一會兒來解釋。這裡還有一個問題就是全量備份可能太“舊”了，這也給後面的恢複帶來了更多的時間成本。

　　獲取增量備份，很多時候增量備份沒有來得及做異地容災備份，所以很大概率要從磁盤恢複，這又是大量的時間消耗，而且同樣不能保證完全恢複。

　　獲取binlog，binlog是記錄所有數據庫表結構變更(例如CREATE、ALTER TABLE等)以及表數據修改(INSERT、UPDATE、DELETT等)的二進制日志文件，通常以索引文件(後綴為.index)和日志文件(後綴為.00000*)的形式存在磁盤上，通常為了保證binlog記錄數據變更的準确性，一般都是采用row格式的binlog，因此文件尺寸也不小，而且文件個數也很多。

　　有了上面這些作為基本的輸入，才能開始數據庫層面的數據導入和恢複工作，這個過程也需要花費大量的時間，而且這是基于上述文件都可以得到為前提的，如果上述備份文件中出現數據問題，那由此帶來的額外時間成本将會變得更大。

　　最後來說說磁盤文件的恢複。當我們對磁盤等存儲介質上的文件進行删除操作，甚至是格式化操作(低級格式化除外)時，磁盤上的數據并沒有真正從磁盤上消失，而隻是在文件分配表中标注了一下而已，位于數據區的數據本身并沒有被立即抹掉。隻要文件的數據區沒有被後面寫入的信息覆蓋，那麼這些被删除的文件就是可以恢複的，這就是磁盤文件在删除後可以恢複的理論基礎。

　　但是數據庫的數據文件和備份文件往往很大，那麼隻要有個别數據區出現了重寫，那麼恢複出來的文件就是不完整的，這個時候就需要人為介入來進行修正，這個工作量以及技術難度就會很大，有時還會需要借助專用的儀器設備。在更複雜的情況下，還會采用數據雕刻技術(File Carving)，數據雕刻技術是數字取證研究中頻繁使用的一種文件恢複技術，它從表面上無差别的二進制數據集即原始磁盤映象中提取文件，而不利用磁盤的文件系統類型。

　　除此之外，像微盟如此龐大的系統，各個垂直事業部可能都有各自的業務數據庫，這些數據庫甚至可能采用了不同的方案，這種架構上的異構性也會給恢複過程帶來極大的挑戰。另外，即使部分數據恢複完成之後，也不能立即上線，而要等其他相關數據恢複，并且做好數據的的交叉校驗，确保數據的萬無一失，這些都需要大量的時間。

　　這些隻是我能想到的一些情況，我站的也很遠，也是從旁觀者的維度在看問題，所以，我相信實際情況會比我所描述的更為複雜。我們還沒法對最終的恢複結果作出推斷，能夠做的隻有等待。