從刪庫(kù)到恢復(fù)到跑不了路-數(shù)據(jù)恢復(fù)工程師解說(shuō)順豐刪庫(kù)事件

本文由北亞數(shù)據(jù)恢復(fù)中心(http://www.frombyte.com)張宇所寫，如有錯(cuò)誤，祝愿各位中秋節(jié)刪庫(kù)還跑不了路。

事件回顧：

據(jù)悉，順豐科技數(shù)據(jù)中心的一位鄧某因誤刪生產(chǎn)數(shù)據(jù)庫(kù)，導(dǎo)致某項(xiàng)服務(wù)無(wú)法使用并持續(xù)590分鐘。事發(fā)后，順豐將鄧某辭退，且在順豐科技全網(wǎng)通報(bào)批評(píng)。真實(shí)地玩了一把“從刪庫(kù)到跑路”。

毫無(wú)疑問(wèn)地，我們又突然象被打了雞血般，整了整衣領(lǐng)，挺了挺胸，存在感立馬爆棚，拉個(gè)小板凳，就著中秋節(jié)的月光，絮絮叨叨地講講想當(dāng)年。
想當(dāng)年，我國(guó)那啥機(jī)構(gòu)，設(shè)備升級(jí)改造，生產(chǎn)庫(kù)在線熱遷，腳本寫錯(cuò)，rm掉了，然后，我們XXX，全部恢復(fù)所有數(shù)據(jù)（此處省略幾萬(wàn)字，包含數(shù)十個(gè)自我標(biāo)榜的“牛X”助詞）?？上В锰嬗脩舯Ｃ?。
想當(dāng)年，那啥機(jī)構(gòu)，因?yàn)槟巧?，然后，……，算了，不能說(shuō)，反正老傳奇了。
啥也不能說(shuō)，就從技術(shù)角度聊一聊，論刪庫(kù)到恢復(fù)，再到跑不了路的作死人生。
我肯定不會(huì)聊找個(gè)收費(fèi)或開源數(shù)據(jù)恢復(fù)軟件恢復(fù)，丟不起那人。
不聊Windows，因?yàn)榛竞退鼰o(wú)關(guān)。
僅限Unix、Linux上刪除oracle、db2、mysql、Hadoop等的情況，就以rm -f為例吧。
數(shù)據(jù)庫(kù)的載體有多種實(shí)現(xiàn)方式，文件或裸設(shè)備。多數(shù)情況下，系統(tǒng)會(huì)以文件的方式(一切皆為文件)對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)文件進(jìn)行管理。一套數(shù)據(jù)庫(kù)，簡(jiǎn)單地看，物理上可以理解為一個(gè)或多個(gè)文件。刪庫(kù)，也就是刪一個(gè)或多個(gè)文件了。
文件是存儲(chǔ)在文件系統(tǒng)內(nèi)的。Unix和Linux上有很多種文件系統(tǒng)，這些文件系統(tǒng)保留相同的VFS文件訪問(wèn)接口，確保用戶透明地使用每種文件系統(tǒng)(當(dāng)然，也會(huì)有一些小差異，但一般都會(huì)遵循POSIX之類的標(biāo)準(zhǔn))。但實(shí)際上，不同的文件系統(tǒng)在內(nèi)核設(shè)計(jì)上千差萬(wàn)別，這也導(dǎo)致了rm -f的不同底層表現(xiàn)，再導(dǎo)致每個(gè)文件系統(tǒng)在rm -f后恢復(fù)的可能性、難度的不同。簡(jiǎn)單地說(shuō)，刪除文件后的恢復(fù)，并不是文件系統(tǒng)規(guī)范中約定的技術(shù)細(xì)節(jié)，文件系統(tǒng)設(shè)計(jì)人員壓根就沒考慮過(guò)。
在文件系統(tǒng)上恢復(fù)一個(gè)刪除的庫(kù)，大概的思路應(yīng)該是這樣的：

?圖1：恢復(fù)被刪除數(shù)據(jù)庫(kù)的思路

上述方法A：

指以文件為對(duì)象進(jìn)行恢復(fù)，也就是恢復(fù)文件系統(tǒng)上刪除(或丟失)的某幾個(gè)文件，不關(guān)心文件的內(nèi)容，僅通過(guò)文件系統(tǒng)的元數(shù)據(jù)進(jìn)行分析和恢復(fù)。元數(shù)據(jù)是一個(gè)文件系統(tǒng)的管理信息，一般不以用戶文件為載體，通常只能通過(guò)底層塊的二進(jìn)制流進(jìn)行獲取和分析。
文件系統(tǒng)中，對(duì)文件的尋址大致是這樣一個(gè)流程，每個(gè)文件系統(tǒng)在本文討論的范圍，幾乎都不例外。

