服務器數據恢復環境:
一臺服務器共配備32塊硬盤,組建了4組RAIDZ,Windows操作系統+zfs文件系統。
服務器故障:
服務器在運行過程中突然崩潰,經過初步檢測檢測沒有發現服務器存在物理故障,重啟服務器后故障依舊,需要恢復服務器內的大量數據。
經過北亞企安數據恢復工程師的初步檢測,發現故障服務器中4組raidz里有兩組raidz中的熱備盤啟動。其中第一組raidz啟用了一塊熱備盤,之后又有一塊硬盤掉線;第二組raidz第一塊磁盤離線后又有2塊硬盤掉線,總共啟用了三塊熱備盤。
這兩組raidz中硬盤離線后均啟用了熱備盤替換壞盤,熱備盤上線后這2組raidz中又出現其他硬盤離線的情況。為了得到正確數據,zpool在每次讀取數據時都會進行校驗。第二組raidz熱備盤上線后又有硬盤離線,服務器徹底崩潰。
服務器數據恢復過程:
1、將故障服務器中所有磁盤編號后取出,以只讀方式將所有磁盤做全盤鏡像,鏡像完成后將所有磁盤按照編號還原到原服務器中,后續的數據分析和數據恢復操作都基于鏡像文件進行,避免對原始磁盤數據造成二次破壞。
2、ZFS管理的存儲池與常規RAID不同。常規RAID在存儲數據時會按照特定的規則組建存儲池,并不考慮文件在子設備上的位置;而ZFS在存儲數據時會為每次寫入的數據分配適當大小的空間,通過計算獲取指向子設備的數據指針。ZFS的這種特性讓RAIDZ在缺盤時無法直接進行校驗得到數據,必須將整個ZPOOL作為一個整體進行解析。
3、手工截取事務塊數據,北亞企安數據恢復工程師編寫程序獲取最大事務號入口。
獲取文件系統入口:
北亞企安數據恢復——zfs數據恢復
4、獲取到文件系統入口后,北亞企安數據恢復工程師編寫數據指針解析程序進行地址解析。
解析數據指針:
北亞企安數據恢復——zfs數據恢復
5、獲取到文件系統入口點在各磁盤分布情況后,數據恢復工程師手工截取&分析文件系統內部結構。入口分布所在的磁盤組無缺失盤,可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到映射的LUN名稱,進而找到其節點。
6、由于在此ZFS版本與開源版本有較大差別,無法使用原先開發的解析程序進行解析,所以數據恢復工程師只能重新編寫數據提取程序。
北亞企安數據恢復——zfs數據恢復
7、由于磁盤組內缺盤個數較多,每個IO流都需要通過校驗得到,提取進度極為緩慢。與用戶方溝通后得知此ZVOL卷映射到XenServer作為存儲設備,用戶需的文件在其中一個大小約為2T的vhd內。提取ZVOL卷頭部信息,按照XenStore卷存儲結構進行分析,發現2T vhd在整個卷的尾部,計算得到其起始位置,從起始位置開始提取數據。
8、Vhd提取完畢后,對其內部的壓縮包、圖片、視頻等文件進行驗證,均可正常打開。
9、用戶發經過驗證后,確定恢復出來的文件數量與系統自動記錄的文件數量差不多,極小部分丟失的文件可能是由于這些文件是新生成的還未刷新到磁盤。用戶驗證文件的可用性,文件全部可正常打開,本次數據恢復工作完成。
審核編輯 黃宇
-
存儲
+關注
關注
13文章
4355瀏覽量
86175 -
服務器
+關注
關注
12文章
9304瀏覽量
86066 -
數據恢復
+關注
關注
10文章
585瀏覽量
17632
發布評論請先 登錄
相關推薦
評論