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

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

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

[[316971]]

舉個(gè)很形象例子，人們通常喜歡采摘低垂的果實(shí)，因?yàn)榫痛竽X的反饋來講，低垂的果實(shí)是很容易采摘的，但是一個(gè)果實(shí)看起來低，它未必是真的低，很有可能是你離它太遠(yuǎn)了，當(dāng)你走進(jìn)一些，你會發(fā)現(xiàn)它比你最初看起來要高，當(dāng)你再走進(jìn)一些，你會發(fā)現(xiàn)根本高不可及。

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

[[316972]]

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

好了，接下來聊聊偏技術(shù)的話題。很顯然，目前微盟的主要問題是在數(shù)據(jù)庫的恢復(fù)上，由于官方并沒有公布具體的技術(shù)細(xì)節(jié)，我在網(wǎng)上也只找到一張非常頂層的架構(gòu)示意圖，并沒有能獲得系統(tǒng)基礎(chǔ)架構(gòu)，尤其是數(shù)據(jù)庫架構(gòu)方面的詳細(xì)信息，所以只能從個(gè)人經(jīng)驗(yàn)的角度做一些可能的猜想，目的是想讓你能夠理解其中的技術(shù)復(fù)雜程度。

首先讓我們了解一下數(shù)據(jù)庫的運(yùn)行環(huán)境，簡化來講主要有以下三種：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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