SuperBlock損壞修復

什麼是superblock？

能夠參考下這個網站：http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm

詳細的介紹superblock組成 構成

 

你們可能遇到過這樣的狀況：

[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

[root@dhcp-0-142 ~]#

 

這種狀況通常爲superblock損壞的機率很大。

 

例如我如今/dev/sdb1沒法掛載 現象如上，能夠這樣操做：

 

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: <none>

Last mounted on: <not available>

Filesystem UUID: c3800df3-5c34-4b53-8144-94029b5736d8

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super

Default mount options: (none)

Filesystem state: clean with errors

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 0

Block count: 0

Reserved block count: 0

Free blocks: 20926971

Free inodes: 4705752

First block: 1

Block size: 1024

Fragment size: 1024

Reserved GDT blocks: 256

Blocks per group: 8192

Fragments per group: 8192

Inodes per group: 2008

Inode blocks per group: 251

Filesystem created: Tue Oct 7 19:18:08 2008

Last mount time: n/a

Last write time: Tue Oct 7 19:29:39 2008

Mount count: 0

Maximum mount count: 20

Last checked: Tue Oct 7 19:18:08 2008

Check interval: 15552000 (6 months)

Next check after: Sun Apr 5 19:18:08 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

Directory Hash Seed: 7f7e1c41-5cae-4f23-9873-877991751ccb

Journal backup: inode blocks

dumpe2fs: Illegal inode number while reading journal inode

[root@dhcp-0-142 ~]#

因此我作以下操做：

[root@dhcp-0-142 ~]# fsck -b 8193 /dev/sdb1

fsck 1.39 (29-May-2006)

e2fsck 1.39 (29-May-2006)

/dev/sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: 11/26104 files (9.1% non-contiguous), 8966/104388 blocks

[root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1

[root@dhcp-0-142 ~]# ls /mnt/sdb1

lost+found

[root@dhcp-0-142 ~]#

 

superblock已經修復，文件系統掛載正常。 這麼作是由於ext2/3文件系統在建立文件系統的時候會建立若干個superblock的備份存放於特定位置。

 

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep --before-context=1 superblock

dumpe2fs 1.39 (29-May-2006)

Group 0: (Blocks 1-8192)

Primary superblock at 1, Group descriptors at 2-2

--

Group 1: (Blocks 8193-16384)

Backup superblock at 8193, Group descriptors at 8194-8194

--

Group 3: (Blocks 24577-32768)

Backup superblock at 24577, Group descriptors at 24578-24578

--

Group 5: (Blocks 40961-49152)

Backup superblock at 40961, Group descriptors at 40962-40962

--

Group 7: (Blocks 57345-65536)

Backup superblock at 57345, Group descriptors at 57346-57346

--

Group 9: (Blocks 73729-81920)

Backup superblock at 73729, Group descriptors at 73730-73730

[root@dhcp-0-142 ~]#

從上面操做能夠看出，在第一、三、四、七、9這幾個Block Group上存放有superblock備份。

什麼是Block Group？ext2/3文件系統爲了提升磁盤尋道效率，把inode table等信息按照Inodes per group分紅若干組存放，而沒有所有放在一塊兒。 
 

Inodes per group信息相見命令：

[root@dhcp-0-142 ~]# dumpe2fs /dev/sdb1 | grep 'Inodes per group'

dumpe2fs 1.39 (29-May-2006)

Inodes per group: 2008

[root@dhcp-0-142 ~]#

有些文件系統superblock損壞的很厲害。連dumpe2fs和tune2fs都看不到信息。

[root@dhcp-0-175 ~]# dd if=/dev/zero of=/dev/sdb1 bs=1 count=1024 seek=1024

1024+0 records in

1024+0 records out

1024 bytes (1.0 kB) copied, 0.0228272 seconds, 44.9 kB/s

[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

Couldn't find valid filesystem superblock.

[root@dhcp-0-175 ~]# tune2fs -l /dev/sdb1

tune2fs 1.39 (29-May-2006)

tune2fs: Bad magic number in super-block while trying to open /dev/sdb1

Couldn't find valid filesystem superblock.

[root@dhcp-0-175 ~]#

這時候咱們根本沒法從dumpe2fs和tune2fs看到Backup superblock的位置。

咱們能夠嘗試從superblock的結構來猜想superblock的位置（superblock結構見上圖）。

咱們從superblock結構能夠知道，卷標volume name存放於superblock中。因此若是文件系統有設置卷標，那麼咱們能夠嘗試從卷標來定位superblock。

咱們用hexdump把文件系統dump出來：

[root@dhcp-0-175 ~]# hexdump -C /dev/sdb1 > /var/sdb1.hexdump

[root@dhcp-0-175 ~]#

咱們已知 /dev/sdb1的卷標是sdb1(若是不知道卷標或者沒有設置卷標，那麼我就沒辦法了)。

咱們搜索sdb1，搜到結果以下： 

 

咱們猜想這裏就是備份superblock的位置。

卷標起始位置是0x18000078。因爲superblock結構裏volume name位於0x78的位置，因此咱們能夠猜想備份superblock的起始位置是0x18000078 – 0x78 = 0x18000000。

因爲blocksize位於superblock的[0x18, 0x22)的位置，這裏的值是0x0002，得出blocksize是0x0400 x ( 0x00020x0002 ) = 0x1000 = 4096

( [0x18, 0x22) 處值n和blocksize的關係是 blocksize = 0x0400 x 0x0002n)

而備份superblock的偏移量爲offset / blocksize，即0x18000000 / 0x1000 = 0x00018000 = 98304。

所以咱們執行：

[root@dhcp-0-175 ~]# fsck.ext3 -b 98304 /dev/sdb1

e2fsck 1.39 (29-May-2006)

sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

sdb1: ***** FILE SYSTEM WAS MODIFIED *****

sdb1: 11/123648 files (9.1% non-contiguous), 8298/246991 blocks

[root@dhcp-0-175 ~]#

這樣文件系統就有給修復的可能性了。

測試一下：

[root@dhcp-0-175 ~]# dumpe2fs /dev/sdb1

dumpe2fs 1.39 (29-May-2006)

Filesystem volume name: sdb1

Last mounted on: <not available>

Filesystem UUID: 0293bd85-b911-43bf-853e-6588b3eaaf39

Filesystem magic number: 0xEF53

Filesystem revision #: 1 (dynamic)

Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file

Default mount options: (none)

Filesystem state: clean

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 123648

Block count: 246991

Reserved block count: 12349

Free blocks: 238693

Free inodes: 123637

First block: 0

Block size: 4096

Fragment size: 4096

Reserved GDT blocks: 60

Blocks per group: 32768

Fragments per group: 32768

Inodes per group: 15456

Inode blocks per group: 483

Filesystem created: Wed Oct 8 12:49:09 2008

Last mount time: n/a

Last write time: Wed Oct 8 12:52:10 2008

Mount count: 0

Maximum mount count: 28

Last checked: Wed Oct 8 12:52:10 2008

Check interval: 15552000 (6 months)

Next check after: Mon Apr 6 12:52:10 2009

Reserved blocks uid: 0 (user root)

Reserved blocks gid: 0 (group root)

First inode: 11

Inode size: 128

Journal inode: 8

Default directory hash: tea

Directory Hash Seed: 2efa124c-dde6-4046-9181-a05b7e6d182a

Journal backup: inode blocks

Journal size: 16M 

 Group 0: (Blocks 0-32767)

Primary superblock at 0, Group descriptors at 1-1

Reserved GDT blocks at 2-61

Block bitmap at 62 (+62), Inode bitmap at 63 (+63)

Inode table at 64-546 (+64)

28113 free blocks, 15445 free inodes, 2 directories

Free blocks: 4655-32767

Free inodes: 12-15456

Group 1: (Blocks 32768-65535)

Backup superblock at 32768, Group descriptors at 32769-32769

Reserved GDT blocks at 32770-32829

Block bitmap at 32830 (+62), Inode bitmap at 32831 (+63)

Inode table at 32832-33314 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 33315-65535

Free inodes: 15457-30912

Group 2: (Blocks 65536-98303)

Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1)

Inode table at 65538-66020 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 66021-98303

Free inodes: 30913-46368

Group 3: (Blocks 98304-131071)

Backup superblock at 98304, Group descriptors at 98305-98305

Reserved GDT blocks at 98306-98365

Block bitmap at 98366 (+62), Inode bitmap at 98367 (+63)

Inode table at 98368-98850 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 98851-131071

Free inodes: 46369-61824

Group 4: (Blocks 131072-163839)

Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1)

Inode table at 131074-131556 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 131557-163839

Free inodes: 61825-77280

Group 5: (Blocks 163840-196607)

Backup superblock at 163840, Group descriptors at 163841-163841

Reserved GDT blocks at 163842-163901

Block bitmap at 163902 (+62), Inode bitmap at 163903 (+63)

Inode table at 163904-164386 (+64)

32221 free blocks, 15456 free inodes, 0 directories

Free blocks: 164387-196607

Free inodes: 77281-92736

Group 6: (Blocks 196608-229375)

Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1)

