某省雲數據中心數據恢復報告

 

1、故障描述

機房忽然斷電致使整個存儲癱瘓，加電後存儲依然沒法使用。通過用戶方工程師診斷後認爲是斷電致使存儲陣列損壞。整個存儲是由12塊日立硬盤（3T SAS硬盤）組成的RAID-6磁盤陣列，被分紅一個卷，分配給幾臺Vmware的ESXI主機作共享存儲。整個卷中存放了大量的Windows虛擬機，虛擬機基本都是模板建立的，所以系統盤都統一爲160G。數據盤大小不肯定，而且數據盤都是精簡模式。

 

2、備份數據

將故障存儲的全部磁盤和備份數據的目標磁盤連入到一臺Windows Server 2008的服務器上。故障磁盤都設爲脫機（只讀）狀態，在專業工具WinHex下看到鏈接狀態以下圖所示：(圖中HD1-HD12爲目標備份磁盤，HD13-HD24爲源故障磁盤，型號爲HUS723030ALS640)：

 

 

 

    使用WinHex 對HD13-HD24以底層方式讀取扇區，發現了大量損壞扇區。初步判斷多是這種硬盤的讀取機制與常見的硬盤不同。嘗試更換操做主機，更換HBA卡，更換擴展櫃，更換爲Linux操做系統，均呈現相同故障。與用戶方工程師聯繫，對方迴應此控制器對磁盤沒有特殊要求。

   使用專業工具對硬盤損壞扇區的分佈規律進行檢測，發現以下規則：

一、  損壞扇區分佈以256個扇區爲單位。

二、  除損壞扇區片段的起始位置不固定外，後面的損壞扇區都是以2816個扇區爲間隔。

全部磁盤的損壞扇區分佈以下表（只列出前3個損壞扇區）：

ID號	硬盤序列號	第1個損壞扇區	第2個損壞扇區	第3個損壞扇區
13	YHJ7L3DD	5376	8192	11008
14	YHJ6YW9D	2304	5120	7936
15	YHJ7M77D	2048	4864	7680
16	YHJ4M5AD	1792	4608	7424
17	YHJ4MERD	1536	4352	7168
18	YHJ4MH9D	1280	6912	9728
19	YHJ7JYYD	1024	6656	9472
20	YHJ4MHMD	768	6400	9216
21	YHJ7M4YD	512	6144	8960
22	YHJ632UD	256	5888	8704
23	YHJ6LEUD	5632	8448	11264
24	YHHLDLRA	256	5888	8704

 臨時寫了個小程序，對每一個磁盤的損壞扇區作繞過處理。用此程序鏡像完全部盤的數據。

 

3、故障分析

1、分析損壞扇區

仔細分析損壞扇區發現，損壞扇區呈規律性出現。

一、  每段損壞扇區區域大小總爲256。

二、  損壞扇區分佈爲固定區域，每跳過11個256扇區遇到一個壞的256扇區。

三、  損壞扇區的位置一直存在於RAID的P校驗或Q校驗區域。

四、  全部硬盤中只有10號盤中有一個天然壞道。

 

2、分析分區大小

