1. 程式人生 > >Linux ext4 rm 誤刪,用extundelete恢復失敗/報錯,無數血淚教訓!!!附:ext4誤刪後的正確處理步驟

Linux ext4 rm 誤刪,用extundelete恢復失敗/報錯,無數血淚教訓!!!附:ext4誤刪後的正確處理步驟

目錄

典型使用者故事

Ext4誤刪恢復原理

恢復失敗的主要原因

正確的資料恢復步驟

恢復例項教學

工作室部分恢復案例

技術支援



典型使用者故事

阿里雲WEB伺服器主機,安裝CentOS系統,建立ext4檔案系統。使用者誤刪除MySQL資料庫整個目錄,導致網站業務停機。

使用者自行下載安裝了extundelete等反刪除軟體,發現可以看到被刪除檔案的inode,並顯示為delete狀態,但用恢復時報錯無法恢復。


Ext4誤刪恢復原理

檔案系統由MetaData和DataBlock兩部分組成,MetaData存放索引訊息,superblock,inode分配表,datablock分配表等都可歸類為MetaData。DataBlock存放真實資料塊。而Ext3、ext4檔案系統支援journal

日誌,journal迴圈記錄近期對檔案的操作,在系統意外掉電時,可利用journal修復檔案系統。而多數免費資料恢復軟體,通過掃描journal日誌恢復資料。

但是journal日誌通常比較小,新的IO操作很快會覆蓋老的記錄。如下圖所示,journal僅8192 block:


恢復失敗的主要原因

1、誤刪除後,沒有立即關機,執行的系統在持續覆蓋誤刪資料。

作業系統只要在執行,就會有IO,而對於業務系統,IO可能更頻繁。這導致journal很快被佔滿,自動迴圈刪除之前的操作記錄,並重新分配使用inode,使得通過journal恢復失敗。

2、下載、解壓、安裝extundelete,這些操作都在佔用journal

。使用者嘗試恢復檔案過程,就是破壞檔案的過程。

注意:網上多數extundelete的恢復案例,僅在簡單的實驗環境,刪除了幾個檔案,並且立即恢復,造成extundelete的恢復能力很強的假象。但在繁忙的業務系統,誤刪後再安裝extundelete,資料恢復的可能性極低。

 

3、更多的IO寫入,將有概率覆蓋檔案的DataBlock,這表示資料徹底不可能恢復。

4、雲主機執行在雲端,傳統資料恢復人員缺乏雲運維經驗,無法快速實施強有力的恢復方案,貽誤資料恢復的最後時機



正確的資料恢復步驟

  1. 立即啟動雲主機保護方案,防止資料被繼續破壞
  2. 建立雲恢復環境
  3. 執行專業資料恢復方案
  4. 匯入恢復資料,重建業務
  5. 在業務確認恢復之前,避免讀寫模式呼叫原始磁碟
  • 對於誤刪後立即關機的雲主機,在專業雲資料恢復工程師的協助下,有99.99%可能性恢復所有資料。
  • 對於已經有大量檔案寫入,journal被覆蓋的情況,用專業資料恢復方案,仍可搶救重要資料。

恢復例項教學

Linux系統下,使用者誤刪除DB2資料庫,自行嘗試失敗後,聯絡資料修復工作室支援,以下恢復過程:

雲資料恢復工程師隨後預檢,確認使用者在/dev/sda劃分兩個區,/dev/sda2劃分為三個lv,最後一個lv格式化為ext4,掛載在/home目錄,所有資料已刪除,並且使用者安裝了多個免費資料恢復軟體,但均無法恢復資料:

資料修復工作室立即給出緊急資料保護方案,預計4小時可恢復資料:

資料修復工作室立即分析誤刪除對EXT4檔案系統造成的破壞,並對關鍵目錄的inode進行了重建(過程略去,相關原理請參考資料修復工作室另一篇原理解析:Linux ext4檔案系統原理-檔案系統結構及檔案解析 ),然後用專業軟體再進行掃描:

資料修復工作室在14:54恢復出所有資料,僅耗時1小時40分鐘:

恢復出目錄結構如下:

資料恢復到本地目錄下:

協助使用者將恢復出的資料匯入後,DB2正常執行,恢復圓滿結束。


工作室部分恢復案例

部分extundelete失敗案例


技術支援

溫馨提示:如重要資料丟失,還請在行動前諮詢專業工程師建議,以免資料遭到二次破壞。

恢復支援:https://item.taobao.com/item.htm?id=583275204347