Inode table at 196610-197092 (+2)

32283 free blocks, 15456 free inodes, 0 directories

Free blocks: 197093-229375

Free inodes: 92737-108192

Group 7: (Blocks 229376-246990)

Backup superblock at 229376, Group descriptors at 229377-229377

Reserved GDT blocks at 229378-229437

Block bitmap at 229438 (+62), Inode bitmap at 229439 (+63)

Inode table at 229440-229922 (+64)

17068 free blocks, 15456 free inodes, 0 directories

Free blocks: 229923-246990

Free inodes: 108193-123648

[root@dhcp-0-175 ~]# mount /dev/sdb1 /mnt

[root@dhcp-0-175 ~]# ls /mnt

lost+found

[root@dhcp-0-175 ~]#

其實對於這種superblock破壞很嚴重的文件系統，其實系統已經有了很強大的修復方案：
咱們能夠用mke2fs -S 來修復superblock。

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/

mount: you must specify the filesystem type

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

[root@dhcp-0-175 /]# mke2fs -S /dev/sdb1

mke2fs 1.39 (29-May-2006)

Filesystem label=

OS type: Linux

Block size=1024 (log=0)

Fragment size=1024 (log=0)

24480 inodes, 97656 blocks

4882 blocks (5.00%) reserved for the super user

