Disaster Recovery
From NBSWiki
Contents |
Filesystem corruption
Ext3 bad superblock
Copied from ext3 filesystem bad superblock recovery for prosperity ;)...and a trace of the real thing :P
The Procedure
You did write down the backup superblocks you were given by ext3 when you created your new filesystem, right? No? Oops. If you used the defaults or remember what options you used, never fear. The recover procedure is simple: First, obtain the size of the damaged filesystem in question. If your system still has df functioning, you can run df and grab the filesystem size that way. The output reports the number of 1K (1,024 bytes) blocks the filesystem is using. Next, find a working system if the box with the broken filesystem has lost its root filesystem. Now, invoke the magic of dd. For example, my filesystem showed up as using 101,086 blocks. So I used the following command:
dd if=/dev/zero of=/tmp/foo bs=1024 count=101086
Now, we’re nearly finished. Finally, build an ext3 filesystem on your new file.
jasonb@faith:~$ /sbin/mkfs.ext2 /tmp/foo
mke2fs 1.32 (09-Nov-2002)
/tmp/foo is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25272 inodes, 101086 blocks
5054 blocks (5.00%) reserved for the super user
First data block=1
13 block groups
8192 blocks per group, 8192 fragments per group
1944 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
(The careful reader will notice I used mkfs.ext2, but the results are the same.)
Look, your missing superblocks are revealed!
Now, to recover, call fsck.ext3 on the damaged system.
/sbin/fsck.ext3 -b 57345 /dev/sda1
Carefully evaluate the prompts and decide if you want to allow fsck to proceed with filesystem repairs. If the backup superblock is also invalid, try another or follow the steps above again and double check your numbers.
But what if you don't have enough space to create a file as big as your lost partition? If that is the case or the partition is so huge you don’t want to wait that long for dd to complete, there is another option. The superblock locations vary depending on the blocksize used. The ext3 filesystem varies between 1024, 2048, and 4096 bytes depending on the size of the filesystem. Since the locations are neither magic or random, you can create, say, a 500MB partition and force the blocksize to match that of the damaged filesystem.
/sbin/mkfs.ext3 -j -b 4096 /tmp/foo
The presence or absence of a journal does not effect the location of the backup superblocks. Perhaps I should've titled this fishing for superblocks instead.
An Applied Example
livecd ~ # fdisk -l -b 1024 /dev/hda
Disk /dev/hda: 60.0 GB, 60011642880 bytes 255 heads, 63 sectors/track, 3648 cylinders Units = cylinders of 16065 * 1024 = 16450560 bytes
Device Boot Start End Blocks Id System /dev/hda1 1 13 208782 83 Linux /dev/hda2 14 1038 16466625 83 Linux /dev/hda3 1039 7296 100534770 83 Linux
Create empty "virtual" partition (hda3 being the lost one obviously):
cp /dev/hda3 /mnt/gentoo/part3
Identifying the spare superblocks
livecd ~ # mkfs.ext2 /mnt/gentoo/HDA3
mke2fs 1.38 (30-Jun-2005)
/mnt/gentoo/HDA3 is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
6291456 inodes, 12566846 blocks
628342 blocks (5.00%) reserved for the super user
First data block=0
384 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
