A server of mine had a drive failure of some sort which caused the OS (CentOS 5) to crash and stop working (it refuses to boot).
So we put another drive with a working OS and from there we try to mount the partitions in the old drive.
Most partitions mount fine except for one: the
/var partition, where my MySQL tables reside.
When I try to mount that one, I see these errors with
sd 0:0:1:0: Unhandled sense code
sd 0:0:1:0: SCSI error: return code = 0x08100002
Result: hostbyte=invalid driverbyte=DRIVER_SENSE,SUGGEST_OK
sdb: Current: sense key: Medium Error
Add. Sense: Unrecovered read error
JBD: Failed to read block at offset 9863
JBD: recovery failed
EXT3-fs: error loading journal.
Is there a way I can recover the data in that partition?
As requested, the output of
tune2fs -l /dev/sdb2 is:
tune2fs 1.39 (29-May-2006) Filesystem volume name: /var1 Last mounted on: <not available> Filesystem UUID: d84f5181-24f3-40ce-9eaa-601ae5ae33bd Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 26214400 Block count: 26214063 Reserved block count: 1310703 Free blocks: 25127226 Free inodes: 26213665 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1017 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 32768 Inode blocks per group: 1024 Filesystem created: Thu May 13 18:14:28 2010 Last mount time: Thu Nov 29 12:52:00 2012 Last write time: Wed Mar 27 20:29:28 2013 Mount count: 15 Maximum mount count: -1 Last checked: Thu May 13 18:14:28 2010 Check interval: 0 (<none>) 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: 35f38c48-3933-4c99-bde2-63b0eccf200d Journal backup: inode blocks
As suggested by @Hartmut, I run
fsck.ext3 /dev/sdb2 with the following result:
e2fsck 1.39 (29-May-2006) /var1: recovering journal /var1: Attempt to read block from filesystem resulted in short read while reading block 11931 JBD: Failed to read block at offset 9863 fsck.ext3: No such device or address while trying to re-open /var1 e2fsck: io manager magic bad!
It appears that your hard drive has had a physical failure, and that it has affected a block containing the ext3 journal.
You will need a second blank hard drive, at least as large as the failed drive partition, to perform any sort of recovery of this disk. You will also need a destination to copy recovered files to, so let’s call it a third blank hard drive, network file share, etc.
The general recovery process is going to be:
Copy the failed partition to the new drive using
dd conv=noerroror better
dd_rescue. This may take some time.
Perform all further operations on the copy Here I assume that you have copied
/dev/sdc2and that you will recover files to
Since the journal is corrupt, we will remove it:
tune2fs -O ^has_journal /dev/sdc2
Now complete an fsck of the device. This may take some time.
Mount the filesystem read-only and attempt to recover files.
mount -o ro /dev/sdc2 /mnt/baddrive mount /dev/sdd2 /mnt/recoveredfiles cp -av /mnt/baddrive/* /mnt/recoveredfiles
In no case should you ever use the original disk again. Replace it (under warranty, if it is still under warranty).
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.