服務器存儲數據恢復環境:
ZFS Storage 7320存儲陣列中有32塊硬盤。32塊硬盤分為4組,每組8塊硬盤,共組建了3組RAIDZ,每組raid都配置了熱備盤。
服務器存儲故障:
服務器存儲運行過程中突然崩潰,排除人為誤操作、斷電、進水和其他機房不穩定因素。管理員重啟服務器存儲,系統無法進入,需要恢復服務器存儲中的數據。
服務器存儲數據恢復過程:
1、將故障服務器存儲中所有硬盤標記后取出,以只讀方式進行扇區級完整鏡像,鏡像完成后將所有磁盤按照原樣還原到原存儲中,后續的數據分析和數據恢復操作都基于鏡像文件進行,避免對原始磁盤數據造成二次破壞。
2、基于鏡像文件分析所有硬盤中的底層數據,發現服務器存儲中的熱備盤全部啟用,上層采用ZFS文件系統。
Tips:
在ZFS文件系統中,存儲池被稱為ZPOOL。ZPOOL可以有各種類別的子設備:塊設備、文件、磁盤等等。本案例中ZPOOL的子設備是三組RAIDZ作為子設備。
經過對底層數據的分析發現,三組RAIDZ中的兩組RAIDZ啟用的熱備盤的個數分別為1和3。啟用熱備盤后,第一組RAIDZ中又有一塊盤離線,第二組RAIDZ中則又有兩塊硬盤離線。
根據上述分析結果模擬故障現場:三組RAIDZ中的兩組RAIDZ出現硬盤離線的情況,熱備盤自動上線替換離線盤。在熱備盤無冗余的情況下第一組RAIDZ中又有一塊盤離線,第二組RAIDZ中則有兩塊盤離線,ZPOOL進入高負荷狀態(每次讀取數據都需要校驗);當第二組RAIDZ中出現第三塊離線盤的時候,該組RAIDZ崩潰,ZPOOL下線,服務器存儲崩潰。
3、ZFS管理的存儲池與常規存儲池不同。在ZFS文件系統下,ZFS管理所有磁盤。常規RAID在存儲數據時會按照特定的規則組建池,并不關心文件在子設備上的位置。在ZFS下,存儲數據時會為每次寫入的數據分配適當大小的空間,并計算出指向子設備的數據指針。所以RAIDZ缺盤時無法直接通過校驗得到數據,必須將整個ZPOOL作為一個整體進行解析。
4、北亞企安數據恢復工程師手工截取事務塊數據,并編寫程序獲取最大事務號入口。
獲取文件系統入口:
北亞企安數據恢復—ZFS文件系統數據恢復
5、獲取到文件系統入口后,北亞企安數據恢復工程師編寫數據指針解析程序進行地址解析。
解析數據指針:
北亞企安數據恢復—ZFS文件系統數據恢復
6、獲取到文件系統入口點在各磁盤上的分布情況后,北亞企安數據恢復工程師開始手工截取并分析文件系統內部結構。入口點所在的磁盤組無缺失盤,可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到映射的LUN的名稱,進而找到其節點。
7、經過分析發現此存儲中的ZFS版本與開源版本有較大差別,無法使用之前開發的解析程序進行解析,所以北亞企安數據恢復工程師重新編寫程序進行解析。
北亞企安數據恢復—ZFS文件系統數據恢復
8、由于缺盤個數較多,每個IO流都需要通過校驗得到,進度極為緩慢。與用戶方溝通后得知此ZVOL卷映射到XenServer作為存儲設備,所需要的文件在一個vhd內。提取ZVOL卷頭部信息,按照XenStore卷存儲結構進行分析,發現該vhd在整個卷的尾部。計算出其起始位置后從此位置開始提取數據。
9、Vhd提取完畢后,驗證其內部的壓縮包、圖片、視頻等文件,均可正常打開。
10、交由用戶方驗證恢復出來的數據。經過驗證,發現恢復出來的文件數量與系統自動記錄的文件數量差不多,稍微有點出入。丟失的極少量文件應該是因為這些文件是新生成的還未存儲到磁盤。隨機驗證恢復出來的文件,全部可正常打開。用戶方認可數據恢復結果。
審核編輯 黃宇
-
服務器
+關注
關注
12文章
9437瀏覽量
86512 -
RAID
+關注
關注
0文章
280瀏覽量
35383 -
數據恢復
+關注
關注
10文章
596瀏覽量
17793 -
zfs
+關注
關注
0文章
7瀏覽量
2656
發布評論請先 登錄
相關推薦
服務器數據恢復—如何讓ZFS文件系統數據“起死回生”?

服務器數據恢復—raid5陣列+reiserfs文件系統數據恢復案例
服務器數據恢復—異常斷電導致linux系統無法啟動的數據恢復案例
服務器數據恢復—xfs文件系統服務器數據恢復案例
服務器數據恢復—X3650服務器raid5磁盤陣列數據恢復案例
服務器數據恢復—CX4-480存儲中XFS文件系統分區丟失的數據恢復案例

服務器數據恢復—服務器XFS分區丟失,無法訪問的數據恢復案例

評論