【伺服器資料恢復】ZFS檔案系統下RAIDZ多塊硬碟離線的資料恢復案例

北亞資料恢復發表於2023-02-20

伺服器資料恢復環境:

SUN ZFS系列某型號儲存陣列;

40塊磁碟組建的儲存池(其中4塊磁碟用作全域性熱備盤),池內劃分出若干空間對映到伺服器使用;

伺服器使用Windows作業系統。


伺服器故障:

伺服器在工作時由於未知原因崩潰,排除斷電、進水或者誤操作等外部因素。管理員重啟伺服器後發現無法進入系統,需要

恢復該儲存內的所有資料。


伺服器資料恢復過程:

1、對故障儲存中所有硬碟以只讀方式做映象備份,後續的資料分析和資料恢復操作都基於映象檔案進行,避免對原始資料

造成二次破壞。

2、分析磁碟映象,發現故障裝置是透過ZFS檔案系統來管理所有磁碟。磁碟內記錄系統元資訊的NVLIST較為混亂,只能粗

略得知以下資訊:故障儲存中的磁碟被分為三組,每組12塊;每個組使用ZFS檔案系統獨有的RAIDZ管理磁碟。RAIDZ級別

為2,即每個組最多可缺失2塊磁碟;故障儲存內的4塊全域性熱備全部啟用。

Tips:ZFS檔案系統中的池被稱為ZPOOL。ZPOOL的子裝置可以有很多型別:塊裝置、檔案、磁碟等等。本案例中所採用

三組RAIDZ作為子裝置。

3、經過進一步分析,發現三組RAIDZ內有兩組分別啟用的熱備盤個數為1和3。在熱備盤啟用後,第一組內又出現一塊離線

盤,第二組內則又出現兩塊離線盤。透過上面分析得到的結論可以模擬故障現場:三組RAIDZ中的第一組和第二組分別出現

離線盤,熱備盤及時進行替換;在熱備盤無冗餘的狀態下第一組RAIDZ又出現一塊離線盤,第二組RAIDZ則又出現兩塊離線

盤,ZPOOL進入高負荷狀態(每次讀取資料都需要經過校驗才能得到正確資料)。當第二組RAIDZ出現了第三塊離線盤時候

,RAIDZ崩潰、ZPOOL下線、伺服器崩潰。

4、由於ZFS檔案系統管理的儲存池與常規儲存不同。常規RAID在儲存資料時只會按照特定的規則組建池,不關心檔案在子

裝置上的位置。而ZFS檔案系統在儲存資料時會為每次寫入的資料分配適當大小的空間,並計算出指向子裝置的資料指標。

ZFS檔案系統的這種特性決定了RAIDZ缺盤時無法直接透過校驗得到資料,必須將整個ZPOOL作為一個整體進行解析。於是

,北亞企安資料恢復工程師手工擷取事務塊資料,並編寫程式獲取最大事務號入口。

獲取檔案系統入口:


獲取到檔案系統入口後,北亞企安資料恢復工程師編寫資料指標解析程式進行地址解析。

解析資料指標:


獲取到檔案系統入口點在各磁碟的分佈情況後,資料恢復工程師開始手工擷取並分析檔案系統內部結構。由於入口分佈所在

的磁碟組無缺失盤,可直接提取資訊。根據ZFS檔案系統的資料儲存結構找到使用者對映的LUN名稱,進而找到其節點。

5、經過分析發現故障儲存中的ZFS檔案系統版本與開源版本有很大差別,無法使用之前開發的解析程式進行解析,所以北亞

企安資料恢復工程師重新編寫了資料提取程式提取資料。


6、由於磁碟組內缺盤個數較多,每個IO流都需要透過校驗得到,所以提取進度極為緩慢。與使用者溝通後得知,此ZVOL卷映

射到XenServer作為儲存裝置,使用者所需的檔案在其中一個大小約為2T的vhd內。提取ZVOL卷頭部資訊,按照XenStore卷存

儲結構進行分析,發現這個2T的vhd在整個卷的尾部,計算其起始位置後從此位置開始提取資料。

7、Vhd提取完畢後,驗證其內部的壓縮包、圖片和影片等檔案,均可正常開啟。聯絡使用者親自驗證資料,經過反覆驗證後確

定檔案數量與系統自動記錄的檔案數量相差無幾,缺失的那部分極少數量的檔案可能因為是最新生成還未重新整理到磁碟。驗證

檔案可用性,檔案全部可正常開啟,本次資料恢復工作完成。


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

相關文章