順豐刪庫事件有感 - 數據庫數據恢復方法分享

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

毫無疑問地，我們又突然象被打了雞血般，整了整衣領，挺了挺胸，存在感立馬爆棚，拉個小板凳，就著中秋節的月光，絮絮叨叨地講講想當年。
想當年，我國那啥機構，設備升級改造，生產庫在線熱遷，腳本寫錯，rm掉了，然后，我們XXX，全部恢復所有數據（此處省略幾萬字，包含數十個自我標榜的“牛X”助詞）。可惜，得替用戶保密。
想當年，那啥機構，因為那啥，然后，……，算了，不能說，反正老傳奇了。
啥也不能說，就從技術角度聊一聊，論刪庫到恢復，再到跑不了路的作死人生。
我肯定不會聊找個收費或開源數據恢復軟件恢復，丟不起那人。
不聊Windows，因為基本和它無關。
僅限Unix、Linux上刪除oracle、db2、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。
這類文件系統，節點區域為可變區域，刪除數據時很多時候不會清除數據。
原因大概是：
1、區域可變，節點大小就可以設大一些，清除太浪費性能；
2、區域可變，緩沖區就不一定很好命中，清除節點時只需在位圖上做手腳就行了；
3、區域可變，可考慮區域重定向，原區域也就沒必要理會了。
節點不做清除，意味著“節點->數據塊索引->數據塊”的鏈條不會被打斷，自然也就容易恢復數據了。
其實也是有難度的，刪除一個文件，必然要表現在文件系統層面釋放，所以，可能“節點->數據塊索引->數據塊”整個鏈條會成為游離態，也可能象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，從日志中恢復記錄。這個日志是廣義的，包括歸檔、過程性語句表述等一切可能有記錄痕跡的數據集。在主數據文件是破壞的情況下，這些任何可能包含記錄的數據集，都應該是分析的對象。也如同數據庫文件，按文件、結構塊、記錄的思路進行最大程度的恢復。結合C1、C2、C3，再做定向性的數據集合和數據清洗，數據恢復的手段也就到頭了。
忘了聊一句Hadoop了，Hadoop,Hbase在刪除時觸發的是節點文件系統上的文件刪除行為，以最常見的Linux為例，其實就是Ext3/4上刪除文件的恢復問題，如果文件恢復不了，再參考Hadoop的HASH、fsimage之類的進行數據塊關聯。如同上述數據庫的思路。
顯而易見的是，恢復方法越向后，匯總的生產數據問題越多，數據邏輯的排查和糾正將會讓太多人夜不能寐，咬牙切齒，這時候，可能跑路都會被大家堵回來。得，還是乖乖地給大家買咖啡，向老板貢獻全年工資和資金，裝著蓬頭垢面、愁眉不展的樣子吧，興許大家還能答應每天讓你睡上2個小時。