對HD1三、HD2三、HD24的0-2扇區作分析，可知分區大小爲52735352798扇區，此大小按RAID-6的模式計算，除以9，等於5859483644扇區，與物理硬盤大小1049524，和DS800控制器中保留的RAID信息區域大小吻合；同時根據物理硬盤底層表現，分區表大小爲512字節，後面無8字節校驗，大量的0扇區也無8字節校驗。故可知，原存儲並未啓用存儲中經常使用的DA技術(520字節扇區）。

分區大小以下圖(GPT分區表項底層表現，塗色部分表示分區大小，單位512字節扇區，64bit)：

4、重組RAID

1、分析RAID結構

存儲使用的是標準的RAID-6陣列，接下來只須要分析出RAID 成員數量以及RAID的走向就能夠重組RAID。

一、  分析RAID條帶大小

整個存儲被分紅一個大的卷，分配給幾臺ESXI作共享存儲，所以卷的文件系統確定是VMFS文件系統。而VMFS卷中又有存放了大量的Windows 虛擬機。Windows虛擬機中大多使用的是NTFS文件系統，所以能夠根據NTFS中的MFT的順序分析出RAID條帶的大小以及RAID的走向。

二、  分析RAID是否存在掉線盤

鏡像完全部磁盤。後發現最後一塊硬盤中並無像其餘硬盤同樣有大量的壞道。其中有大量未損壞扇區，這些未損壞扇區大可能是全0扇區。所以能夠判斷這塊硬盤是熱備盤。

 

2、重組RAID

根據分析出來的RAID結構重組RAID，能看到目錄結構。可是不肯定是否爲最新狀態，檢測幾個虛擬機發現有部分虛擬機正常，但也有不少虛擬機數據異常。初步判斷RAID中存在掉線的磁盤，依次將RAID中的每一塊磁盤踢掉，而後查看剛纔數據異常的地方，未果。又仔細分析底層數據發現問題不是出在RAID層面，而是出在VMFS文件系統上。VMFS文件系統若是大於16TB的話會存在一些其餘的記錄信息，所以在組建RAID的時候須要跳過這些記錄信息。再次重組RAID，查看之前數據異常的地方能夠對上了。針對其中的一臺虛擬機作驗證，將全部磁盤加入RIAD中後，這臺虛擬機是能夠啓動的，但缺盤的狀況下啓動有問題。所以判斷整個RAID處在不缺盤的狀態爲最佳。

5、驗證數據

1、驗證虛擬機

針對用戶較爲重要的虛擬機作驗證，發現虛擬機大多均可以開機，能夠進入登錄界面。有部分虛擬機開機藍屏或開機檢測磁盤，可是光盤修復以後均可以啓動。

部分虛擬機現象開機以下：

2、驗證數據庫

針對重要的虛擬機中的數據庫作驗證，發現數據庫都正常。其中有一個數據庫，據用戶描述是缺乏部分數據，可是通過仔細覈對後發現這些數據在數據庫中原本就不存在。經過查詢 master 數據庫中的系統視圖，查出原來的全部數據庫信息以下：

 

3、檢測整個VMFS卷是否完整

因爲虛擬機的數量不少，每臺都驗證的話，所需的時間會很長，所以咱們對整個VMFS卷作檢測。在檢測VMFS卷的過程當中發現有部分虛擬機或虛擬機的文件被破壞。列表以下：’

 

6、恢復數據

1、生成數據

北亞工程師跟客戶溝通而且描述了目前恢復的狀況。用戶通過對幾臺重要的虛擬機驗證後，用戶反應恢復的數據能夠接受，接着北亞工程師當即着手準備恢復全部數據。

先準備目標磁盤，使用一臺dell 的MD 1200加上11塊3T的硬盤組成一個RAID陣列。接着將重組的RAID數據鏡像到目標陣列上。而後利用專業的工具UFS解析整個VMFS文件系統。

2、嘗試掛載恢復的VMFS卷

將恢復好的VMFS卷鏈接到咱們的虛擬化環境中的一臺ESXI5.5主機上，嘗試將其掛載到的ESXI5.5的環境中。可是因爲版本（客戶的ESXI主機是5.0版本）緣由或VMFS自己有損壞，致使其掛載不成功。繼續嘗試使用ESXI的命令掛載也不成功，因而放棄掛載VMFS卷。

7、移交數據

因爲時間緊迫，先安排北亞工程師將MD 1200 陣列上的數據帶到用戶現場。而後使用專業工具」UFS」依次導出VMFS卷中的虛擬機。

一、  將MD 1200陣列上的數據經過HBA卡鏈接到用戶的VCenter服務器上。

二、  在VCenter服務器安裝「UFS」工具，而後使用「UFS」工具解釋VMFS卷。

三、  使用「UFS」工具將VMFS卷中的虛擬機導入到VCenter服務器上。

四、  使用VCenter的上傳功能將虛擬機上傳到ESXI的存儲中。

五、  接着將上傳完的虛擬機添加到清單，開機驗證便可。

六、  若是有虛擬機開機有問題，則嘗試使用命令行模式修復。或者重建虛擬機並將恢復的虛擬機磁盤（既VMDK文件）拷貝過去。

七、  因爲部分虛擬機的數據盤很大，而數據不多。像這種狀況就能夠直接導出數據，而後新建一個虛擬磁盤，最後將導出的數據拷貝至新建的虛擬磁盤中便可。

 

統計了一下整個存儲中虛擬機的數量，大約有200臺虛擬機。目前的狀況只能經過上述方式將恢復的虛擬機一臺一臺的恢復到用戶的ESXI中。因爲是經過網絡傳輸，所以整個遷移的過程當中網絡是一個瓶頸。通過不斷的調試以及更換主機最終仍是沒法達到一個理想的狀態，因爲時間緊張，最終仍是決定在當前的環境遷移數據。

8、數據恢復總結

1、故障總結

全部磁盤壞道的規律以下表：

 

ID號	硬盤序列號	損壞扇區域（256SEC）分佈規則
		位置	備註
13	YHJ7L3DD	5376+N*2816
14	YHJ6YW9D	2304+N*2816
15	YHJ7M77D	2048+N*2816
16	YHJ4M5AD	1792+N*2816
17	YHJ4MERD	1536+N*2816
18	YHJ4MH9D	1280+N*2816
19	YHJ7JYYD	1024+N*2816
20	YHJ4MHMD	768+N*2816
21	YHJ7M4YD	512+N*2816
22	YHJ632UD	256+N*2816
23	YHJ6LEUD	5632+N*2816	98724塊區有一天然損壞扇區
24	YHHLDLRA	256+N*2816

 

通過仔細分析後得出壞道的結論以下：

一、  除去SN：YHJ6LEUD上的一個天然壞道外，其他壞道均分佈於RAID-6的Q校驗塊中。

二、  壞道區域多數表現爲完整的256個扇區，正好當時建立RAID-6時的一個完整RAID塊大小。

三、  活動區域表現爲壞道，非活動區域壞道有可能不出現，如熱備盤，上線不足10%，壞道數量就比其餘在線盤少（熱備盤的鏡像4小時完成，其餘有壞道盤大概花費40小時）

四、  其餘非Q校驗區域無缺，無任何故障。

 

結論：

一般狀況，經如上壞道規則表現可推斷，壞道爲控制器生成Q校驗，向硬盤下達IO指令時，可能表現爲非標指令，硬盤內部處理異常，致使出現規律性壞道。

 

2、數據恢復總結

數據恢復過程當中因爲壞道數量太多，以至備份數據時花費了很長世間。整個存儲是由壞道引發的，致使最終恢復的數據有部分破壞，但不影響總體數據，最終的結果也在可接受範圍內。

整個恢復過程，用戶方要求緊急，我方也安排工程師加班加點，最終在最短的時間內將數據恢復出來。後續的數據遷移過程當中由我方工程師和用戶方工程師配合完成。

 

9、項目成員 

姓名	職務	電話	EMAIL
張曉娜	商務表明	13161737074
張宇	項目主管	18600440055
鄧奇	存儲恢復工程師
秦穎吉	虛擬化工程師
張勇	數據庫工程師
劉思棋	硬盤工程師
陳琳娜	項目記錄

 

 

 

 

 

                         北京北亞時代科技股份有限公司

                                               2014年11月26日