從刪庫到恢復到跑不了路-數據恢復工程師解說順豐刪庫事件

本文由北亞數據恢復中心(http://www.frombyte.com)張宇所寫，若有錯誤，祝願各位中秋節刪庫還跑不了路。

事件回顧：

據悉，順豐科技數據中心的一位鄧某因誤刪生產數據庫，致使某項服務沒法使用並持續590分鐘。事發後，順豐將鄧某辭退，且在順豐科技全網通報批評。真實地玩了一把「從刪庫到跑路」。

毫無疑問地，咱們又忽然象被打了雞血般，整了整衣領，挺了挺胸，存在感立馬爆棚，拉個小板凳，就着中秋節的月光，絮絮不休地講講想當年。
想當年，我國那啥機構，設備升級改造，生產庫在線熱遷，腳本寫錯，rm掉了，而後，咱們XXX，所有恢復全部數據（此處省略幾萬字，包含數十個自我標榜的「牛X」助詞）。惋惜，得替用戶保密。
想當年，那啥機構，由於那啥，而後，……，算了，不能說，反正老傳奇了。
啥也不能說，就從技術角度聊一聊，論刪庫到恢復，再到跑不了路的做死人生。
我確定不會聊找個收費或開源數據恢復軟件恢復，丟不起那人。
不聊Windows，由於基本和它無關。
僅限Unix、Linux上刪除oracle、db二、mysql、Hadoop等的狀況，就以rm -f爲例吧。
數據庫的載體有多種實現方式，文件或裸設備。多數狀況下，系統會以文件的方式(一切皆爲文件)對數據庫數據文件進行管理。一套數據庫，簡單地看，物理上能夠理解爲一個或多個文件。刪庫，也就是刪一個或多個文件了。
文件是存儲在文件系統內的。Unix和Linux上有不少種文件系統，這些文件系統保留相同的VFS文件訪問接口，確保用戶透明地使用每種文件系統(固然，也會有一些小差別，但通常都會遵循POSIX之類的標準)。但實際上，不一樣的文件系統在內核設計上千差萬別，這也致使了rm -f的不一樣底層表現，再致使每一個文件系統在rm -f後恢復的可能性、難度的不一樣。簡單地說，刪除文件後的恢復，並非文件系統規範中約定的技術細節，文件系統設計人員壓根就沒考慮過。
在文件系統上恢復一個刪除的庫，大概的思路應該是這樣的：

 圖1：恢復被刪除數據庫的思路

上述方法A：

指以文件爲對象進行恢復，也就是恢復文件系統上刪除(或丟失)的某幾個文件，不關心文件的內容，僅經過文件系統的元數據進行分析和恢復。元數據是一個文件系統的管理信息，通常不以用戶文件爲載體，一般只能經過底層塊的二進制流進行獲取和分析。
文件系統中，對文件的尋址大體是這樣一個流程，每一個文件系統在本文討論的範圍，幾乎都不例外。

 圖2 文件尋址鏈

「節點」表述一個文件(或目錄)的摘要信息，也包括指向下一層數據單元的指針，下一層數據單元指一個或多個指向，多是一些附加信息，但確定會指出「數據塊索引」。
「數據塊索引」是指指向真正數據區的指針信息。
「數據塊」就是數據自己。
除非在SSD等介質上啓用TRIM通知硬盤清除數據，不然爲了效率，刪除數據，並不會清除數據區，只會打上可重用的標籤，這是文件恢復的原理所在。
重點1：刪除文件恢復的第一個有可能特別好用的方法是lsof。
Linux系統中使用rm -rf刪除文件後，其實文件節點只是從目錄樹中移除，文件內容仍是在系統後臺等待回收，此時有機會使用系統進程號將文件拷貝出來。
# lsof |grep data.file1
  # cp /proc/xxx/xxx/xx  /dir/data.file1
這個方法和個人專業關係不大，詳情查google。
若是lsof找不出來，那就能夠考慮從文件系統角度進行刪除恢復了。
按恢復的方法，文件系統大體分爲三類：

I類：

UFS（Solaris、BSD等使用），Ext2/3/4(Linux最通用的文件系統)，JFS(Aix最先使用)，OCFS1/2，HTFS（SCO）。
這類文件系統，使用固定的節點長度，和固定的節點區域。文件系統上的全部文件（或目錄）都會在節點表中有惟一一個編錄對應，用來作尋址文件的起點。這類文件系統在刪除文件時，通常會將節點進行清0操做(由於節點編號和位置是物理上固定的，刪除文件後必須能夠重用，節點區操做也較爲集中和頻繁，通常設計時會在刪除時順手清0)，清0後，節點到數據塊索引之間的紐帶就斷開了，本來一對一的映射關係，變成了N對N，N是文件總數。
因此，這類文件系統在刪除文件後恢復時，每每名稱和目錄對應較爲困難，像醫院的PACS、OA、郵件系統、語音庫、地質採樣、多媒體素材，也包括數據庫文件等的對應。(插播廣告：咱們，也就是北亞數據恢復中心，www.frombyte.com，視錢如命，這種沒人作的活，咱們接)。
特殊地，一些linux上的開源數據恢復軟件，ext3grep之類的，爲什麼能恢復Ext3/4上刪除的文件呢？
是由於，Ext3/4文件系統支持日誌回滾，系統會在格式化時創立一個日誌文件(用戶不可見)，典型的大小有32M~128M之間，在刪除文件時，節點會先行復制到日誌文件中，再進行刪除，以確保操做意外中斷時，可回到上一個乾淨的穩定狀態。
但缺點也顯而易見，日誌是不斷循環回滾的，若是時間過久，或文件系統操做頻繁，就沒那麼容易了。典型地，若是刪除大量文件，靠這個方法，只能恢復一部分。
固然，能夠再給一計了。重點2：刪除後，若是lsof搞不定，有可能的話，第一時間dd文件系統進行歸檔保護。別覺得不斷地ls，find會有奇蹟出現，會雪上加霜的。

II類：

XFS、ReiserFS、JFS2(for AIX)、ZFS、NetApp WALF、EMC Isilon、StorNext、NTFS。
這類文件系統，節點區域爲可變區域，刪除數據時不少時候不會清除數據。

緣由大概是：

一、區域可變，節點大小就能夠設大一些，清除太浪費性能；
二、區域可變，緩衝區就不必定很好命中，清除節點時只需在位圖上作手腳就好了；
三、區域可變，可考慮區域重定向，原區域也就不必理會了。
節點不作清除，意味着「節點->數據塊索引->數據塊」的鏈條不會被打斷，天然也就容易恢復數據了。
其實也是有難度的，刪除一個文件，必然要表如今文件系統層面釋放，因此，可能「節點->數據塊索引->數據塊」整個鏈條會成爲遊離態，也可能象zfs同樣，會出現很是多的副本，分揀也會有難度。不一樣的文件系統，會有不少信息之間存在關聯，好比JFS2中索引塊會記錄上一項、下一項；ZFS會在節點中記錄下一項數據的HASH等，根據這些匹配點，就能夠匹配、擇優找到最恰當的數據恢復起點。因不一樣的文件系統，有不一樣的針對性的方法。

III類：其餘吧。

好比Vxfs、HFS+結構上像II類，但由於節點區域每每集中在前部，命中率較高，在設計上，刪除文件就會作清0或重構樹操做，數據恢復的難度又如同I類。
好比ASM，嚴格來講，也不太像文件系統了，反正結論是文件系統自己沒有太好的算法，保證刪除後可恢復(但依靠文件內部結構，恢復的可靠性很是高)
好比VMFS，基本是個大塊分配的文件系統，恢復方法和方案和本文多有不一樣，一扯內容有點多，有空專門扯。
上述，是針對完整恢復文件的思路進行描述的，但也如上文所述，有時文件是沒法恢復的，也可能文件部分被破壞、覆蓋。
若是文件內容都還在，但文件系統元數據部分已經沒法支撐對文件信息的還原，那就能夠考慮從文件內容的關聯性上作文章。
好比Oracle數據文件，多數狀況下，按8K爲頁大小，可喜的是，每一頁的頭部都有頁校驗、頁編號和可能的文件編號。按頁校驗從磁盤底層掃描出全部數據頁後，統計文件編號和頁編號，幸運的話，就可能把文件拼接起來。
Oracle的控制文件會記錄數據文件邏輯、物理之間的關聯，分析後，文件名稱、路徑就不難還原了。
一樣的方法，可大體適應於Sql Server、MySQL InnoDB。思惟稍作變通，可適應Sybase、DB2等。
若是是MySQL MyISAM引擎，也有辦法。記錄是一行一行依次壓入文件中的，若是某個表有主鍵，或特殊的字段，或特殊的表結構，就能對全部磁盤上符合條件的塊進行歸類。MyISAM還會有行溢出、行遷移的狀況，即存在A指向B的數據關聯關係，根據這個關係，也能夠進一步匹配塊記錄的排列邏輯，從而組合數據文件。對於MyISAM，這其實也是恢復表或恢復記錄的方法。
這是根據文件內容，恢復完整文件的思路。若是文件內容不完整，或副本太多致使排重難度太大呢？---恢復表或表記錄。
根據表與表之間的差別，通常狀況下，能夠容易對找出的全部多是數據庫的片段進行歸類，歸類的最直接方案是按表進行。
按表概括爲相同一組單元后，就能夠從記錄角度進行分揀和排錯了，若是能夠藉助於索引、空間分配、其餘關聯表等信息，能夠容易對恢復的表單元進行數據清洗，幸運的話，數據多是完整的。
若是表概括爲同一單元后，與索引不對應、有錯誤記錄等，致使數據庫沒法修復啓動，就能夠按表結構，對錶單元，以記錄的方式進行抽取->插入新庫->數據定向清洗。雖然結果可能不是完美的，但不少狀況下，總比沒有強。
還有圖1中方法C2，從日誌中恢復記錄。這個日誌是廣義的，包括歸檔、過程性語句表述等一切可能有記錄痕跡的數據集。在主數據文件是破壞的狀況下，這些任何可能包含記錄的數據集，都應該是分析的對象。也如同數據庫文件，按文件、結構塊、記錄的思路進行最大程度的恢復。結合C一、C二、C3，再作定向性的數據集合和數據清洗，數據恢復的手段也就到頭了。
忘了聊一句Hadoop了，Hadoop,Hbase在刪除時觸發的是節點文件系統上的文件刪除行爲，以最多見的Linux爲例，其實就是Ext3/4上刪除文件的恢復問題，若是文件恢復不了，再參考Hadoop的HASH、fsimage之類的進行數據塊關聯。如同上述數據庫的思路。
顯而易見的是，恢復方法越向後，彙總的生產數據問題越多，數據邏輯的排查和糾正將會讓太多人夜不能寐，咬牙切齒，這時候，可能跑路都會被你們堵回來。得，仍是乖乖地給你們買咖啡，向老闆貢獻整年工資和資金，裝着蓬頭垢面、愁雲滿面的樣子吧，興許你們還能答應天天讓你睡上2個小時。