[數據恢復故障描述]
新疆某政府機構，MS SQL SERVER服務器，硬件環境爲：IBM X225，由4塊73G SCSI硬盤組成RAID5，RAID中只劃分了一個邏輯卷。操作系統爲WINDOWS 2003。
A、之前未發現故障，直至服務器癱瘓，再查服務器時，發現有3塊硬盤離線。
B、隨便強制上線2塊硬盤後，無法啓動操作系統。
C、使用WINPE光盤啓動操作系統後，可以看到數據，將備份好的ZIP數據庫文件拷貝到移動硬盤上。
D、ZIP文件在另外的機器上測試，無法正確解壓。
E、請對應維保公司幫助恢復。
F、其維保公司更換了一塊新的RAID卡，直接重建成了一組RAID5。
G、客戶認爲ZIP文件大小、名稱都正確，應該可以修好，所以直接先在RAID上重裝了系統並正常工作，同時試圖修復ZIP文件，嘗試了1天后，沒有結果。這時，向數據恢復公司尋求幫助。
[數據恢復結論]
與以往我敘述的數據恢復安全不同，我直接說數據恢復的最後結論：
因數據破壞嚴重，數據最終無法按客戶要求恢復。
[案例分析]
針對上面的故障描述作如下分析：
故障描述A中，在使用RAID5做存儲時，一定要及時維護RAID的正常狀態，當RAID5一塊硬盤掉線後，要及時備份數據到另外的存儲體上，再及時REBUILD故障RAID。
故障描述B中，RAID5存在2塊以上硬盤離線時，一定要可以隨意選擇硬盤上線，如果選擇錯了，有些情況下，一啓動系統，整個RAID的狀態就會改變，有可能會破壞重要數據。參考《RAID損壞後，我們該如何緊急應對？》
故障描述C中，用PE可以看到目錄是因爲目錄區正常或部分正常，並不見得數據區正常，其實系統無法啓動就意味着強制上線的操作是錯誤的，不應該繼續下去。在PE裏讀到目錄，實際上已經對文件系統進行了載入，已經破壞了正常文件系統的元數據區(只是有可能破壞的不影響要恢復的數據)
故障描述D中，ZIP文件無法解壓即意味着RAID結構是錯誤的，實際上強制上線了2塊盤(這時候有3塊盤在線，僅有一塊盤離線)，但這3塊盤裏有一塊是早就離線了的，所以合起來的數據是新鮮與陳舊的混合在一起的，雖然目錄是正確的，但數據區是混亂的。這時候並未對這3塊硬盤有全面的數據同步，基本還是可以完整恢復的。
故障描述E中，如果和維保公司簽訂協議中確定有數據恢復的項目，可以讓其代爲處理(但最好還是諮詢幾家專業的數據恢復公司，確定一下處理方式)。如果維保公司並無數據恢復的服務範圍，最好直接選擇數據恢復公司。大多數情況下，如果客戶直接找維保公司，維保公司再找數據恢復公司，可能會導致費用增加(有時候大得可怕)，同時對數據安全、數據恢復流程的規範方面無法直接控制。
故障描述F中，重建RAID5是此例中最致命的操作。IBM X225使用SERVER RAID SUPPORT CD重建RAID時，默認會清0所有數據。即使是其它服務器，重建RAID時一般也會重新同步校驗，也會打亂原來的數據結構。但這個過程全部完成需要一段時間，如果沒完成，可能剩餘部分數據還有機會恢復。
故障描述G中，經過了一天，73G的RAID成員盤都已經同步完成了。數據完全毀掉了。