一、服務器數據恢復故障描述
介紹數據恢復案例前照例先介紹故障服務器的物理狀況。本次數據恢復的服務器是linux操作系統，某品牌730系列服務器，MD3200系列存儲。導致數據丟失的原因是機房意外斷電導致系統無法正常啓動，客戶管理員對無法訪問的服務器進行了修復操作後進入系統查看數據，服務器部分文件已經丟失。於是客戶管理員聯繫了數據恢復中心進行服務器數據恢復。
二、服務器數據恢復故障分析
1.備份客戶服務器數據
數據恢復工程師接到客戶的服務器後對服務器進行了初檢，首先將存儲的lun以只讀的模式映射到了數據恢復中心的數據恢復專用存儲設備上。接着對客戶的服務器進行扇區級別的鏡像操作，這樣做的目的有兩個，一個是可以讓客戶取回原服務器，避免後期的數據恢復過程佔用客戶設備，另一個是爲了保護客戶的原有數據，因爲數據恢復需要大量的數據分析和嘗試，存在有多次嘗試的可能，這樣在鏡像文件中進行數據恢復操作就可以避免在客戶的原服務器上進行操作，保護客戶原數據的完整性。萬一我們恢復失敗了，客戶也可以攜帶原服務器到其他公司進行數據恢復操作，是一種對客戶數據負責的方式。
2、分析服務器故障原因
備份完成後，服務器數據恢復工程師對底層數據進行查看，發現服務器的目錄項已經遭到了破壞，所幸運的是這些目錄項的破壞並沒影響到服務器的重要數據，僅僅是將目錄項破壞了一些，這些破壞可以通過人工進行修復。由於客戶的服務器管理員進行過修復操作，這也就導致了損壞的目錄項本質上並沒有被成功修復，而是以節點號進行命名同時存放到了lost+found文件夾內，對應的數據區索引也被服務器進行了自動清除。工程師以前處理過很多起類似的數據丟失案例，這種情況下只需要根據文件系統和文件類型在自由空間中進行碎片匹配、碎片拼合，最終恢復整個服務器的數據。
三、服務器數據恢復實施過程
在本次數據恢復案例中的節點信息已經被清除，無法根據節點信息還原數據。服務器數據恢復工程師提取出lost+found文件夾下的文件名稱，根據丟失文件的文件目錄項節點號進行一一匹配，從而分析出丟失的目錄結構。再繼續分析底層數據，根據文件系統的結構信息在底層空間的相對應位置掃描符合丟失目錄結構條件的信息並進行提取，再與目錄項節點號進行整合，把掃描到的目錄項節點號記錄到數據庫裏面，之後在通過lost+found裏面的文件記錄號和數據庫裏面的記錄號進行匹配。
四、服務器數據恢復結果
在本次服務器數據恢復案例中，客戶的服務器先是異常斷電導致文件系統被損壞，接着被管理員進行了人人工修復導致大量文件的目錄結構丟失，在修復和檢查過程中服務器還寫入了一部分的新數據，這就直接導致了本次服務器數據恢復的過程比正常情況下的數據丟失更爲複雜一些，由於工程師有着多年的服務器數據恢復經驗，在經過一段時間的分析和重組後，最終成功提取出了客戶服務器丟失的數據。客戶對恢復成功的數據進行驗證，經過驗證，客戶原服務器內的所有數據都恢復成功，可以正常使用，客戶認可本次服務器數據恢復結果。