Linux Ext3下刪除MySQL資料庫的資料恢複案例

[資料恢複故障描述]

　　一台重要的MySQL資料庫伺服器，146GB*2，RAID1，約130GB DATA卷，儲存了大約200~300個資料庫。平時管理員對每個資料庫dump出以後，直接壓縮成.gz包，再將所有重要的.gz 包合起來壓縮成一個總的.tar.gz包，這些檔案每日產生一次，覆蓋原來的備份。資料檔案及備份檔案全部儲存於data卷上。

　　一次系統維護中，管理員不小心將data卷下的所有檔案全部rm，刪除後，馬上停止系統，再未做其它操作，但刪除時仍有大量終端在訪問此伺服器。

　　要求恢複MySQL資料庫檔案，即myd、frm、myi(可重建)檔案，或每個資料庫的.gz包，或所有重要資料庫總的.tar.gz備份包。

[資料恢複分析]

　　Ext3下的資料刪除，理論上，會清除inode中除節點類型、日期外的其他屬性，諸如檔案大小、資料存放區地址等屬性會全部清0，同時目錄表中會以目錄條目長度的方式屏蔽掉已刪除檔案，但會保留節點編號，最後會改變BITMAP中的空間佔用標誌。

　　即使是目錄表中存在刪除檔案的節點編號，但因節點內容已經沒有需要的東西，與資料區也是脫鉤的。

　　從資料角度，大多數檔案類型都會有特定的檔案頭標誌，按頭標誌是有可能找到刪除檔案的起始位置的，但EXT3以塊組為單位進行儲存，同時資料與索引是混合儲存於資料區的，所以資料連續儲存的可能性非常之小，這樣，按檔案格式進行處理也是很困難的。

　　唯一的演算法是結合上述幾個特徵，加上對日誌的分析，加上對預存程序的模擬分析，儘可能地逼近真實儲存結構。

[資料恢複過程]

　　１、對故障卷做完整備份。

　　２、對總.tar.gz進行恢複分析，但恢複出來的檔案解壓到50%左右會報錯，後續檔案清單也無法列出。經分析，最大的原因是刪除時仍有資料寫入破壞檔案導致。

　　３、對分包的.gz檔案進行恢複分析，大多數恢複成功。

　　４、對於未恢複成功的.gz資料庫。直接恢複其myd\frm資料檔案，所有資料恢複成功。

[其他]

　　１、Linux Ext3資料刪除後應儘快斷掉檔案系統IO，通常umount檔案系統即可。

　　２、對故障卷做dd備份，確保資料恢複過程不會導致更嚴重的故障。

著作權聲明：原創作品，允許轉載，轉載時請務必以超連結形式標明文章 原始出處 、作者資訊和本聲明。否則將追究法律責任。http://zhangyu.blog.51cto.com/197148/153250

作者：張宇，北亞MYSQL資料恢複中心，轉載請聯絡作者，如果實在不想聯絡作者，至少請保留著作權，謝謝。