☰

如何从损坏的 ext3 分区恢复数据？

tag-icon • tag-icon linux mount partition ext3 data-recovery
如何从损坏的 ext3 分区恢复数据？

我的一台服务器出现某种驱动器故障，导致操作系统（CentOS 5）崩溃并停止工作（拒绝启动）。

因此，我们放置另一个装有可运行操作系统的驱动器，然后尝试从那里安装旧驱动器中的分区。

大多数分区都安装正常，除了一个分区/var，即我的 MySQL 表所在的分区。
当我尝试安装该分区时，我看到以下错误dmesg：

sd 0:0:1:0: 未处理的感知代码
sd 0:0:1:0: SCSI 错误：返回代码 = 0x08100002
结果：hostbyte=invalid driverbyte=DRIVER_SENSE,SUGGEST_OK
sdb：当前：感知键：中等错误
附加感知：未恢复的读取错误

信息 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 的建议，我运行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!

答案1

看起来您的硬盘驱动器发生了物理故障，并且影响了包含 ext3 日志的块。

您将需要第二块空白硬盘，其大小至少与故障驱动器分区一样大，才能对该磁盘执行任何类型的恢复。您还需要一个目标位置来复制恢复的文件，因此我们将其称为第三个空白硬盘、网络文件共享等。

一般的恢复过程如下：

  1. dd conv=noerror使用或更好的将故障分区复制到新驱动器dd_rescue。这可能需要一些时间。

  2. 对副本执行所有进一步的操作这里我假设您已复制/dev/sdb2到/dev/sdc2并且您将文件恢复到/dev/sdd2。

  3. 由于日志已损坏，我们将把它删除：

    tune2fs -O ^has_journal /dev/sdc2

  4. 现在完成设备的 fsck。这可能需要一些时间。

    e2fsck /dev/sdc2

  5. 以只读方式挂载文件系统并尝试恢复文件。

    mount -o ro /dev/sdc2 /mnt/baddrive
mount /dev/sdd2 /mnt/recoveredfiles
cp -av /mnt/baddrive/* /mnt/recoveredfiles

  6. 在任何情况下，您都不应再使用原始磁盘。更换它（在保修期内，如果仍在保修期内）。

答案2

您是否尝试过将其安装为 ext2 文件系统mount -t ext2 ...？ext3 向后兼容 ext2，因此它应该会忽略似乎已损坏的日志。这不是理想的解决方案，但如果您幸运的话，它可能会让您访问一些数据！

答案3

文件系统的超级块可能已损坏。您可以按照以下步骤恢复超级块。

# 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 的分区。

检查文件系统

# fsck.ext3 -b 32768 /dev/sda2

要使用替代超级块挂载文件系统：

# mount sb={alternative-superblock} /dev/device /mnt
# mount sb=32768 /dev/sdb2 /mnt

并尝试浏览文件。

相关内容