順豐刪庫工程師遭開除，難道他不會恢復誤刪數據？
順豐刪庫事件回顧：
據悉，順豐科技數據中心的一位鄧某因誤刪生產數據庫，導致某項服務無法使用並持續590分鐘。事發後，順豐將鄧某辭退，且在順豐科技全網通報批評。真實地玩了一把“從刪庫到跑路”。
毫無疑問地，我們又突然象被打了雞血般，整了整衣領，挺了挺胸，存在感立馬爆棚，拉個小板凳，就著中秋節的月光，絮絮叨叨地講講想當年。
好漢要提當年勇，回憶我們的牛X歲月
想當年，我國那啥機構，設備升級改造，生產庫在線熱遷，腳本寫錯，rm掉了，然後，我們XXX，全部恢復所有數據（此處省略幾萬字，包含數十個自我標榜的“牛X”助詞）。可惜，得替用戶保密。
想當年，那啥機構，因為那啥，然後，……，算了，不能說，反正老傳奇了。
分割線：正談數據庫刪除後的恢復方法
數據庫的載體有多種實現方式，文件或裸設備。多數情況下，系統會以文件的方式(一切皆為文件)對數據庫數據文件進行管理。一套數據庫，簡單地看，物理上可以理解為一個或多個文件。刪庫，也就是刪一個或多個文件了。
文件是存儲在文件系統內的。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個小時。
順豐刪庫工程師遭開除，難道他不會恢復誤刪數據？