服務器數(shù)據(jù)恢復環(huán)境:
MYSQL數(shù)據(jù)庫服務器,2塊硬盤組建RAID1;
DATA卷存儲了200多個數(shù)據(jù)庫;
每天將每個數(shù)據(jù)庫dump出后直接壓縮成.gz包,然后將所有重要數(shù)據(jù)庫的.gz 包放在一起壓縮成一個總的.tar.gz包,覆蓋原來的備份;
數(shù)據(jù)文件及備份文件全部存儲于DATA卷上。
服務器故障&分析:
在一次常規(guī)的維護中,管理員不小心將DATA卷下的所有文件全部rm,刪除后管理員馬上關(guān)閉系統(tǒng),再未做其它操作,但在刪除那一刻有大量終端在訪問此服務器。
管理員聯(lián)系我們數(shù)據(jù)恢復中心要求恢復mysql數(shù)據(jù)庫文件(如myd、frm、myi(可重建)文件),或者每個數(shù)據(jù)庫的.gz包,或者所有重要數(shù)據(jù)庫總的.tar.gz備份包。
理論上,在ext3文件系統(tǒng)下刪除數(shù)據(jù)會清除inode中除節(jié)點類型、日期外的其他屬性如文件大小、數(shù)據(jù)存儲地址等,這些屬性會全部清0。同時目錄表中會以目錄條目長度的方式屏蔽掉已刪除的文件,但會保留節(jié)點編號,最后會改變BITMAP中的空間占用標志。即使是目錄表中存在刪除文件的節(jié)點編號,但因節(jié)點內(nèi)容已經(jīng)沒有需要的東西,與數(shù)據(jù)區(qū)也是脫鉤的。
從數(shù)據(jù)角度來說,大多數(shù)文件類型都會有特定的文件頭標志,通過文件頭標志是有可能找到刪除文件的起始位置的。但EXT3文件系統(tǒng)以塊組為單位進行存儲,同時數(shù)據(jù)與索引是混合存儲于數(shù)據(jù)區(qū)的,所以數(shù)據(jù)連續(xù)存儲的可能性非常小,所以按照文件格式進行處理可行性不大。
唯一的方案是結(jié)合上述幾個特征,加上對日志和存儲過程的模擬分析,盡可能地還原真實的存儲結(jié)構(gòu)。
服務器數(shù)據(jù)恢復過程:
1、首先對故障服務器的所有硬盤做完整鏡像備份。
2、基于鏡像文件對總的.tar.gz進行分析并嘗試恢復,但恢復出來的文件解壓到一半左右就報錯,后續(xù)文件列表也無法列出。經(jīng)過數(shù)據(jù)恢復工程師的分析,發(fā)現(xiàn)出現(xiàn)這種情況是因為在刪除DATA卷下的所有文件時仍有數(shù)據(jù)寫入破壞了文件。
3、對每個數(shù)據(jù)庫的.gz包進行分析并嘗試恢復,大多數(shù)數(shù)據(jù)庫的.gz包恢復成功。
4、對于未恢復成功的數(shù)據(jù)庫.gz包,直接恢復其mydfrm數(shù)據(jù)文件,最終將所有數(shù)據(jù)庫的.gz包恢復成功。
5、經(jīng)過用戶親自驗證,恢復出來的數(shù)據(jù)完整可用。
服務器數(shù)據(jù)安全Tips:
1、LINUX EXT3文件系統(tǒng)下數(shù)據(jù)刪除后應盡快斷掉文件系統(tǒng)I/O,通常umount文件系統(tǒng)即可。
2、對故障卷做dd備份,確保數(shù)據(jù)恢復操作不會對原始數(shù)據(jù)進行二次破壞。
審核編輯:湯梓紅
-
Linux
+關(guān)注
關(guān)注
87文章
11213瀏覽量
208736 -
服務器
+關(guān)注
關(guān)注
12文章
8977瀏覽量
85100 -
數(shù)據(jù)恢復
+關(guān)注
關(guān)注
10文章
541瀏覽量
17346
發(fā)布評論請先 登錄
相關(guān)推薦
評論