伺服器故障情況簡介：
客戶的一台ibm x3850伺服器上組了乙個raid5磁碟陣列，有兩塊硬碟離線，伺服器崩潰。北亞資料恢復中心工程師對伺服器進行初檢，客戶的磁碟陣列由5塊硬碟組成，linux redhat 5.3作業系統，儲存乙個oracle資料庫。陣列中有兩塊硬碟處於離線狀態，熱備盤未啟用。硬碟無物理故障，無明顯同步表現。
資料恢復方案：
1.關閉伺服器同時確保在恢復過程中不再開啟伺服器，將故障盤進行標記後取出槽位掛載至資料恢復公司的備份伺服器環境進行映象備份。完成後恢復原故障伺服器。
2.分析備份盤中的raid結構，得到原陣列中的raid界別、條帶大小、校驗方向、條帶規則以及meta區域等資訊。
根據分析出來的raid資訊虛擬搭建一組raid5環境對磁碟檔案系統進行解釋，對虛擬結構的正確性檢測，資料無誤即可回遷資料。
伺服器資料恢復及系統復原過程：
1. 對原硬碟映象後發現除了2號盤有10-20個壞扇區外其他硬碟均正常。
2. 對raid結構進行分析，最佳盤序結構是0-1-2-3，缺失3號盤，結構如下圖：
3.組好後資料驗證，200m以上的最新壓縮包解壓無報錯，按照這一結構將虛擬raid生成到一塊硬碟上，通過usb的方式把恢復後的單盤接入原伺服器，通過linux systemrescuecd啟動故障伺服器後使用dd命令進行全盤回寫。
4. 資料回寫完成後無法進入作業系統，報錯資訊為：/etc/rc.d/rc.sysinit:line 1:/sbin/pidof:permission denied。工程師使用systemrescuecd重啟後檢查發現檔案的許可權、時間、大小都有明顯錯誤，對根分割槽再次分析定位出錯的/sbin/pidof/datahf.net，得出問題原因是2號盤壞道。
5. 通過其他盤針對2號盤的損壞區域進行xor補齊並重新校驗檔案系統，依然有錯誤，工程師只好再次對inode表進行檢查，發現2號盤損壞區域有部分節點表現為(圖中的55 55 55部分)：
可以看出雖然節點中描述的uid還正常存在，但大小、屬性、最初的分配塊全部是錯誤的。通過日誌確定原節點塊的節點資訊後進行修正，重新dd根分割槽，執行fsck -fn /dev/sda5/datahf.net檢測，報錯情況如下圖：
經過分析發現，原來3號盤最先離線，節點資訊新舊交集導致有多個節點共用資料塊，工程師按節點所屬的檔案進行區別，清除錯誤節點後，再次執行fsck -fn /dev/sda5,依然有部分位於doc目錄下的節點報錯，由於不影響啟動所以強行修復後重啟系統，系統正常，啟動資料庫正常。此次資料恢復工作成功。
raid5因兩塊硬碟掉線導致的資料丟失恢復過程分享
全文鏈結 1.故障描述 本案例是hp p2000的儲存vmware exsi虛擬化平台，由raid 5由10塊lt硬碟組成，其中6號盤是熱備盤，由於故障導致raid 5磁碟陣列的兩塊盤掉線，表現為兩塊硬碟亮黃燈。經使用者方維護人員檢測，故障硬碟應為物理故障，表現為 序列號無法讀取，在sas擴充套件卡...
RAID5當一塊硬碟離線後處理
raid5當一塊硬碟離線後，處理降級狀態，這時候正常的建議是馬上更換硬碟做 rebuild 以恢復完整的資料狀態，如果有熱備盤的話，就會自動做 rebuild 這樣做合適嗎？一組raid卷在工作很長時間以後也很少會讀到物理硬碟的所有磁碟空間，同一時間更是不可能。部分情況下，硬碟會在沒有讀到的區域或者...
公司linux伺服器raid5陣列癱瘓資料恢復過程
服務作業系統 linux伺服器 伺服器型號 某品牌x3850伺服器 硬碟數量 介面型別 4塊 sas介面 陣列級別 raid5磁碟陣列 故障情況 伺服器突然癱瘓 操作情況 伺服器癱瘓後原系統進行了重新安裝，需要恢復的資料型別 資料庫 辦公文件 檔案等 工程師對客戶的伺服器進行了檢測，經過檢測發現由於...