[數據恢複故障描述]

一（yī）台重要的MYSQL數（shù）據庫服務器，146GB*2，RAID1，約130GB DATA卷（juàn），存儲了大約200~300個數據庫。平時管理員（yuán）對（duì）每（měi）個數據庫dump出以後，直（zhí）接壓縮成.gz包，再將所有重要的.gz 包合起來壓縮成一個總的.tar.gz包，這些文（wén）件每日產生一次，覆蓋原來的備份。數據文件及備份文件全部存儲於data卷上。

一次係統維（wéi）護中，管理員不小心將data卷下的所有文件全部rm，刪除後，馬上停止係統，再未做其它操作，但刪除時仍有大量終端在訪問此服（fú）務器。

要求恢複mysql數據庫文件，即myd、frm、myi(可重建)文件，或每個數據庫（kù）的.gz包，或所有重要數據庫總的.tar.gz備份包。

[數（shù）據恢複分析]

ext3下的數據刪除（chú），理論上，會清除inode中除節（jiē）點類型、日期外的其他屬性，諸如文件大小（xiǎo）、數據存儲地址等屬性會全（quán）部清0，同時目錄表中會以目錄（lù）條目（mù）長度（dù）的方式（shì）屏蔽掉已刪除文件，但會保留節點編號，最後會改變（biàn）BITMAP中（zhōng）的空間占（zhàn）用標誌。

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

從數據角度，大多數文件類型都會（huì）有特定的（de）文件頭標誌，按頭（tóu）標誌是有可能找到刪除文件（jiàn）的（de）起（qǐ）始位置（zhì）的，但EXT3以塊組為單位進（jìn）行存儲，同時數據與索引（yǐn）是混合存儲於數據區的，所（suǒ）以數據連續存儲的可能性非常之小，這樣，按文件格（gé）式（shì）進行處理也是很困難的。

唯一的算法是結合上述幾個（gè）特征，加上對日誌的分析，加上對（duì）存儲過程的模擬（nǐ）分析，盡可能地逼近真實存儲（chǔ）結構。

[數據恢複（fù）過程]

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

2、對總.tar.gz進行恢複分析（xī），但恢（huī）複出來的文（wén）件解壓到50%左（zuǒ）右會（huì）報錯，後續文件列表也無法列出。經分析，最大（dà）的原因是刪除時仍有數據寫入破（pò）壞文件導致。

3、對分包的（de）.gz文件進行恢複分（fèn）析，大（dà）多（duō）數恢複成功。

4、對於（yú）未恢複成功的.gz數據庫。直接恢複其（qí）myd\frm數據文件，所有數據恢（huī）複成功。

[其他]

1、LINUX EXT3數據刪除（chú）後應盡快斷掉文件係（xì）統IO，通常umount文件（jiàn）係統即可（kě）。

2、對故障卷做dd備份，確（què）保（bǎo）數（shù）據（jù）恢複過程不會導致更嚴重的故障。