本次分享的案例是由于機房突然斷電導緻整個存儲癱瘓，加電後存儲依然無法使用。經過用戶方工程師診斷後認為是斷電導緻存儲陣列損壞。整個存儲是由12塊盤組成的RAID-6磁盤陣列，被分成一個卷，分配給幾台Vmware的ESXI主機做共享存儲。整個卷中存放了大量的Windows虛拟機，虛拟機基本都是模闆創建的，系統盤都為統一大小，數據盤大小不确定，并且數據盤都是精簡模式。

将故障存儲的所有磁盤和備份sss數據的目标磁盤連入到一台Windows Server 2008的服務器上。以底層方式讀取扇區，發現了大量損壞扇區。初步判斷可能是這種硬盤的讀取機制與常見的硬盤不一樣。嘗試更換操作主機，更換HBA卡，更換擴展櫃，更換為Linux操作系統，均呈現相同故障。跟用戶溝通了解到控制器對磁盤沒有特殊要求。使用專業工具對硬盤損壞扇區的分布規律進行檢測，發現損壞扇區分布以256個扇區為單位，除損壞扇區片段的起始位置不固定外，後面的損壞扇區都是以2816個扇區為間隔。臨時寫了個小程序，對每個磁盤的損壞扇區做繞過處理，用此程序鏡像完所有盤的數據。

【分析故障情況】對損壞扇區進行分析，分析後發現，損壞扇區呈規律性出現。每段損壞扇區區域大小總為256；損壞扇區分布為固定區域，每跳過11個256扇區遇到一個壞的256扇區；損壞扇區的位置一直存在于RAID的P校驗或Q校驗區域，所有硬盤中隻有10号盤中有一個自然壞道。

【RAID重組】1、分析RAID結構：存儲使用的是标準的RAID-6陣列，接下來隻需要分析出RAID 成員數量以及RAID的走向就可以重組RAID。2、分析RAID條帶大小：整個存儲被分成一個大的卷，分配給幾台ESXI做共享存儲，因此卷的文件系統肯定是VMFS文件系統。而VMFS卷中又有存放了大量的Windows 虛拟機。Windows虛拟機中大多使用的是NTFS文件系統，因此可以根據NTFS中的MFT的順序分析出RAID條帶的大小以及RAID的走向。3、分析RAID是否存在掉線盤：鏡像完所有磁盤。後發現最後一塊硬盤中并沒有像其他硬盤一樣有大量的壞道。其中有大量未損壞扇區，這些未損壞扇區大多是全0扇區。因此可以判斷這塊硬盤是熱備盤。4、重組RAID根據分析出來的RAID結構重組RAID，能看到目錄結構。但是不确定是否為最新狀态，檢測幾個虛拟機發現有部分虛拟機正常，但也有很多虛拟機數據異常。初步判斷RAID中存在掉線的磁盤，依次将RAID中的每一塊磁盤踢掉，然後查看剛才數據異常的地方，未果。又仔細分析底層數據發現問題不是出在RAID層面，而是出在VMFS文件系統上。VMFS文件系統如果大于16TB的話會存在一些其他的記錄信息，因此在組建RAID的時候需要跳過這些記錄信息。再次重組RAID，查看以前數據異常的地方可以對上了。針對其中的一台虛拟機做驗證，将所有磁盤加入RAID中後，這台虛拟機是可以啟動的，但缺盤的情況下啟動有問題。因此判斷整個RAID處在不缺盤的狀态為最佳。

【數據驗證及結果】針對用戶較為重要的虛拟機做驗證，發現虛拟機大多都可以開機，可以進入登陸界面。有部分虛拟機開機藍屏或開機檢測磁盤，但是光盤修複之後都可以啟動。針對重要的虛拟機中的數據庫做驗證，發現數據庫都正常。檢測整個VMFS卷是否完整由于虛拟機的數量很多，每台都驗證的話，所需的時間會很長，用戶對部分較為重要的虛拟機進行了驗證，用戶對驗證結果還是比較滿意的。由于部分虛拟機的數據盤很大，而數據很少。像這種情況就可以直接導出數據，然後新建一個虛拟磁盤，最後将導出的數據拷貝至新建的虛拟磁盤中即可。統計了一下整個存儲中虛拟機的數量，大約有200台虛拟機。目前的情況隻能通過上述方式将恢複的虛拟機一台一台地恢複到用戶的ESXI中。由于是通過網絡傳輸，因此整個遷移的過程中網絡是一個瓶頸。經過不斷的調試以及更換主機最終還是無法達到一個理想的狀态，由于時間緊張，最終還是決定在當前的環境遷移數據。整個恢複過程，用戶方要求緊急，我方也安排工程師加班加點，最終在最短的時間内将數據恢複出來。後續的數據遷移過程中由我方工程師和用戶方工程師配合完成，本次數據恢複圓滿成功。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!