Linux EXT3下刪除MySQL數(shù)據(jù)庫(kù)的數(shù)據(jù)恢復(fù)

本文主要研究服務(wù)器及非WINDOWS平臺(tái)下的數(shù)據(jù)災(zāi)難恢復(fù)。

[數(shù)據(jù)恢復(fù)故障描述]

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

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

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

[數(shù)據(jù)恢復(fù)分析]

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

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

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

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

[數(shù)據(jù)恢復(fù)過程]

1、對(duì)故障卷做完整備份。

2、對(duì)總.tar.gz進(jìn)行恢復(fù)分析，但恢復(fù)出來的文件解壓到50%左右會(huì)報(bào)錯(cuò)，后續(xù)文件列表也無法列出。經(jīng)分析，最大的原因是刪除時(shí)仍有數(shù)據(jù)寫入破壞文件導(dǎo)致。

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

4、對(duì)于未恢復(fù)成功的.gz數(shù)據(jù)庫(kù)。直接恢復(fù)其mydfrm數(shù)據(jù)文件，所有數(shù)據(jù)恢復(fù)成功。

[其他]

1、LINUX EXT3數(shù)據(jù)刪除后應(yīng)盡快斷掉文件系統(tǒng)IO，通常umount文件系統(tǒng)即可。

2、對(duì)故障卷做dd備份，確保數(shù)據(jù)恢復(fù)過程不會(huì)導(dǎo)致更嚴(yán)重的故障。