[資料恢復故障描述]
一臺linux網站伺服器，DELL R200，管理約50個左右網站，使用一塊SATA 160GB硬碟。正常使用中突然當機，嘗試再次啟動失敗，將硬碟拆下檢測時發現存在約100個壞扇區。
某資料恢復公司修復壞道後，嘗試了約3天時間，未恢復成功。
[資料恢復過程]
接到盤後，首先通過PC3K with DE對故障盤進行完整映象操作，在映象中進行資料分析。
整塊硬碟由兩個分割槽組成：100M的boot分割槽及剩餘空間的/分割槽(通過LVM管理)，檔案系統均為EXT3。
根分割槽超級塊正常，根據超級塊檢視第一塊組描述表正常，但節點區全為0。
根據塊組描述表分析其他塊組，發現前27個塊組全部為0，但塊組前後的資料區明顯有使用者資料存在。
中間塊組區後設資料正常(描述表、節點、BITMAP等)
最後部分塊組的後設資料區全部為0。
試圖查詢根目錄，找到。
以根目錄為線索，恢復根目錄節點區，成功。
以生成的根目錄節點區與根目錄記錄生成檔案系統樹，成功後已經可以看到大量資料，檔案系統結構正常。但部分檔案或資料夾的節點為0，通過節點跟蹤，發現節點區位於檔案系統前部分及後部分。
試圖恢復節點區為0的檔案與資料夾，資料夾大部分恢復成功，但檔案大部分無法恢復。
試圖恢復使用者曾做過的.TAR.GZ備份包，恢復成功，但開啟時提示出錯，中間資料被破壞，只能有限匯出部分網站。
最終評估約70%的資料恢復成功。
[資料恢復故障原因推斷]
資料恢復的故障原因往往無法明確得知，此例中僅僅推斷如下：
1、出現壞道後，使用者可能試圖進行自動或手工的fsck操作，導致進一步的災難。
2、以部分塊組全為0看，有可能做過未完成的mkfs。
3、送修的資料恢復公司並不專業，有破壞資料的可能性。
[給使用者的建議]
1、重要的資料一定不要用單盤做儲存環境，目前構架一套簡單的RAID並不需要很大的投入。
2、一定要做好備份工作，最起碼，備份包不要放到同一儲存體上，退而求其次，也一定不要放到同一分割槽下。
3、硬碟出現故障後，一定不要反覆嘗試處理，應儘快做完整備份操作。
4、儘可能選擇專業一點的資料恢復公司進行處理，不專業的公司或個人公司部分做事相當無恥，無意或有意的會對故障盤進行破壞(有意的目的是為了提高報價要挾或維持名聲)。