?圖2 文件尋址鏈

“節(jié)點(diǎn)”表述一個(gè)文件(或目錄)的摘要信息，也包括指向下一層數(shù)據(jù)單元的指針，下一層數(shù)據(jù)單元指一個(gè)或多個(gè)指向，可能是一些附加信息，但肯定會(huì)指出“數(shù)據(jù)塊索引”。
“數(shù)據(jù)塊索引”是指指向真正數(shù)據(jù)區(qū)的指針信息。
“數(shù)據(jù)塊”就是數(shù)據(jù)本身。
除非在SSD等介質(zhì)上啟用TRIM通知硬盤清除數(shù)據(jù)，否則為了效率，刪除數(shù)據(jù)，并不會(huì)清除數(shù)據(jù)區(qū)，只會(huì)打上可重用的標(biāo)簽，這是文件恢復(fù)的原理所在。
重點(diǎn)1：刪除文件恢復(fù)的第一個(gè)有可能特別好用的方法是lsof。
Linux系統(tǒng)中使用rm -rf刪除文件后，其實(shí)文件節(jié)點(diǎn)只是從目錄樹中移除，文件內(nèi)容還是在系統(tǒng)后臺(tái)等待回收，此時(shí)有機(jī)會(huì)使用系統(tǒng)進(jìn)程號(hào)將文件拷貝出來(lái)。
# lsof |grep data.file1
??# cp /proc/xxx/xxx/xx ?/dir/data.file1
這個(gè)方法和我的專業(yè)關(guān)系不大，詳情查google。
如果lsof找不出來(lái)，那就可以考慮從文件系統(tǒng)角度進(jìn)行刪除恢復(fù)了。
按恢復(fù)的方法，文件系統(tǒng)大致分為三類：

I類：

UFS（Solaris、BSD等使用），Ext2/3/4(Linux最通用的文件系統(tǒng))，JFS(Aix最早使用)，OCFS1/2，HTFS（SCO）。
這類文件系統(tǒng)，使用固定的節(jié)點(diǎn)長(zhǎng)度，和固定的節(jié)點(diǎn)區(qū)域。文件系統(tǒng)上的所有文件（或目錄）都會(huì)在節(jié)點(diǎn)表中有唯一一個(gè)編錄對(duì)應(yīng)，用來(lái)做尋址文件的起點(diǎn)。這類文件系統(tǒng)在刪除文件時(shí)，一般會(huì)將節(jié)點(diǎn)進(jìn)行清0操作(因?yàn)楣?jié)點(diǎn)編號(hào)和位置是物理上固定的，刪除文件后必須可以重用，節(jié)點(diǎn)區(qū)操作也較為集中和頻繁，一般設(shè)計(jì)時(shí)會(huì)在刪除時(shí)順手清0)，清0后，節(jié)點(diǎn)到數(shù)據(jù)塊索引之間的紐帶就斷開了，原本一對(duì)一的映射關(guān)系，變成了N對(duì)N，N是文件總數(shù)。
所以，這類文件系統(tǒng)在刪除文件后恢復(fù)時(shí)，往往名稱和目錄對(duì)應(yīng)較為困難，像醫(yī)院的PACS、OA、郵件系統(tǒng)、語(yǔ)音庫(kù)、地質(zhì)采樣、多媒體素材，也包括數(shù)據(jù)庫(kù)文件等的對(duì)應(yīng)。(插播廣告：我們，也就是北亞數(shù)據(jù)恢復(fù)中心，www.frombyte.com，視錢如命，這種沒人做的活，我們接)。
特殊地，一些linux上的開源數(shù)據(jù)恢復(fù)軟件，ext3grep之類的，為何能恢復(fù)Ext3/4上刪除的文件呢？
是因?yàn)?，Ext3/4文件系統(tǒng)支持日志回滾，系統(tǒng)會(huì)在格式化時(shí)創(chuàng)立一個(gè)日志文件(用戶不可見)，典型的大小有32M~128M之間，在刪除文件時(shí)，節(jié)點(diǎn)會(huì)先行復(fù)制到日志文件中，再進(jìn)行刪除，以確保操作意外中斷時(shí)，可回到上一個(gè)干凈的穩(wěn)定狀態(tài)。
但缺點(diǎn)也顯而易見，日志是不斷循環(huán)回滾的，如果時(shí)間太久，或文件系統(tǒng)操作頻繁，就沒那么容易了。典型地，如果刪除大量文件，靠這個(gè)方法，只能恢復(fù)一部分。
當(dāng)然，可以再給一計(jì)了。重點(diǎn)2：刪除后，如果lsof搞不定，有可能的話，第一時(shí)間dd文件系統(tǒng)進(jìn)行歸檔保護(hù)。別以為不斷地ls，find會(huì)有奇跡出現(xiàn)，會(huì)雪上加霜的。

