伺服器硬碟掉線解決過程分析

伺服器資料恢複故障描述

伺服器内有兩塊硬碟掉線，現在伺服器内的lun丢失了，資料恢複工程師開始對故障伺服器進行檢測發現掉線的硬碟并沒有存在實體故障、也沒有壞道等其他故障。于是開始對客戶的故障伺服器進行鏡像備份。

伺服器故障原因分析：

本次需要進行資料恢複的伺服器沒有硬碟故障，是以硬碟掉線的原因可能是因為硬碟讀寫不穩定導緻的，硬碟讀寫不穩定将被控制器預設為是壞盤踢出，掉線的硬碟超過了2塊後就會導緻伺服器不可用，此時不能通過正常方式進行修複，隻能通過伺服器資料恢複手段進行資料恢複。通過分析該伺服器内的raid條目存儲形式，每個硬碟的不同塊組成一個raid條目，伺服器資料恢複工程師通過分析解析出來raid條目資訊，每個LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盤中，使用一個索引來指定其位置。是以去每個磁盤中找這個指向LUN_MAP的索引就可以找到現存LUN的資訊了。

伺服器資料恢複過程

通過故障分析硬碟是因為性能原因掉線，這些掉線的硬碟中有一部分資料是老舊資料，由于LUN的RAID結構大多都是RAID5，隻需要将一個LUN的RAID條目通過RAID5的校驗算法算出校驗值，再和原有的校驗值做比較就可以判斷這個條目中是否有掉線盤。而将一個LUN的所有LUN_MAP都校驗一遍就可以知道這個LUN中哪些RAID條目中有掉線盤。而這些RAID條目中都存在的那個盤就一定是掉線盤。排除掉線盤，然後根據LUN_MAP恢複所有LUN的資料即可。

上述的故障分析以及解決思路最終都需要使用程式設計來實作。編寫掃描LUN_MAP的程式Scan_Map.exe，掃描全部LUN_MAP，結合人工分析得出最精确的LUN_MAP。編寫檢測RAID條目的程式Chk_Raid.exe，檢測所有LUN中掉線的磁盤，結合人工分析排除掉線的磁盤。編寫LUN資料恢複程式Lun_Recovery.exe，結合LUN_MAP恢複所有LUN資料。根據編寫好的程式去實作不同的功能，最後使用Lun_Recovery.exe結合LUN_MAP恢複所有LUN的資料。然後人工核對每個LUN，确認是否和甲方工程師描述的一緻。

伺服器資料恢複資料驗證

根據甲方工程師描述所有LUN的資料可以分成兩大部份，一部份是Vmware的虛拟機，一部分是HP-UX上的裸裝置，裸裝置裡存放的是Oracle的dbf資料庫。由于我們恢複的是LUN，無法看到裡面的檔案，是以需要将這些LUN同過人工的核對哪些LUN是存放Vmware的資料，哪些是HP-UX的裸裝置。然後将LUN挂載到不同的驗證環境中驗證恢複的資料是否完整。

在一台dell的伺服器上安裝了ESXI5.5虛拟主機環境，然後通過iSCSI的方式将恢複的LUN挂載到虛拟主機上。但是在VMware vSphere Client?上掃描vmfs卷，沒有發現。後來發現客戶的虛拟主機是EXSI3.5的版本。可能因為版本的原因無法直接掃描到vmfs卷，于是換一種驗證方式。将所有符合vmware虛拟機的LUN裡面的虛拟機檔案都生成出來，然後通過NFS共享的方式挂載到虛拟主機上，然後将虛拟機一個一個的添加到清單。

驗證vmfs虛拟機

通過NFS将所有虛拟機都添加到虛拟主機以後，将所有虛拟機都加電開機，發現都能啟動系統。由于沒有開機密碼無法确認虛拟機裡面的檔案是否完整。後來甲方安排工程師通過遠端到我們的伺服器，将所有虛拟機都開機進入系統，驗證虛拟機裡面的資料都沒問題。虛拟機的所有資料都恢複成功。

日後資料安全建議

1、安排員工經常巡視機房，發現有報警資訊及時處理。

2、管理人員操作存儲要謹慎，避免誤操作導緻資料丢失。

3、現場發現EVA控制器部分子產品不太穩定，應當及時更換。

4、由于EVA存儲故障是由磁盤不穩定引起的，而這部分磁盤應該是同一批次的磁盤。是以，這些磁盤的性能也快到極限，如果有條件建議換掉這批磁盤。