伺服器資料恢復環境：
北京某科技大學，某品牌PowerEdge系列某型號伺服器，6塊SAS硬碟組成RAID5；
作業系統REDHAT，檔案系統EXT3，分割槽採用LVM方式，儲存著該大學某研究室運算1年多的重要資料。
伺服器故障&分析：
未知原因導致伺服器崩潰。管理員進入RAID控制介面檢查發現1號盤與6號盤狀態顯示損壞。諮詢伺服器原廠工程師後，管理員強制上線6號盤，結果raid無法啟動（作業系統也安裝於此RAID）。管理員意識到問題嚴重性，馬上停止所有操作。
根據使用者的描述及故障表現，北亞伺服器資料恢復工程師推斷本案例中的RAID5陣列中應該有一塊硬碟早離線，這時候磁碟陣列還能正常工作，後來又有一塊硬碟離線，從而導致RAID陣列崩潰。按照管理員的描述，6號盤早離線，1號盤後離線。
如果上面的推斷屬實，1號盤只要能正常讀取即可恢復全部的資料。但管理員強制上線6號盤，可能會導致檔案系統不一致，引起其他盤的資料發生變更。
經過研究，北亞資料恢復工程師敲定了恢復資料的思路：
首先檢測所有硬碟狀態，分析RAID資訊，剔除掉陳舊資料盤。根據分析出來的RAID資訊重組RAID，讀取資料；或直接以EXT3的模式恢復資料。
伺服器資料恢復過程：
1、伺服器資料恢復工程師拿到故障伺服器硬碟後以只讀方式對所有硬碟做映象備份，使用不含RAID功能的SAS介面卡作為物理連線進行備份。後續資料恢復操作都在備份檔案上進行，避免對資料造成二次傷害。
2、基於映象檔案對RAID結構進行分析，獲取到原始RAID相關資訊。
3、對RAID進行一致性校驗，結果發現大量的不匹配。
4、從6塊盤中剔除掉陳舊盤。但此時發現前部分割槽結構的內容錯誤，應該為強制上線6號盤所導致的問題。
5、修正硬碟結構，將LVM改為普通分割槽指引。
6、透過北亞自主研發軟體解釋EXT3並讀取資料，以SAMBA方式匯出至LINUX EXT3目標分割槽。到此步資料恢復已經完成。
7、經過使用者親自檢測沒有發現問題，協助使用者把資料匯入準備好的環境中，一切正常。