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

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

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

[[316971]]

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

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

[[316972]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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