First data block=1

Maximum filesystem blocks=67371008

12 block groups

8192 blocks per group, 8192 fragments per group

2040 inodes per group

Superblock backups stored on blocks:

8193, 24577, 40961, 57345, 73729

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/

[root@dhcp-0-175 /]# cd /mnt

[root@dhcp-0-175 mnt]# ls

file0 file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

file1 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file10 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file100 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

[root@dhcp-0-175 mnt]#

 

e2fsck也能夠達到一樣的效果

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

missing codepage or other error

In some cases useful info is found in syslog - try

dmesg | tail or so

[root@dhcp-0-175 /]# e2fsck /dev/sdb1

e2fsck 1.39 (29-May-2006)

Couldn't find ext2 superblock, trying backup blocks...

/dev/sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

Free blocks count wrong for group #0 (3549, counted=3547).

Fix<y>? yes

Free blocks count wrong (88895, counted=88893).

Fix<y>? yes

Free inodes count wrong for group #0 (2029, counted=1929).

Fix<y>? yes

Free inodes count wrong (24469, counted=24369).

Fix<y>? yes

 

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: 111/24480 files (1.8% non-contiguous), 8763/97656 blocks

[root@dhcp-0-175 /]# mount /dev/sdb1 /mnt/ -t ext3

[root@dhcp-0-175 /]# ls /mnt

file0 file15 file21 file28 file34 file40 file47 file53 file6 file66 file72 file79 file85 file91 file98

file1 file16 file22 file29 file35 file41 file48 file54 file60 file67 file73 file8 file86 file92 file99

file10 file17 file23 file3 file36 file42 file49 file55 file61 file68 file74 file80 file87 file93 lost+found

file11 file18 file24 file30 file37 file43 file5 file56 file62 file69 file75 file81 file88 file94

file12 file19 file25 file31 file38 file44 file50 file57 file63 file7 file76 file82 file89 file95

file13 file2 file26 file32 file39 file45 file51 file58 file64 file70 file77 file83 file9 file96

file14 file20 file27 file33 file4 file46 file52 file59 file65 file71 file78 file84 file90 file97

[root@dhcp-0-175 /]# 

 

當你的系統出現superblock corrupt而沒法啓動時：

1.用應急盤啓動,先看fdisk的結果.若是你的分區表看起來正常,那麼恢復的可能性就比較大,若是出現cannot open /dev/sda2的提示,那麼想想你的scsi卡啓動沒有,若是沒有,那麼你能夠試着用小紅帽的安裝光盤啓動,記住,僅僅是看分區表,千萬不要寫它.而後把分區狀況詳細記錄下來.

 

