【伺服器資料恢復】Ext4檔案系統執行fsck後檔案掛載報錯的資料恢復
伺服器資料恢復環境:
Linux系統,Ext4檔案系統;
劃分為2個分割槽:1個交換分割槽和1個檔案系統分割槽。
在分析實際案例之前,我們先了解一下Ext4的相關知識。
Ext4檔案系統的全部空間被劃分為若干個塊組,每個塊組內的結構大致相同。
每個塊組都對應一個塊組描述符,這些塊組描述符都放在檔案系統的前部,稱為塊組描述符表。每個塊組描述符大小為32字
節,描述了塊點陣圖、i-節點點陣圖及i-節點表的地址等資訊。
超級塊(Superblock)是用來儲存檔案系統的配置引數(如塊大小、總塊數、i-節點數)和動態資訊(當前空閒塊數和i-節點數)。
Ext4檔案系統的超級塊(Superblock)開始於1024位元組處,即2號扇區。
i節點描述檔案的時間資訊、大小、塊指標等資訊。
塊組描述符和超級塊在塊中的位置:當塊大小為2個扇區時,0號塊是載入程式或者保留塊,超級塊起始於1號塊。當塊大小為
4個扇區時,載入程式或者保留塊位於0號塊的前兩個扇區,超級塊位於0號塊的後兩個扇區。當塊大小為8個扇區時,引導程
序或者保留塊位於0號塊的0-1號扇區,超級塊位於0號塊的2-3號扇區。
Ext4檔案系統的整體結構及第一個塊組的具體結構如下圖所示:
伺服器故障&分析:
某公司Ext4檔案系統umount失敗,管理員執行fsck檢查一致性,結果Ext4檔案mount不上(有時也表現為目錄變成了檔案),
報錯資訊:mount: wrong fs type, bad option,bad superblock。
因為日誌和資料不一致而導致正常檔案系統資料被覆蓋的情況在Ext3、Ext4檔案系統中發生的頻率較高。由於journal日誌文
件保留著緩衝資料,資料恢復時可以透過joumal日誌檔案找到相關資訊並重建原始檔。
安裝Linux系統的硬碟第一個扇區是MBR扇區,透過觀察MBR分割槽表得知本案例中Linux系統分為兩個分割槽:交換分割槽和檔案
系統分割槽。北亞資料恢復工程師決定透過joumal日誌檔案找回丟失的資料。
經過資料恢復工程師的檢測分析,本案例Ext4檔案系統相關資訊如下:
1、塊大小為固定的4KB,即8個扇區。
2、超級塊(Superblock)起始位置在1024位元組處,即2號扇區,大小為2個扇區。
3、塊組描述表從第一個塊開始,即從4096位元組處開始。
伺服器資料恢復過程:
1、首先用資料恢復工具將Ext4檔案系統開啟,發現0-23扇區的資料(包括超級塊和塊組描述符)被日誌記錄所覆蓋。Ext3、
Ext4檔案系統的日誌頁以C0 3B 39 98開頭。
超級塊中可以找到關於塊大小的資訊。從journal日誌中把超級塊的備份查詢出來,然後再透過資料恢復工具進行超級塊資訊
的查詢,其標誌是“53ef”。超級塊0x18-0x1B處描述塊大小,本案例塊大小為4KB。
透過超級塊檢視塊大小。
透過資料恢復軟體的模板編輯器也可以顯示塊大小。
2、重建(恢復)超級塊;由於原檔案系統超級塊損壞,所以恢復檔案時要把這部分超級塊資訊貼上回去,即放在2號扇區開始
或1024位元組處。超級塊備份的某些部分的數值可能與實際的超級塊數值不一致,這種情況下需要透過資料恢復工具的模板
管理器進行修改。本案例對超級塊所在的第0個塊組做了修改。
3、重建(恢復)塊組描述表;由於部分塊組描述表被破壞,所以需要先在journal日誌檔案裡找到所有塊組描述表並把它們粘
貼回去。本案例中journal日誌檔案裡的塊組描述符表儲存在超級塊的後面,要找塊組描述表可以先找超級塊,找到後將塊
組描述符表內容貼上到4096位元組處。
4、重建(恢復)目錄;當要恢復某個資料夾裡的檔案時,比如kyproc資料夾裡的資料,這些資料夾在WinHex裡是不能開啟
的狀態,這意味著這個目錄已經損壞(下圖1)。開啟其節點資訊,發現正常資料被日誌填充(下圖2)。
找到上一級目錄var資料夾,右擊點“open”,開啟後能看到var資料夾裡的所有檔案的目錄資訊。找到要恢復的kyproc目
錄的資訊:12 32 EE 00是其i-節點號,10 00表示其目錄項長度,06表示其檔名稱長度,02表示其檔案型別為目錄。如
下圖所示。
在var資料夾的目錄塊下查詢kyproc目錄的位置,如下圖所示,標紅的位置是找到的結果。此位置顯示所在塊號為62399108。
根據所在塊號可以定位kyproc目錄相應節點的位置。由於人工補節點比較繁瑣,可以從journal日誌檔案裡面找到其節點資訊
,把相應的資訊貼上回去。
透過上述方法可以重建(恢復)目錄。恢復目錄裡的檔案也是透過同樣的方法從journal日誌檔案裡找到相應的檔案的節點資訊
,找到後貼上回原來的位置,達到重建(恢復)檔案的目的。
5、經過資料恢復工程師的努力,終於把使用者需要的資料都恢復出來,經過資料恢復工程師和使用者的核檢沒有發現問題。本次
資料恢復工作完成。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2919607/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【伺服器資料恢復】FSCK後ext3檔案系統無法掛載的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】Ext4檔案系統fsck後mount不上並報錯的資料修復案例伺服器資料恢復
- 【伺服器資料恢復】EXT4檔案系統分割槽無法掛載的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】linux下執行FSCK後無法掛載的資料恢復案例伺服器資料恢復Linux
- 【伺服器資料恢復】Linux伺服器EXT4檔案系統故障的資料恢復案例伺服器資料恢復Linux
- 【伺服器資料恢復】StorNext檔案系統資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】xfs檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】ZFS檔案系統下伺服器資料恢復案例伺服器資料恢復
- 伺服器資料恢復-伺服器XFS檔案系統分割槽資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- Linux伺服器資料恢復案例;ocfs2檔案系統資料恢復Linux伺服器資料恢復
- RMAN恢復案例:丟失非系統資料檔案恢復
- 【伺服器資料恢復】ORACLE-SUN-ZFS檔案系統伺服器資料恢復案例伺服器資料恢復Oracle
- 在歸檔下恢復系統資料檔案
- 【北亞資料恢復】zfs檔案系統的伺服器誤刪除的資料恢復資料恢復伺服器
- 備份與恢復--重建控制檔案後資料檔案損壞的恢復
- 【伺服器資料恢復】SAN LUN對映出錯導致檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 伺服器資料恢復-ext3檔案系統下oracle資料庫資料恢復案例伺服器資料恢復Oracle資料庫
- 【伺服器資料恢復】Zfs檔案系統下誤刪除怎麼恢復資料伺服器資料恢復
- 【伺服器資料恢復】reiserfs檔案系統下RAID5資料恢復案例伺服器資料恢復AI
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 資料庫資料恢復—MongoDB資料庫檔案丟失,啟動報錯的資料恢復案例資料庫資料恢復MongoDB
- 【儲存資料恢復】WAFL檔案系統下raid資料恢復案例資料恢復AI
- 【伺服器資料恢復】IBM伺服器ext3檔案系統資料恢復案例伺服器資料恢復IBM
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- rman恢復時跳過資料檔案,進行恢復
- 伺服器資料恢復-UNIX類檔案系統資料災難的資料恢復可能性分析伺服器資料恢復
- 恢復ext4檔案系統被誤刪的檔案
- 【伺服器資料恢復】Lustre分散式檔案系統RAID5資料恢復案例伺服器資料恢復分散式AI
- 資料恢復-電腦管家檔案恢復工具資料恢復
- rman恢復資料檔案 恢復表空間
- 【伺服器資料恢復】REISERFS檔案系統RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】xfs檔案系統分割槽消失不可用的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】VMFS檔案系統RAID5硬碟故障的資料恢復案例伺服器資料恢復AI硬碟
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 【資料庫資料恢復】EXT3檔案系統下MYSQL資料庫恢復案例資料庫資料恢復MySql
- 【伺服器資料恢復】linux ext3檔案系統下mysql資料庫資料恢復案例伺服器資料恢復LinuxMySql資料庫
- 恢復之重建資料檔案