主页 / unix / 问题 / 688265
Accepted
php_nub_qq
Asked: 2022-01-28 15:20:00 +0800 CST

如何从损坏的驱动器中浏览 img（恢复丢失的数据）

  • 772

目前我相信我遇到了驱动器 (HDD) 故障。它是用于额外存储的单个分区驱动器。当我尝试安装它时，出现以下错误：

# mount /dev/sdc1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

按照建议检查 dmesg：

# dmesg | tail
[12641.405658] blk_update_request: critical medium error, dev sdc, sector 2064
[12641.410139] Buffer I/O error on dev sdc1, logical block 2, async page read
[12641.415774] EXT4-fs (sdc1): couldn't mount as ext3 due to feature incompatibilities
[12641.420578] EXT4-fs (sdc1): couldn't mount as ext2 due to feature incompatibilities
[12644.186523] sd 5:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[12644.186543] sd 5:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current] 
[12644.186556] sd 5:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
[12644.186570] sd 5:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 08 10 00 00 08 00
[12644.186580] blk_update_request: critical medium error, dev sdc, sector 2064
[12644.191255] EXT4-fs (sdc1): can't read group descriptor 1

正如我所说，我假设驱动器是夜间行驶，所以我想至少保存我在那里的所有信息（顺便说一句，这是更重要的一面）。我尝试从驱动器上切下 500GB，看看它是否可以工作：

# ddrescue -d -s 500G /dev/sdc data.img data.log

不幸的是，我在 ssh 上运行它并且我的管道坏了或其他东西，所以我最终得到了一个 ~150GB 的img文件，当我尝试挂载时，我得到了与尝试挂载驱动器本身时相同的错误（duh）：

# mount data.img /mnt -o loop
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

如何获取应该保存的信息？

filesystems hard-disk

1 个回答

  1. Best Answer

    对于发现此问题的任何人，我都设法解决了该问题，而无需求助于photorec或其他打捞工具。我制作了一个完整的磁盘映像，以防万一，ddrescue但最终不需要它。

    运行badblocks并查看 SMART 数据我确定有 1 个损坏的扇区位于驱动器的开头某处。显然它是存储超级块的地方，这就是分区无法识别且无法安装的原因。

    我试着跑步e2fsck -cfpv /dev/sdc1并得到了

    e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc1
Could this be a zero-length partition?

    我是菜鸟，我不知道发生了什么，但显然用零覆盖该扇区并重新运行e2fsck会产生某种魔力并修复分区，之后我能够挂载分区并复制我之前的所有文件把硬盘扔出窗外。e2fsck这是我发出的命令（是的，一旦我注意到分区被识别并且可以挂载，我立即停止了）：

    # dd if=/dev/zero of=/dev/sdc1 bs=4096 count=1 seek=0
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000367146 s, 11.2 MB/s

# e2fsck -fy -b 32768 /dev/sdc1
e2fsck 1.46.2 (28-Feb-2021)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdc1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
^C/dev/sdc1: e2fsck canceled.

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****

    完整的解释和所有的功劳都归功于这个人，我希望宇宙向他发送大量的健康和财富，并满足他最深切的愿望！

    • 1

相关问题