服務器數據恢復環境：

MYSQL數據庫服務器，2塊硬盤組建RAID1;

DATA卷存儲了200多個數據庫;

每天將每個數據庫dump出后直接壓縮成.gz包，然后將所有重要數據庫的.gz 包放在一起壓縮成一個總的.tar.gz包，覆蓋原來的備份;

數據文件及備份文件全部存儲于DATA卷上。

服務器故障&分析：

在一次常規的維護中，管理員不小心將DATA卷下的所有文件全部rm，刪除后管理員馬上關閉系統，再未做其它操作，但在刪除那一刻有大量終端在訪問此服務器。

管理員聯系我們數據恢復中心要求恢復mysql數據庫文件(如myd、frm、myi(可重建)文件)，或者每個數據庫的.gz包，或者所有重要數據庫總的.tar.gz備份包。

理論上，在ext3文件系統下刪除數據會清除inode中除節點類型、日期外的其他屬性如文件大小、數據存儲地址等，這些屬性會全部清0。同時目錄表中會以目錄條目長度的方式屏蔽掉已刪除的文件，但會保留節點編號，最后會改變BITMAP中的空間占用標志。即使是目錄表中存在刪除文件的節點編號，但因節點內容已經沒有需要的東西，與數據區也是脫鉤的。

從數據角度來說，大多數文件類型都會有特定的文件頭標志，通過文件頭標志是有可能找到刪除文件的起始位置的。但EXT3文件系統以塊組為單位進行存儲，同時數據與索引是混合存儲于數據區的，所以數據連續存儲的可能性非常小，所以按照文件格式進行處理可行性不大。

唯一的方案是結合上述幾個特征，加上對日志和存儲過程的模擬分析，盡可能地還原真實的存儲結構。

服務器數據恢復過程：

1、首先對故障服務器的所有硬盤做完整鏡像備份。

2、基于鏡像文件對總的.tar.gz進行分析并嘗試恢復，但恢復出來的文件解壓到一半左右就報錯，后續文件列表也無法列出。經過數據恢復工程師的分析，發現出現這種情況是因為在刪除DATA卷下的所有文件時仍有數據寫入破壞了文件。

3、對每個數據庫的.gz包進行分析并嘗試恢復，大多數數據庫的.gz包恢復成功。

4、對于未恢復成功的數據庫.gz包，直接恢復其mydfrm數據文件，最終將所有數據庫的.gz包恢復成功。

5、經過用戶親自驗證，恢復出來的數據完整可用。

服務器數據安全Tips：

1、LINUX EXT3文件系統下數據刪除后應盡快斷掉文件系統I/O，通常umount文件系統即可。

2、對故障卷做dd備份，確保數據恢復操作不會對原始數據進行二次破壞。

審核編輯：湯梓紅