2.試着e2fsck /dev/hda2,(先不要加-p -y 之類的參數,)用手動進行修復,同時也能夠了解具體是文件系統的那些地方損壞了,若是你的運氣好,e2fsck過去了,/dev/hda2已經基本修復,固然修復的多是99.9%,也多是99%這就看文件系統的損壞程度樂,不過如今能夠說你的數據已經都找回來了.剩下的事就是mount上把數據備份出來以防萬一.

 

3.若是e2fsck沒過去(確保你的硬盤已經正確驅動樂),也不要着急,由於superblock在硬盤中有不少地方有備份,如今你最好把硬盤卸下來掛到另外一個好的linux系統上,固然一樣要保證硬盤被正確驅動樂.先用e2fsck /dev/hda2,若是結果和前面同樣，就用e2fsck -b xxx -f /dev/hda2, xxx是硬盤上superblock的備份塊,xxx=n*8192+1,n=1,2,3...通常來說,若是系統癱瘓的真正緣由是superblock損壞，這種辦法就應該能夠恢復你的數據了。若是執行後的結果仍是不能經過,那麼往下一步.

 

4.利用dd命令.先dd if=/dev/hda2 of=/tmp/rescue conv=noerror(/tmp/rescue是一個文件),把重要的數據拷出來,固然,這個盤要比你損壞的盤大一點,不然拷不下.另外,上面的dd命令在不一樣的境況下if和of應做相應的修改，寫在這裏只是一個例子，總之在用dd以前最好先看看man.剛纔你已經看到你的分區表了,如今找一個和你的硬盤同樣的硬盤,應該是一摸同樣（大小，型號),在這塊硬盤上按照壞盤上的分區表分區，分的區也應該是也是如出一轍而後用dd命令把壞盤上superblock location後的東東所有拷到好盤的superblock location後，上帝保佑你，當你再次啓動系統時就能夠看到熟悉的數據了,有人用這種方法恢復了99%以上的數據,不過好在這種方法(包括前面的方法)沒有動那塊壞盤上的數據,若是仍是沒有恢復,那沒你還有最後一種選擇.

 

5. 在手冊頁裏稱這種方法爲last-ditch recovery method,就是說這是最後的恢復方法，只有當你已經嘗試了其餘的方法,都沒有能恢復你的數據的狀況下才用,由於這須要冒必定的風險.
把你的硬盤掛在一臺好的linux box上，運行：#mke2fs -S /dev/hda2(若是你的數據在hda2裏）這條命令只重建superblock，而不碰inode表，不過這仍有必定的風險。good luck to you all.當時也有人建議我若是實在不行的話就重裝系統（不動分區也不格式化），這也可能有效，但你也應該清楚這種方法就像mke2fs -S /dev/hd*同樣是有風險的。

一點建議：
若是你的硬盤不是能夠輕易就重作的，最好在創建一個新的系統後：

1。拿出筆和紙,把你的分區信息詳細記錄下來.

2. 用mkbootdisk作好如今這個系統的啓動盤並測試.特別是若是你用的硬盤是scsi的。

3. 在用mke2fs創建一個文件系統後將屏幕上的superblock所在位置記錄下來。

4. 用crontab對重要數據進行備份。ext2文件系統（包括其餘的unix文件系統）是很強壯的，但你仍然應該當心。

 

 

RedHat官方解釋：

解決方法:

一般在做磁盤操做以前應該備份磁盤的數據，在做這個操做以前也應該把磁盤上的全部內容備份到另外一個磁盤中。就是說若是這個故障盤是20g的話，就須要一個20G的備份空間。備份的命令以下：

#dd if=/dev/baddrive of=/storagearea
而後能夠在已經卸載的故障盤上運行以下命令找到備份的superblock.

#mke2fs -n /dev/badparition
再運行mke2fs命令的時候須要把參數設置成爲文件系統建立時所用的參數。若是當初使用的是默認值， 那就可使用以下命令：

#mke2fs -n -b 4000 /dev/hdb1
能夠看到有以下的輸出:

Filesystem label=OS type: LinuxBlock size=1024 (log=0)Fragment size=1024 (log=0)122400 inodes, 488848 blocks24442 blocks (5.00%) reserved for the super userFirst data block=160 block groups8192 blocks per group, 8192 fragments per group2040 inodes per groupSuperblock backups stored on blocks:        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409從輸出可知superblock存在於: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409.