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

发布时间：2020-12-13 17:20:45 所属栏目：Linux 来源：网络整理

导读：我的服务器有某种驱动器故障导致操作系统(CentOS 5)崩溃并停止工作(它拒绝启动). 所以我们把另一个带有工作OS的驱动器放在那里,然后我们尝试在旧驱动器中安装分区. 大多数分区都安装正常,除了一个：/ var分区,我的MySQL表所在的分区. 当我尝试安装那个时,我

我的服务器有某种驱动器故障导致操作系统(CentOS 5)崩溃并停止工作(它拒绝启动).

所以我们把另一个带有工作OS的驱动器放在那里,然后我们尝试在旧驱动器中安装分区.

大多数分区都安装正常,除了一个：/ var分区,我的MySQL表所在的分区.
当我尝试安装那个时,我用dmesg看到这些错误：

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

Info fld=0x4a47e
JBD: Failed to read block at offset 9863
JBD: recovery failed
EXT3-fs: error loading journal.

有没有办法可以恢复该分区中的数据？

编辑：
根据要求,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!

解决方法

您的硬盘驱动器似乎发生了物理故障,并且它已经影响了包含ext3日志的块.

您将需要第二个空白硬盘驱动器,至少与发生故障的驱动器分区一样大,以执行此磁盘的任何类型的恢复.您还需要一个目标来复制恢复的文件,所以我们称之为第三个空白硬盘,网络文件共享等.

一般的恢复过程将是：

>使用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

>在任何情况下都不应该再次使用原始磁盘.更换它(在保修期内,如果它仍在保修期内).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!