[數據恢復故障描述]
一台重要的MYSQL數據庫服務器GB*RAID約GB DATA卷存儲了大約~個數據庫平時管理員對每個數據庫dump出以後直接壓縮成gz包再將所有重要的gz 包合起來壓縮成一個總的targz包這些文件每日產生一次覆蓋原來的備份數據文件及備份文件全部存儲於data卷上
一次系統維護中管理員不小心將data卷下的所有文件全部rm刪除後馬上停止系統再未做其它操作但刪除時仍有大量終端在訪問此服務器
要求恢復mysql數據庫文件即mydfrmmyi(可重建)文件或每個數據庫的gz包或所有重要數據庫總的targz備份包
[數據恢復分析]
ext下的數據刪除理論上會清除inode中除節點類型日期外的其他屬性諸如文件大小數據存儲地址等屬性會全部清同時目錄表中會以目錄條目長度的方式屏蔽掉已刪除文件但會保留節點編號最後會改變BITMAP中的空間占用標志
即使是目錄表中存在刪除文件的節點編號但因節點內容已經沒有需要的東西與數據區也是脫鉤的
從數據角度大多數文件類型都會有特定的文件頭標志按頭標志是有可能找到刪除文件的起始位置的但EXT以塊組為單位進行存儲同時數據與索引是混合存儲於數據區的所以數據連續存儲的可能性非常之小這樣按文件格式進行處理也是很困難的
唯一的算法是結合上述幾個特征加上對日志的分析加上對存儲過程的模擬分析盡可能地逼近真實存儲結構
[數據恢復過程]
對故障卷做完整備份
對總targz進行恢復分析但恢復出來的文件解壓到%左右會報錯後續文件列表也無法列出經分析最大的原因是刪除時仍有數據寫入破壞文件導致
對分包的gz文件進行恢復分析大多數恢復成功
對於未恢復成功的gz數據庫直接恢復其myd\frm數據文件所有數據恢復成功
[其他]
LINUX EXT數據刪除後應盡快斷掉文件系統IO通常umount文件系統即可
對故障卷做dd備份確保數據恢復過程不會導致更嚴重的故障
From:http://tw.wingwit.com/Article/program/MySQL/201311/29362.html
