Linux ext4 rm 誤刪，用extundelete恢復失敗/報錯，無數血淚教訓！！！附：ext4誤刪後的正確處理步驟
目錄
恢復例項教學
典型使用者故事
阿里雲WEB伺服器主機，安裝CentOS系統，建立ext4檔案系統。使用者誤刪除MySQL資料庫整個目錄，導致網站業務停機。
使用者自行下載安裝了extundelete等反刪除軟體，發現可以看到被刪除檔案的inode，並顯示為delete狀態，但用恢復時報錯無法恢復。
Ext4誤刪恢復原理
檔案系統由MetaData和DataBlock兩部分組成，MetaData存放索引訊息，superblock，inode分配表，datablock分配表等都可歸類為MetaData。DataBlock存放真實資料塊。而Ext3、ext4檔案系統支援journal
但是journal日誌通常比較小，新的IO操作很快會覆蓋老的記錄。如下圖所示，journal僅8192 block：
恢復失敗的主要原因
1、誤刪除後，沒有立即關機，執行的系統在持續覆蓋誤刪資料。
作業系統只要在執行，就會有IO，而對於業務系統，IO可能更頻繁。這導致journal很快被佔滿，自動迴圈刪除之前的操作記錄，並重新分配使用inode，使得通過journal恢復失敗。
2、下載、解壓、安裝extundelete，這些操作都在佔用journal
注意：網上多數extundelete的恢復案例，僅在簡單的實驗環境，刪除了幾個檔案，並且立即恢復，造成extundelete的恢復能力很強的假象。但在繁忙的業務系統，誤刪後再安裝extundelete，資料恢復的可能性極低。
3、更多的IO寫入，將有概率覆蓋檔案的DataBlock，這表示資料徹底不可能恢復。
4、雲主機執行在雲端，傳統資料恢復人員缺乏雲運維經驗，無法快速實施強有力的恢復方案，貽誤資料恢復的最後時機
正確的資料恢復步驟
- 立即啟動雲主機保護方案，防止資料被繼續破壞
- 建立雲恢復環境
- 執行專業資料恢復方案
- 匯入恢復資料，重建業務
- 在業務確認恢復之前，避免讀寫模式呼叫原始磁碟
- 對於誤刪後立即關機的雲主機，在專業雲資料恢復工程師的協助下，有99.99%可能性恢復所有資料。
- 對於已經有大量檔案寫入，journal被覆蓋的情況，用專業資料恢復方案，仍可搶救重要資料。
恢復例項教學
Linux系統下，使用者誤刪除DB2資料庫，自行嘗試失敗後，聯絡資料修復工作室支援，以下恢復過程：
雲資料恢復工程師隨後預檢，確認使用者在/dev/sda劃分兩個區，/dev/sda2劃分為三個lv，最後一個lv格式化為ext4，掛載在/home目錄，所有資料已刪除，並且使用者安裝了多個免費資料恢復軟體，但均無法恢復資料：
資料修復工作室立即給出緊急資料保護方案，預計4小時可恢復資料：
資料修復工作室立即分析誤刪除對EXT4檔案系統造成的破壞，並對關鍵目錄的inode進行了重建（過程略去，相關原理請參考資料修復工作室另一篇原理解析：Linux ext4檔案系統原理-檔案系統結構及檔案解析 ），然後用專業軟體再進行掃描：
資料修復工作室在14:54恢復出所有資料，僅耗時1小時40分鐘：
恢復出目錄結構如下：
資料恢復到本地目錄下：
協助使用者將恢復出的資料匯入後，DB2正常執行，恢復圓滿結束。
工作室部分恢復案例
部分extundelete失敗案例
技術支援
溫馨提示：如重要資料丟失，還請在行動前諮詢專業工程師建議，以免資料遭到二次破壞。