服務器數據恢復環境：

一臺采用zfs文件系統的服務器，配備32塊硬盤。

服務器故障：

服務器在運行過程中崩潰，經過初步檢測沒有發現服務器有物理故障，重啟服務器后故障依舊，用戶聯系我們中心要求恢復服務器數據。

服務器數據恢復過程：

1、服務器數據恢復工程師對故障服務器中所有硬盤進行了扇區級鏡像備份，后續的數據恢復操作都在鏡像文件上進行，避免了可能對原始數據造成的二次破壞。

2、通過對鏡像文件的分析，服務器數據恢復工程師獲取關于故障服務器一些信息：服務器操作系統采用的zfs文件系統，總共組建了4組raidz。4組raidz中的2組raidz的熱備盤已經啟用，其中第一組啟用了1塊熱備盤，第二組啟用了3塊熱備盤。第一組啟動了一塊熱備盤后又有一塊正常硬盤掉線，第二組中有2塊硬盤掉線。

兩組raidz均在有硬盤離線的情況下啟用了熱備盤進行了壞盤的替換，熱備盤上線后第這兩組raidz又有其他的硬盤離線。zpool在每次讀取數據時候都需要進行校驗獲取到正確數據，緊接著第二組raidz又有硬盤離線，服務器因此崩潰。

3、重組ZPOOL，追蹤數據入口。zfs文件系統管理的存儲池與常規存儲不同，所有磁盤都由ZFS進行管理。常規RAID在存儲數據時，只按照特定的規則組建池，不關心文件在子設備上的位置。而ZFS在數據存儲時會為每次寫入的數據分配適當大小的空間，并計算得到指向子設備的數據指針。ZFS這種特性使得RAIDZ缺盤時無法直接通過校驗獲取到數據，必須將整個ZPOOL作為一個整體進行解析。

4、手工截取事務塊數據，北亞數據恢復工程師編寫程序獲取最大事務號入口：

北亞數據恢復——zfs文件系統數據恢復

獲取文件系統入口

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

北亞數據恢復——zfs文件系統數據恢復

解析數據指針

6、獲取到文件系統入口點在各磁盤的分布情況后，北亞數據恢復工程師手工截取并分析文件系統內部結構，發現入口分布所在的磁盤組無缺失盤，可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到映射的LUN名稱，最終找到其節點。

7、經過分析發現在此故障服務器采用的ZFS文件系統版本與開源版本有較大差別，北亞數據恢復工程師重新編寫了數據提取程序。由于磁盤組內缺盤數目比較多，每個IO流都需要通過校驗得到，提取進度極為緩慢。

北亞數據恢復——zfs文件系統數據恢復

8、與用戶溝通得知ZVOL卷映射到XenServer作為存儲設備，用戶所需的文件在其中一個大小約為2T的vhd內。提取ZVOL卷頭部信息，按照XenStore卷存儲結構進行分析后發現這個2T的vhd在整個卷的尾部，通過計算找到這個2T的vhd的起始位置，然后從此位置開始提取數據。

9、Vhd提取完畢后對其內部的壓縮包、圖片、視頻等文件進行驗證，均可正常打開。讓用戶親自驗證數據，結果發現恢復出來的文件數量與系統自動記錄的文件數量幾乎相同，丟失的極小數量的文件可能是因為是最新生成還未刷新到磁盤。文件全部可正常打開，本次數據恢復完成。

審核編輯：湯梓紅