-s 文件系統管理 tro 分享 使用 raid 方案 溝通 容量

一、ZFS文件系統
ZFS是一款128bit文件系統，總容量是現有64bit文件系統的1.84x10^19倍，其支持的單個存儲卷容量達到16EiB（2^64byte，即 16x1024x1024TB）；一個zpool存儲池可以擁有2^64個卷，總容量最大256ZiB（2^78byte）；整個系統又可以擁有2^64個存儲 池。可以說在相當長的未來時間內，ZFS幾乎不太可能出現存儲空間不足的問題。另外，它還擁有自優化，自動校驗數據完整性，存儲池/卷系統易管理等諸多優點。較ext3系統有較大運行速率，提高大約30%-40%。
二、存儲環境部署：
用戶所使用存儲設備型號為ORACLE-SUN-ZFS7320，共使用40塊磁盤組建存儲池，其中四塊磁盤作為全局熱備。池內劃分出若幹空間映射到服務器使用，服務器操作系統為Windows。

三、故障情況：
在使用過程中進行文件遷移時存儲突然發生故障，無法讀取數據。設備管理界面報錯如圖所示：

四、用戶所需數據：
恢復映射到windows服務器的其中一個大小為12T LUN中的丟失數據。在了解到上述情況後，開始制定恢復方案。
五、磁盤鏡像
為防止對客戶原始磁盤內數據造成破壞，首先分別對各磁盤進行鏡像拷貝。拷貝過程中發現有兩塊磁盤內有物理壞道無法生成鏡像，對其進行標註。
六、分析磁盤底層數據
獲取到磁盤鏡像後進行分析，發現其采用ZFS文件系統管理所有磁盤。但磁盤內記錄系統元信息的NVLIST較為混亂，只能粗略得出以下信息：

1、磁盤被分為三組，每組12塊.

2、單個組內使用ZFS特有的RAIDZ管理所有磁盤.

3、RAIDZ級別為2,即每個組內可缺失磁盤個數最大為2.

4、全局熱備全部啟用.
七、故障推測
在ZFS文件系統中，池被稱為ZPOOL。ZPOOL的子設備可以有很多種類，包括塊設備、文件、磁盤等等，在本案例中所采用的是其中的一種------三組RAIDZ作為子設備。
經過分析發現，三組RAIDZ內有兩組分別啟用熱備盤個數為1和3。在啟用熱備盤後，第一組內仍出現一塊離線盤，第二組內則出現兩塊。以此進行故障現場模擬：三組RAIDZ內第一二組分別出現離線盤，熱備盤及時進行替換；熱備盤無冗余狀態下第一組出現一塊離線盤，第二組出現兩塊離線盤，ZPOOL進入高負荷狀態（每次讀取數據都需要進行校驗得到正確數據）；第二組內出現第三塊離線盤，RAIDZ崩潰，ZPOOL下線。

八、ZPOOL重組
ZFS管理的存儲池與常規存儲不同，所有磁盤都由ZFS進行管理。常規RAID在存儲數據時，只按照特定的規則組建池，不關心文件在子設備上的位置。而ZFS在數據存儲時會為每次寫入的數據分配適當大小的空間，並計算得到指向子設備的數據指針。這種特性使得RAIDZ缺盤時無法直接進行校驗得到數據，必須將整個ZPOOL作為一個整體進行解析。
九、追蹤最新數據入口
在ZFS文件系統內每次發生文件系統狀態更新時都會產生新的文件系統入口，所以需要根據其內部記錄的事務塊獲取最新狀態下的入口指針。手工截取事務塊數據，編寫程序獲取最大事務號入口：

獲取到最新狀態的文件系統入口後，編寫數據指針解析程序進行地址解析：

獲取到文件系統入口點在各磁盤分布情況後，開始手工截取並分析文件系統內部結構，入口分布所在的磁盤組無缺失盤，可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到客戶映射的LUN名稱，進而找到其節點。
十、運行提取程序
編輯配置文件，提取ZVOL卷：

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

遇到ZFS文件系統如此棘手的問題，這種辦法簡單又高效！