某省雲資料中心資料恢複報告一、故障描述二、備份資料三、故障分析四、重組RAID五、驗證資料六、恢複資料七、移交資料八、資料恢複總結 九、項目成員

機房突然斷電導緻整個存儲癱瘓，加電後存儲依然無法使用。經過使用者方工程師診斷後認為是斷電導緻存儲陣列損壞。整個存儲是由12塊日立硬碟（3T SAS硬碟）組成的RAID-6磁盤陣列，被分成一個卷，配置設定給幾台Vmware的ESXI主機做共享存儲。整個卷中存放了大量的Windows虛拟機，虛拟機基本都是模闆建立的，是以系統盤都統一為160G。資料盤大小不确定，并且資料盤都是精簡模式。

将故障存儲的所有磁盤和備份資料的目标磁盤連入到一台Windows Server 2008的伺服器上。故障磁盤都設為脫機（隻讀）狀态，在專業工具WinHex下看到連接配接狀态如下圖所示：(圖中HD1-HD12為目标備份磁盤，HD13-HD24為源故障磁盤，型号為HUS723030ALS640)：

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

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

1、  損壞扇區分布以256個扇區為機關。

2、  除損壞扇區片斷的起始位置不固定外，後面的損壞扇區都是以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

 臨時寫了個小程式，對每個磁盤的損壞扇區做繞過處理。用此程式鏡像完所有盤的資料。

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

1、  每段損壞扇區區域大小總為256。

2、  損壞扇區分布為固定區域，每跳過11個256扇區遇到一個壞的256扇區。

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

4、  所有硬碟中隻有10号盤中有一個自然壞道。

