服務器數據恢復環境：
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文件系統數據恢復

獲取到文件系統入口后，北亞企安數據恢復工程師編寫數據指針解析程序進行地址解析。
解析數據指針：

北亞企安數據恢復——ZFS文件系統數據恢復

獲取到文件系統入口點在各磁盤的分布情況后，數據恢復工程師開始手工截取并分析文件系統內部結構。由于入口分布所在的磁盤組無缺失盤，可直接提取信息。根據ZFS文件系統的數據存儲結構找到用戶映射的LUN名稱，進而找到其節點。
5、經過分析發現故障存儲中的ZFS文件系統版本與開源版本有很大差別，無法使用之前開發的解析程序進行解析，所以北亞企安數據恢復工程師重新編寫了數據提取程序提取數據。

北亞企安數據恢復——ZFS文件系統數據恢復

6、由于磁盤組內缺盤個數較多，每個IO流都需要通過校驗得到，所以提取進度極為緩慢。與用戶溝通后得知，此ZVOL卷映射到XenServer作為存儲設備，用戶所需的文件在其中一個大小約為2T的vhd內。提取ZVOL卷頭部信息，按照XenStore卷存儲結構進行分析，發現這個2T的vhd在整個卷的尾部，計算其起始位置后從此位置開始提取數據。
7、Vhd提取完畢后，驗證其內部的壓縮包、圖片和視頻等文件，均可正常打開。聯系用戶親自驗證數據，經過反復驗證后確定文件數量與系統自動記錄的文件數量相差無幾，缺失的那部分極少數量的文件可能因為是最新生成還未刷新到磁盤。驗證文件可用性，文件全部可正常打開，本次數據恢復工作完成。

審核編輯黃宇