【伺服器資料恢復】linux ext3檔案系統下mysql資料庫資料恢復案例

北亞資料恢復發表於2022-11-09

伺服器資料恢復環境:

MYSQL資料庫伺服器,2塊硬碟組建RAID1;

DATA卷儲存了200多個資料庫;

每天將每個資料庫dump出後直接壓縮成.gz包,然後將所有重要資料庫的.gz 包放在一起壓縮成一個總的.tar.gz包,覆蓋原來

的備份;

資料檔案及備份檔案全部儲存於DATA捲上。


伺服器故障&分析:

在一次常規的維護中,管理員不小心將DATA卷下的所有檔案全部rm,刪除後管理員馬上關閉系統,再未做其它操作,但在刪

除那一刻有大量終端在訪問此伺服器。

管理員聯絡我們資料恢復中心要求恢復mysql資料庫檔案(如myd、frm、myi(可重建)檔案),或者每個資料庫的.gz包,或

者所有重要資料庫總的.tar.gz備份包。


理論上,在ext3檔案系統下刪除資料會清除inode中除節點型別、日期外的其他屬性如檔案大小、資料儲存地址等,這些屬性

會全部清0。同時目錄表中會以目錄條目長度的方式遮蔽掉已刪除的檔案,但會保留節點編號,最後會改變BITMAP中的空間

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

從資料角度來說,大多數檔案型別都會有特定的檔案頭標誌,透過檔案頭標誌是有可能找到刪除檔案的起始位置的。但EXT3

檔案系統以塊組為單位進行儲存,同時資料與索引是混合儲存於資料區的,所以資料連續儲存的可能性非常小,所以按照文

件格式進行處理可行性不大。

唯一的方案是結合上述幾個特徵,加上對日誌和儲存過程的模擬分析,儘可能地還原真實的儲存結構。


伺服器資料恢復過程:

1、首先對故障伺服器的所有硬碟做完整映象備份。

2、基於映象檔案對總的.tar.gz進行分析並嘗試恢復,但恢復出來的檔案解壓到一半左右就報錯,後續檔案列表也無法列出

。經過資料恢復工程師的分析,發現出現這種情況是因為在刪除DATA卷下的所有檔案時仍有資料寫入破壞了檔案。

3、對每個資料庫的.gz包進行分析並嘗試恢復,大多數資料庫的.gz包恢復成功。

4、對於未恢復成功的資料庫.gz包,直接恢復其myd\frm資料檔案,最終將所有資料庫的.gz包恢復成功。

5、經過使用者親自驗證,恢復出來的資料完整可用。


伺服器資料安全Tips:

1、LINUX EXT3檔案系統下資料刪除後應儘快斷掉檔案系統I/O,通常umount檔案系統即可。

2、對故障卷做dd備份,確保資料恢復操作不會對原始資料進行二次破壞。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2922520/,如需轉載,請註明出處,否則將追究法律責任。

相關文章