據悉，順豐科技資料中心的一位鄧某因誤刪生產資料庫，導致某項服務無法使用並持續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、郵件系統、語音庫、地質取樣、多媒體素材，也包括資料庫檔案等的對應。(插播廣告：我們，也就是北亞資料恢復中心，，視錢如命，這種沒人做的活，我們接)。
特殊地，一些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個小時。