II類：

XFS、ReiserFS、JFS2(for AIX)、ZFS、NetApp WALF、EMC Isilon、StorNext、NTFS。
這類文件系統(tǒng)，節(jié)點(diǎn)區(qū)域?yàn)榭勺儏^(qū)域，刪除數(shù)據(jù)時(shí)很多時(shí)候不會(huì)清除數(shù)據(jù)。

原因大概是：

1、區(qū)域可變，節(jié)點(diǎn)大小就可以設(shè)大一些，清除太浪費(fèi)性能；
2、區(qū)域可變，緩沖區(qū)就不一定很好命中，清除節(jié)點(diǎn)時(shí)只需在位圖上做手腳就行了；
3、區(qū)域可變，可考慮區(qū)域重定向，原區(qū)域也就沒必要理會(huì)了。
節(jié)點(diǎn)不做清除，意味著“節(jié)點(diǎn)->數(shù)據(jù)塊索引->數(shù)據(jù)塊”的鏈條不會(huì)被打斷，自然也就容易恢復(fù)數(shù)據(jù)了。
其實(shí)也是有難度的，刪除一個(gè)文件，必然要表現(xiàn)在文件系統(tǒng)層面釋放，所以，可能“節(jié)點(diǎn)->數(shù)據(jù)塊索引->數(shù)據(jù)塊”整個(gè)鏈條會(huì)成為游離態(tài)，也可能象zfs一樣，會(huì)出現(xiàn)非常多的副本，分揀也會(huì)有難度。不同的文件系統(tǒng)，會(huì)有很多信息之間存在關(guān)聯(lián)，比如JFS2中索引塊會(huì)記錄上一項(xiàng)、下一項(xiàng)；ZFS會(huì)在節(jié)點(diǎn)中記錄下一項(xiàng)數(shù)據(jù)的HASH等，根據(jù)這些匹配點(diǎn)，就可以匹配、擇優(yōu)找到最恰當(dāng)?shù)臄?shù)據(jù)恢復(fù)起點(diǎn)。因不同的文件系統(tǒng)，有不同的針對(duì)性的方法。

III類：其他吧。

