Linux EXT3下刪除MySQL數據庫的數據恢復

本文主要研究服務(wù)器及非WINDOWS平臺下的數據災難恢復。

[數據恢復故障描述]

一臺重要的MYSQL數據庫服務(wù)器，146GB*2，RAID1，約130GB DATA卷，存儲了大約200~300個(gè)數據庫。平時(shí)管理員對每個(gè)數據庫dump出以后，直接壓縮成.gz包，再將所有重要的.gz 包合起來(lái)壓縮成一個(gè)總的.tar.gz包，這些文件每日產(chǎn)生一次，覆蓋原來(lái)的備份。數據文件及備份文件全部存儲于data卷上。

一次系統維護中，管理員不小心將data卷下的所有文件全部rm，刪除后，馬上停止系統，再未做其它操作，但刪除時(shí)仍有大量終端在訪(fǎng)問(wèn)此服務(wù)器。

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

[數據恢復分析]

ext3下的數據刪除，理論上，會(huì )清除inode中除節點(diǎn)類(lèi)型、日期外的其他屬性，諸如文件大小、數據存儲地址等屬性會(huì )全部清0，同時(shí)目錄表中會(huì )以目錄條目長(cháng)度的方式屏蔽掉已刪除文件，但會(huì )保留節點(diǎn)編號，最后會(huì )改變BITMAP中的空間占用標志。

即使是目錄表中存在刪除文件的節點(diǎn)編號，但因節點(diǎn)內容已經(jīng)沒(méi)有需要的東西，與數據區也是脫鉤的。

從數據角度，大多數文件類(lèi)型都會(huì )有特定的文件頭標志，按頭標志是有可能找到刪除文件的起始位置的，但EXT3以塊組為單位進(jìn)行存儲，同時(shí)數據與索引是混合存儲于數據區的，所以數據連續存儲的可能性非常之小，這樣，按文件格式進(jìn)行處理也是很困難的。

唯一的算法是結合上述幾個(gè)特征，加上對日志的分析，加上對存儲過(guò)程的模擬分析，盡可能地逼近真實(shí)存儲結構。

[數據恢復過(guò)程]

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

2、對總.tar.gz進(jìn)行恢復分析，但恢復出來(lái)的文件解壓到50%左右會(huì )報錯，后續文件列表也無(wú)法列出。經(jīng)分析，最大的原因是刪除時(shí)仍有數據寫(xiě)入破壞文件導致。

3、對分包的.gz文件進(jìn)行恢復分析，大多數恢復成功。

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

[其他]

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

2、對故障卷做dd備份，確保數據恢復過(guò)程不會(huì )導致更嚴重的故障。