本文作者是北亞數(shù)據(jù)恢復中心總工程師張宇， 主要研究服務器及非WINDOWS平臺下的數(shù)據(jù)災難恢復。
　?。蹟?shù)據(jù)恢復故障描述］
　　一臺重要的MYSQL數(shù)據(jù)庫服務器，146GB*2，RAID1，約130GB DATA卷，存儲了大約200~300個數(shù)據(jù)庫。平時管理員對每個數(shù)據(jù)庫dump出以后，直接壓縮成.gz包，再將所有重要的.gz 包合起來壓縮成一個總的.tar.gz包，這些文件每日產(chǎn)生一次，覆蓋原來的備份。數(shù)據(jù)文件及備份文件全部存儲于data卷上。
　　一次系統(tǒng)維護中，管理員不小心將data卷下的所有文件全部rm，刪除后，馬上停止系統(tǒng)，再未做其它操作，但刪除時仍有大量終端在訪問此服務器。
　　要求恢復mysql數(shù)據(jù)庫文件，即myd、frm、myi（可重建）文件，或每個數(shù)據(jù)庫的.gz包，或所有重要數(shù)據(jù)庫總的.tar.gz備份包。
　?。蹟?shù)據(jù)恢復分析］
　　ext3下的數(shù)據(jù)刪除，理論上，會清除inode中除節(jié)點類型、日期外的其他屬性，諸如文件大小、數(shù)據(jù)存儲地址等屬性會全部清0，同時目錄表中會以目錄條目長度的方式屏蔽掉已刪除文件，但會保留節(jié)點編號，最后會改變BITMAP中的空間占用標志。
　　即使是目錄表中存在刪除文件的節(jié)點編號，但因節(jié)點內(nèi)容已經(jīng)沒有需要的東西，與數(shù)據(jù)區(qū)也是脫鉤的。
　　從數(shù)據(jù)角度，大多數(shù)文件類型都會有特定的文件頭標志，按頭標志是有可能找到刪除文件的起始位置的，但EXT3以塊組為單位進行存儲，同時數(shù)據(jù)與索引是混合存儲于數(shù)據(jù)區(qū)的，所以數(shù)據(jù)連續(xù)存儲的可能性非常之小，這樣，按文件格式進行處理也是很困難的。
　　唯一的算法是結合上述幾個特征，加上對日志的分析，加上對存儲過程的模擬分析，盡可能地逼近真實存儲結構。
　　［數(shù)據(jù)恢復過程］
　　1、對故障卷做完整備份。
　　2、對總.tar.gz進行恢復分析，但恢復出來的文件解壓到50%左右會報錯，后續(xù)文件列表也無法列出。經(jīng)分析，最大的原因是刪除時仍有數(shù)據(jù)寫入破壞文件導致。
　　3、對分包的.gz文件進行恢復分析，大多數(shù)恢復成功。
　　4、對于未恢復成功的.gz數(shù)據(jù)庫。直接恢復其mydfrm數(shù)據(jù)文件，所有數(shù)據(jù)恢復成功。
　　［其他］
　　1、LINUX EXT3數(shù)據(jù)刪除后應盡快斷掉文件系統(tǒng)IO，通常umount文件系統(tǒng)即可。
　　2、對故障卷做dd備份，確保數(shù)據(jù)恢復過程不會導致更嚴重的故障。
?