比如Vxfs、HFS+結(jié)構(gòu)上像II類，但因?yàn)楣?jié)點(diǎn)區(qū)域往往集中在前部，命中率較高，在設(shè)計(jì)上，刪除文件就會(huì)做清0或重構(gòu)樹操作，數(shù)據(jù)恢復(fù)的難度又如同I類。
比如ASM，嚴(yán)格來(lái)說(shuō)，也不太像文件系統(tǒng)了，反正結(jié)論是文件系統(tǒng)本身沒有太好的算法，保證刪除后可恢復(fù)(但依靠文件內(nèi)部結(jié)構(gòu)，恢復(fù)的可靠性非常高)
比如VMFS，基本是個(gè)大塊分配的文件系統(tǒng)，恢復(fù)方法和方案和本文多有不同，一扯內(nèi)容有點(diǎn)多，有空專門扯。
上述，是針對(duì)完整恢復(fù)文件的思路進(jìn)行描述的，但也如上文所述，有時(shí)文件是無(wú)法恢復(fù)的，也可能文件部分被破壞、覆蓋。
如果文件內(nèi)容都還在，但文件系統(tǒng)元數(shù)據(jù)部分已經(jīng)無(wú)法支撐對(duì)文件信息的還原，那就可以考慮從文件內(nèi)容的關(guān)聯(lián)性上做文章。
比如Oracle數(shù)據(jù)文件，多數(shù)情況下，按8K為頁(yè)大小，可喜的是，每一頁(yè)的頭部都有頁(yè)校驗(yàn)、頁(yè)編號(hào)和可能的文件編號(hào)。按頁(yè)校驗(yàn)從磁盤底層掃描出所有數(shù)據(jù)頁(yè)后，統(tǒng)計(jì)文件編號(hào)和頁(yè)編號(hào)，幸運(yùn)的話，就可能把文件拼接起來(lái)。
Oracle的控制文件會(huì)記錄數(shù)據(jù)文件邏輯、物理之間的關(guān)聯(lián)，分析后，文件名稱、路徑就不難還原了。
同樣的方法，可大致適應(yīng)于Sql Server、MySQL InnoDB。思維稍做變通，可適應(yīng)Sybase、DB2等。
如果是MySQL MyISAM引擎，也有辦法。記錄是一行一行依次壓入文件中的，如果某個(gè)表有主鍵，或特殊的字段，或特殊的表結(jié)構(gòu)，就能對(duì)所有磁盤上符合條件的塊進(jìn)行歸類。MyISAM還會(huì)有行溢出、行遷移的情況，即存在A指向B的數(shù)據(jù)關(guān)聯(lián)關(guān)系，根據(jù)這個(gè)關(guān)系，也可以進(jìn)一步匹配塊記錄的排列邏輯，從而組合數(shù)據(jù)文件。對(duì)于MyISAM，這其實(shí)也是恢復(fù)表或恢復(fù)記錄的方法。
這是根據(jù)文件內(nèi)容，恢復(fù)完整文件的思路。如果文件內(nèi)容不完整，或副本太多導(dǎo)致排重難度太大呢？---恢復(fù)表或表記錄。
根據(jù)表與表之間的差異，一般情況下，可以容易對(duì)找出的所有可能是數(shù)據(jù)庫(kù)的片斷進(jìn)行歸類，歸類的最直接方案是按表進(jìn)行。
按表歸納為相同一組單元后，就可以從記錄角度進(jìn)行分揀和排錯(cuò)了，如果可以借助于索引、空間分配、其他關(guān)聯(lián)表等信息，可以容易對(duì)恢復(fù)的表單元進(jìn)行數(shù)據(jù)清洗，幸運(yùn)的話，數(shù)據(jù)可能是完整的。
如果表歸納為同一單元后，與索引不對(duì)應(yīng)、有錯(cuò)誤記錄等，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法修復(fù)啟動(dòng)，就可以按表結(jié)構(gòu)，對(duì)表單元，以記錄的方式進(jìn)行抽取->插入新庫(kù)->數(shù)據(jù)定向清洗。雖然結(jié)果可能不是完美的，但很多情況下，總比沒有強(qiáng)。
還有圖1中方法C2，從日志中恢復(fù)記錄。這個(gè)日志是廣義的，包括歸檔、過(guò)程性語(yǔ)句表述等一切可能有記錄痕跡的數(shù)據(jù)集。在主數(shù)據(jù)文件是破壞的情況下，這些任何可能包含記錄的數(shù)據(jù)集，都應(yīng)該是分析的對(duì)象。也如同數(shù)據(jù)庫(kù)文件，按文件、結(jié)構(gòu)塊、記錄的思路進(jìn)行最大程度的恢復(fù)。結(jié)合C1、C2、C3，再做定向性的數(shù)據(jù)集合和數(shù)據(jù)清洗，數(shù)據(jù)恢復(fù)的手段也就到頭了。
忘了聊一句Hadoop了，Hadoop,Hbase在刪除時(shí)觸發(fā)的是節(jié)點(diǎn)文件系統(tǒng)上的文件刪除行為，以最常見的Linux為例，其實(shí)就是Ext3/4上刪除文件的恢復(fù)問(wèn)題，如果文件恢復(fù)不了，再參考Hadoop的HASH、fsimage之類的進(jìn)行數(shù)據(jù)塊關(guān)聯(lián)。如同上述數(shù)據(jù)庫(kù)的思路。
顯而易見的是，恢復(fù)方法越向后，匯總的生產(chǎn)數(shù)據(jù)問(wèn)題越多，數(shù)據(jù)邏輯的排查和糾正將會(huì)讓太多人夜不能寐，咬牙切齒，這時(shí)候，可能跑路都會(huì)被大家堵回來(lái)。得，還是乖乖地給大家買咖啡，向老板貢獻(xiàn)全年工資和資金，裝著蓬頭垢面、愁眉不展的樣子吧，興許大家還能答應(yīng)每天讓你睡上2個(gè)小時(shí)。