對HD13、HD23、HD24的0-2扇區做分析，可知分區大小為52735352798扇區，此大小按RAID-6的模式計算，除以9，等于5859483644扇區，與實體硬碟大小1049524，和DS800控制器中保留的RAID資訊區域大小吻合；同時根據實體硬碟底層表現，分區表大小為512位元組，後面無8位元組校驗，大量的0扇區也無8位元組校驗。故可知，原存儲并未啟用存儲中常用的DA技術(520位元組扇區）。

分區大小如下圖(GPT分區表項底層表現，塗色部分表示分區大小，機關512位元組扇區，64bit)：

<a href="http://s3.51cto.com/wyfs02/M02/54/3A/wKiom1R8hICQDp37AAIg2TNnZ8E713.jpg" target="_blank"></a>

存儲使用的是标準的RAID-6陣列，接下來隻需要分析出RAID 成員數量以及RAID的走向就可以重組RAID。

1、  分析RAID條帶大小

整個存儲被分成一個大的卷，配置設定給幾台ESXI做共享存儲，是以卷的檔案系統肯定是VMFS檔案系統。而VMFS卷中又有存放了大量的Windows 虛拟機。Windows虛拟機中大多使用的是NTFS檔案系統，是以可以根據NTFS中的MFT的順序分析出RAID條帶的大小以及RAID的走向。

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

鏡像完所有磁盤。後發現最後一塊硬碟中并沒有像其他硬碟一樣有大量的壞道。其中有大量未損壞扇區，這些未損壞扇區大多是全0扇區。是以可以判斷這塊硬碟是熱備盤。

根據分析出來的RAID結構重組RAID，能看到目錄結構。但是不确定是否為最新狀态，檢測幾個虛拟機發現有部分虛拟機正常，但也有很多虛拟機資料異常。初步判斷RAID中存在掉線的磁盤，依次将RAID中的每一塊磁盤踢掉，然後檢視剛才資料異常的地方，未果。又仔細分析底層資料發現問題不是出在RAID層面，而是出在VMFS檔案系統上。VMFS檔案系統如果大于16TB的話會存在一些其他的記錄資訊，是以在組建RAID的時候需要跳過這些記錄資訊。再次重組RAID，檢視以前資料異常的地方可以對上了。針對其中的一台虛拟機做驗證，将所有磁盤加入RIAD中後，這台虛拟機是可以啟動的，但缺盤的情況下啟動有問題。是以判斷整個RAID處在不缺盤的狀态為最佳。

針對使用者較為重要的虛拟機做驗證，發現虛拟機大多都可以開機，可以進入登陸界面。有部分虛拟機開機藍屏或開機檢測磁盤，但是CD光牒修複之後都可以啟動。

部分虛拟機現象開機如下：

針對重要的虛拟機中的資料庫做驗證，發現資料庫都正常。其中有一個資料庫，據使用者描述是缺少部分資料，但是經過仔細核對後發現這些資料在資料庫中本來就不存在。通過查詢 master 資料庫中的系統視圖，查出原來的所有資料庫資訊如下：

由于虛拟機的數量很多，每台都驗證的話，所需的時間會很長，是以我們對整個VMFS卷做檢測。在檢測VMFS卷的過程中發現有部分虛拟機或虛拟機的檔案被破壞。清單如下：’

<a href="http://s3.51cto.com/wyfs02/M02/54/3A/wKiom1R8hseRYdUQAASO69tyCAM380.jpg" target="_blank"></a>

北亞工程師跟客戶溝通并且描述了目前恢複的情況。使用者經過對幾台重要的虛拟機驗證後，使用者反應恢複的資料可以接受，接着北亞工程師立即着手準備恢複所有資料。

先準備目标磁盤，使用一台dell 的MD 1200加上11塊3T的硬碟組成一個RAID陣列。接着将重組的RAID資料鏡像到目标陣列上。然後利用專業的工具UFS解析整個VMFS檔案系統。

将恢複好的VMFS卷連接配接到我們的虛拟化環境中的一台ESXI5.5主機上，嘗試将其挂載到的ESXI5.5的環境中。但是由于版本（客戶的ESXI主機是5.0版本）原因或VMFS本身有損壞，導緻其挂載不成功。繼續嘗試使用ESXI的指令挂載也不成功，于是放棄挂載VMFS卷。

由于時間緊迫，先安排北亞工程師将MD 1200 陣列上的資料帶到使用者現場。然後使用專業工具”UFS”依次導出VMFS卷中的虛拟機。

1、  将MD 1200陣列上的資料通過HBA卡連接配接到使用者的VCenter伺服器上。

2、  在VCenter伺服器安裝“UFS”工具，然後使用“UFS”工具解釋VMFS卷。

3、  使用“UFS”工具将VMFS卷中的虛拟機導入到VCenter伺服器上。

4、  使用VCenter的上傳功能将虛拟機上傳到ESXI的存儲中。

5、  接着将上傳完的虛拟機添加到清單，開機驗證即可。

6、  如果有虛拟機開機有問題，則嘗試使用指令行模式修複。或者重建虛拟機并将恢複的虛拟機磁盤（既VMDK檔案）拷貝過去。

7、  由于部分虛拟機的資料盤很大，而資料很少。像這種情況就可以直接導出資料，然後建立一個虛拟磁盤，最後将導出的資料拷貝至建立的虛拟磁盤中即可。

統計了一下整個存儲中虛拟機的數量，大約有200台虛拟機。目前的情況隻能通過上述方式将恢複的虛拟機一台一台的恢複到使用者的ESXI中。由于是通過網絡傳輸，是以整個遷移的過程中網絡是一個瓶頸。經過不斷的調試以及更換主機最終還是無法達到一個理想的狀态，由于時間緊張，最終還是決定在目前的環境遷移資料。

所有磁盤壞道的規律如下表：

損壞扇區域（256SEC）分布規則

位置

備注

5376+N*2816

2304+N*2816

2048+N*2816

1792+N*2816

1536+N*2816

1280+N*2816

1024+N*2816

768+N*2816

512+N*2816

256+N*2816

5632+N*2816

98724塊區有一自然損壞扇區

經過仔細分析後得出壞道的結論如下：

1、  除去SN：YHJ6LEUD上的一個自然壞道外，其餘壞道均分布于RAID-6的Q校驗塊中。

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

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

4、  其他非Q校驗區域完好，無任何故障。

結論：

通常情況，經如上壞道規則表現可推斷，壞道為控制器生成Q校驗，向硬碟下達IO指令時，可能表現為非标指令，硬碟内部處理異常，導緻出現規律性壞道。

資料恢複過程中由于壞道數量太多，以緻備份資料時花費了很長世間。整個存儲是由壞道引起的，導緻最終恢複的資料有部分破壞，但不影響整體資料，最終的結果也在可接受範圍内。

整個恢複過程，使用者方要求緊急，我方也安排工程師加班加點，最終在最短的時間内将資料恢複出來。後續的資料遷移過程中由我方工程師和使用者方工程師配合完成。

姓名

職務

電話

EMAIL

張曉娜

商務代表

13161737074

張宇

項目主管

18600440055

鄧奇

存儲恢複工程師

　

秦穎吉

虛拟化工程師

張勇

資料庫工程師

劉思棋

硬碟工程師

陳琳娜

項目記錄

本文轉自 張宇 51CTO部落格，原文連結：http://blog.51cto.com/zhangyu/1585274，如需轉載請自行聯系原作者