Access and repair an ext3 file system with the superblock

A damaged ext3 file system is accessible and repairable, thanks to the data within either the superblock or the superblock's backup.

You won't normally see many problems with your server's file system, but occasionally things go wrong and it will...

be damaged. In this article, you'll learn how to access a damaged ext3 file system.

If you receive a file system error, you will lose file system access. If it is an ext2 or ext3 file system, however, there is still a way in. Advanced mount options will help allow you to access data that you may have considered lost.

In order to gain this access, you need the superblock. This is a 1 KB block that contains all metadata about the file system, which is what you need to mount the file system. It is normally stored as the second 1 KB block on an ext3 file system. To show the contents of the superblock, you can use the debugfs utility. Listing 1 shows what the contents of the superblock looks like:

Listing 1: Contents of the superblock as displayed with debugfs

Filesystem volume name:  <none>
Last mounted on:         <not available>
Filesystem UUID:         09979101-96e0-4533-a7f3-0a2db9b07a03
Filesystem magic number: 0xEF53
Filesystem revision #:   1 (dynamic)
Filesystem features:     has_journal ext_attr 
                         filetype needs_recovery sparse_super large_file
Default mount options:   (none)
Filesystem state:        clean
Errors behavior:         Continue
Filesystem OS type:      Linux
Inode count:             5248992
Block count:             10486428
Reserved block count:    524321
Free blocks:             3888202
Free inodes:             4825214
First block:             0
Block size:              4096
Fragment size:           4096
Blocks per group:        32768
Fragments per group:     32768
Inodes per group:        16352
Inode blocks per group:  511

Problems with your file system can arise if, due to some error, the superblock is no longer accessible. This might happen if, for instance, a mechanical error occurs on your server's hard disk. Fortunately, some backup copies of the superblock are written by default on the ext3 file system. Using these backup copies, you can still mount a file system that might otherwise have been considered lost.

The position of the first backup of the superblock on the disk depends on the size of the file system. On modern large file systems, you will always find it at block 32768. On smaller file systems, you should find it at block 8192. To mount any of the backup superblocks, you can use the mount option -o sb.

The problem with this command, however, is that it expects you to specify the position of the superblock in 1024-byte blocks, whereas the default block size for a modern ext3 volume or partition is 4096 bytes. Therefore, to tell the mount command where it can find the superblock, you have to multiply the position of the superblock by four. This means you should enter the block value 141072 when the first backup superblock is stored on block 32768. If, for example, your /dev/sda5 file system had a problem, you could try mounting it with the command mount -o sb=141072 /dev/sda5/somewhere.

Now that you have mounted the problematic file system and limited the scope of the problem to the superblock, it is time to actually fix the problem. There are both easy and not-as-easy options available. Let's start with the tougher solution, in which you can copy the backup superblock back to the location of the old superblock with the dd utility. To do this, use the code dd if=/dev/sda5 of=/dev/sda5 bs=1024 skip=141072 count=1 seek=1. Once finished, your file system should be accessible just as it was before.

If you don't like this complex and somewhat geeky way of recovering the lost superblock, you can always go for the easy solution. Just enter the code fsck /dev/sda5 and your superblock will be noted as damaged and get repaired for you.

ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. Vugt is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.

This was first published in October 2009

Dig Deeper



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: