您好,登錄后才能下訂單哦!
今天介紹一個服務器數據恢復案例,通過今天這個案例主要介紹一下服務器在分區不能掛載的情況下怎么樣將服務器內的數據進行完整恢復,對于沒有備份的服務器數據恢復具有一定的幫助。下面簡單介紹一下案例中的服務器具體故障情況:
本次需要數據恢復的服務器是一臺某品牌730系列服務器,存儲陣列型號為MD3200,系列存儲,分配lun容量為8TB,操作系統版本是linux centos 7,采用了EXT4文件系統。由于未知原因服務器在運行過程中突然關機且無法啟動,服務器管理員進行修復后可以啟動服務器,但服務器內原來的分區無法掛載。管理員對不能掛載的分區進行fsck修復并掛載查看數據情況,發現部分文件丟失。由于該服務器內存儲了大量的重要數據,管理員決定尋求數據恢復公司的幫助,經過對比多家數據恢復公司后選擇了北京一家數據恢復中心,數據恢復中心接到客戶咨詢后安排服務器數據恢復工程師上門進行故障檢測。
服務器數據恢復工程師到客戶現場后將發生故障的服務器以只讀模式重新映射到數據恢復專用備份服務器上,然后使用數據恢復工具將客戶故障服務器以扇區形式鏡像到數據恢復備份服務器上。數據恢復工程師對備份服務器內的數據進行分析推測可能是由于機房電壓不穩導致服務器異常斷電關機,才會出現故障。
服務器數據恢復工程師仔細分析服務器底層數據發現服務器突然斷電導致了目錄項被破壞,但底層數據仍然存在,想要數據恢復只需要工程師手工修復即可。由于服務器管理員對文件系統進行fsck修復,導致了被損壞了的目錄項修復失敗后以目錄節點號進行命名并存放于lost+found文件目錄內,隨后清除了這些目錄項所對應的數據區索引。這就是為什么部分文件丟失的原因。
現在這樣的情況想要進行數據恢復可以通過被刪除的虛擬磁盤文件的文件系統和文件類型在vmfs卷自由空間中進行排查,匹配碎片并重新合并,最終就能將刪除的虛擬磁盤文件進行恢復。
由于客戶需要進行數據恢復的服務器上面使用的是EXT4文件系統,該文件系統的特征是文件丟失后其節點信息也會被清除,所以在本次數據恢復中不能采用根據節點信息進行還原的方法,而是應該根據丟失的文件目錄項節點號匹配lost+found目錄下的文件名稱,因為lost+found目錄下的文件命名的規則就是該文件的目錄項節點號,服務器數據恢復工程師將目錄項節點號進行提取,與lost+found目錄下的文件名進行一一對應,就可以還原服務器的原始目錄結構。
根據上述數據恢復思路,服務器數據恢復工程師對鏡像文件進行底層數據分析,在底層空間掃描目錄項的區域,將目錄項的節點號、數量等信息進行統計和記錄,然后根據服務器磁盤中的文件系統信息將統計到的目錄項和節點號進行整合匹配,最后和lost+found目錄下的文件記錄號進行匹配,最終恢復服務器內丟失的數據。
最后簡單總結一下本次服務器數據恢復的過程,這次服務器出現數據丟失首先是由于供電異常導致服務器異常關機損壞了文件系統,接著人為進行fsck修復導致了鋒無力內的文件目錄結構丟失。數據恢復中心對EXT4文件系統的底層結構具有足夠的數據分析和恢復能力,并且有豐富的相關服務器數據恢復經驗,整個數據恢復過程十分順利,經客戶服務器管理員對數據進行驗證后確認本次數據恢復成功,服務器數據100%恢復。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。