目錄
恢復實例教學
典型誤操作
阿里雲WEB CentOS 雲主機，默認爲ext4文件系統。用戶rm * -rf 誤刪除MySQL數據庫整個目錄。
用戶下載安裝了extundelete等軟件，發現可以看到被刪除文件，但用恢復時報錯。
明明百度上都說extundelete是神器，爲什麼我們在生產環境，它卻很難恢復出重要數據呢？
Ext4恢復原理
文件系統由元數據和數據塊兩部分組成，元數據存放索引信息，數據塊存放文件內容。Ext3、ext4還支持journal日誌，journal循環記錄近期對文件的操作。免費數據恢復軟件，通過掃描journal日誌恢復數據。
但是journal日誌通常比較小，新的IO操作很快會覆蓋老的記錄。如下圖所示，journal僅8192 block：
恢復失敗的原因
若想嘗試，務必先做快照！！！
若想嘗試，務必先做快照！！！
若想嘗試，務必先做快照！！！
1、下載/解壓/安裝各種軟件，都在寫入大量新文件，造成嚴重的破壞。
注意：網上的extundelete恢復案例，僅在簡單的實驗環境，rm刪除幾個文件，並且立即恢復，造成extundelete的恢復能力很強的假象。但在繁忙的業務系統，誤刪後再安裝extundelete造成大量新文件寫入，再恢復的概率極低。若要測試，務必先做快照！！！
2、rm刪除後，沒有立即關機，運行的系統在持續覆蓋誤刪數據。
正式業務系統IO繁忙，導致journal很快被佔滿，使journal恢復失敗。
3、雲主機運行在雲端，傳統數據恢復人員缺乏雲運維經驗，無法快速實施強有力的恢復方案，貽誤數據恢復的最後時機
正確的數據恢復步驟
- 立即啓動雲主機保護方案，防止數據被繼續破壞
- 建立雲恢復環境
- 執行專業數據恢復方案
- 導入恢復數據，重建業務
- 在業務確認恢復之前，避免讀寫模式調用原始磁盤
-
對於誤刪後立即關機的雲主機，在專業雲數據恢復工程師的協助下，有99.99%概率恢復所有數據！
-
對於已經有一些文件寫入，journal被覆蓋的情況，用專業數據恢復方案，仍可搶救大部分重要數據！
恢復實例教學
Linux系統下，用戶誤刪除DB2數據庫，自行嘗試失敗後，聯繫數據修復工作室支持，以下恢復過程：
用戶在/dev/sda劃分兩個區，/dev/sda2劃分爲三個lv，最後一個lv格式化爲ext4，掛載在/home目錄，所有數據已刪除，並且用戶安裝了多個免費數據恢復軟件，但均無法恢復數據：
我們立即給出緊急數據保護方案，預計4小時可恢復數據：
分析誤刪除對EXT4文件系統造成的破壞情況後，我們對關鍵目錄的inode進行了重建。過程略去，相關原理請參考數據修復工作室另一篇原理解析：
《Linux ext4文件系統原理-文件系統結構及文件解析 》
，然後用專業軟件再進行掃描：
數據修復工作室在14:54恢復出所有數據，僅耗時1小時40分鐘：
恢復出目錄結構如下：
數據恢復到本地目錄下：
協助用戶將恢復出的數據導入後，DB2正常運行，恢復圓滿結束。
工作室部分恢復案例
部分extundelete失敗案例
特別注意
Linux主機上的rm誤刪、上傳覆蓋，是最危險的。主要是用戶抱有僥倖心理，沒有果然採取保護措施，甚至嘗試安裝恢復工具，造成二次破壞。
而對於雲主機，傳統數據恢復方案不再起作用，您需要有豐富雲運維經驗+Linux數據恢復經驗的複合工程師，給出專業恢復方案！
本案例中，難點是雲恢復方案設計，和ext4文件系統inode重建。
技術支持
溫馨提示：如重要數據丟失，建議在行動前諮詢專業工程師，以免數據遭到二次破壞。
