我的服务器有某种驱动器故障导致操作系统（CentOS 5）崩溃并停止工作（它拒绝启动）。
所以，我们把另一个驱动器与一个工作的操作系统，并从那里我们尝试将分区挂载到旧的驱动器。
除了一个分区外，大多数分区都可以正常安装：我的MySQL表所在的/var分区。
当我尝试挂载那个，我看到这些错误与dmesg ：
sd 0：0：1：0：未处理的检测代码
sd 0：0：1：0：SCSI错误：返回码= 0x08100002
结果：hostbyte =无效的driverbyte = DRIVER_SENSE，SUGGEST_OK
sdb：Current：感知键：中等错误
加。 意义：未收回的读取错误
- ext4文件系统所需的分区？
- 新的Windows 2008磁盘分区补偿问题 – 我应该担心吗？
- 主分区与扩展分区
- Preseed Ubuntu / Debian – 分区：防止“分区1不从物理扇区边界开始”。
- 调整debian / tmp分区
信息fld = 0x4a47e
JBD：无法读取偏移量9863处的块
JBD：恢复失败
EXT3-fs：错误加载日志。
有没有一种方法可以恢复该分区中的数据？
编辑：
根据要求， tune2fs -l /dev/sdb2的输出是：
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
编辑2：
按照@Hartmut的build议，我运行fsck.ext3 fsck.ext3 /dev/sdb2 ，结果如下：
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!
看来您的硬盘出现了物理故障，并且影响了包含ext3日志的块。
您将需要第二个空白硬盘驱动器，至less与故障驱动器分区一样大，以执行此磁盘的任何types的恢复。 您还需要将恢复的文件复制到目的地，所以我们称之为第三个空白硬盘，networking文件共享等。
一般的恢复过程将是：
使用dd conv=noerror或更好的dd_rescue将失败的分区复制到新驱动器。 这可能要花点时间。
在复制上执行所有进一步的操作在这里，我假设您已将/dev/sdb2复制到/dev/sdc2 ，并且将文件恢复到/dev/sdd2 。
由于该杂志是腐败的，我们将删除它：
tune2fs -O ^has_journal /dev/sdc2
现在完成设备的fsck。 这可能要花点时间。
e2fsck /dev/sdc2
挂载文件系统只读并尝试恢复文件。
mount -o ro /dev/sdc2 /mnt/baddrive mount /dev/sdd2 /mnt/recoveredfiles cp -av /mnt/baddrive/* /mnt/recoveredfiles
永远不要再使用原始磁盘。 将其更换（在保修期内，如果仍在保修期内）。
你有没有尝试将它mount -t ext2 ...为ext2文件系统与mount -t ext2 ... ？ ext3向后兼容ext2，所以它应该忽略似乎被破坏的日志。 这不是一个理想的解决scheme，但如果你幸运的话，它可以让你访问一些数据！
文件系统的超级块可能已经损坏。 您可以按照以下步骤恢复超级块。
# dumpe2fs /dev/sdb2 | grep -i superblock
示例输出：
Primary superblock at 0, Group descriptors at 1-6 Backup superblock at 32768, Group descriptors at 32769-32774 Backup superblock at 98304, Group descriptors at 98305-98310 Backup superblock at 163840, Group descriptors at 163841-163846 Backup superblock at 229376, Group descriptors at 229377-229382
要么你可以用备选的超级块来分区，或者你可以在文件系统上用没有fsck的备用超级块来挂载分区。
检查文件系统
# fsck.ext3 -b 32768 /dev/sda2
用另一个超级块来挂载文件系统：
# mount sb={alternative-superblock} /dev/device /mnt # mount sb=32768 /dev/sdb2 /mnt
并尝试浏览文件。