伺服器掉了兩塊盤，lun丟失的資料恢復方法

伺服器資料恢復故障描述

伺服器內有兩塊硬碟掉線，現在伺服器內的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儲存故障是由磁碟不穩定引起的，而這部分磁碟應該是同一批次的磁碟。因此，這些磁碟的效能也快到極限，如果有條件建議換掉這批磁碟。