损坏的磁盘映像导致的错误

损坏的磁盘映像导致的错误

我制作了一个驱动器的映像 (dd),并尝试对其运行文件系统检查:文件系统类型:ext3

这是 fsck 的原始错误:

 fsck -fv -z ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.$(date
+"%Y-%m-%d.%H.%M.%S").und /dev/loop2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Overwriting existing filesystem; this can be undone using the command:
    e2undo ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.2019-01-17.13.31.41.und /dev/loop2

The filesystem size (according to the superblock) is 122063840 blocks
The physical size of the device is 121604515 blocks
Either the superblock or the partition table is likely to be corrupt!

来自 fdisk -l /dev/sda 的信息

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000794ac

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1  *        32      8191      8160     4M  4 FAT16 <32M
/dev/sda2       262144 976773119 976510976 465.7G 83 Linux

来自 fdisk -l ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img 的信息

Disk ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img: 464 GiB, 498226311168 bytes, 973098264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000794ac

Device                                              Boot  Start       End   Sectors   Size Id Type
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img1 *        32      8191      8160     4M  4 FAT16 <32M
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img2      262144 976773119 976510976 465.7G 83 Linux

我使用以下命令为分区创建了一个循环设备:

losetup --offset $((512*262144)) /dev/loop2 ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img

来自 blockdev --getbsz /dev/loop2

4096

来自 blockdev --getsz /dev/loop2

972836120

来自 dumpe2fs /dev/loop2:

Filesystem UUID:          f68ccb5a-bcfa-4e8a-8876-45adaa6e6b85
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30523392
Block count:              122063840
Reserved block count:     6103192
Free blocks:              96939245
Free inodes:              30462657
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Sat Apr 26 21:28:22 2014
Last mount time:          Wed Jan 16 15:59:22 2019
Last write time:          Thu Jan 17 18:16:50 2019
Mount count:              17
Maximum mount count:      -1
Last checked:             Sat Apr 26 21:28:22 2014
Check interval:           0 (<none>)
Lifetime writes:          10 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      162d0daa-7968-48f9-8370-f095c9e19f58
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000059bd
Journal start:            0

接下来是很多:

Group 0: (Blocks 0-32767)
  Primary superblock at 0, Group descriptors at 1-30
  Reserved GDT blocks at 31-1024
  Block bitmap at 1025 (+1025)
  Inode bitmap at 1026 (+1026)
  Inode table at 1027-1538 (+1027)
  4 free blocks, 8179 free inodes, 2 directories
...
(SKIPPING TO END)
...
Group 3725: (Blocks 122060800-122063839)
  Block bitmap at 122060800 (+0)
  Inode bitmap at 122060801 (+1)
  Inode table at 122060802-122061313 (+2)
  0 free blocks, 8192 free inodes, 0 directories

完成于:

dumpe2fs: /dev/loop2: error reading bitmaps: Can't read a block bitmap

现在我可以正常挂载 /dev/sda2 并读取文件,但是我无法挂载 /dev/loop2

mount -t ext3 /dev/loop2 ./DriveImage/
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

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

当我尝试使用以下命令直接从图像中挂载时出现相同的错误:

mount -o loop,offset=$((512*262144)) ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img ./DriveImage

现在根据 dumpe2fs 的说法,超级块是正确的!
并且根据数学计算:

 Superblock says:
 122063840
 Filesystem says:
 121604515

 block size:
 4096

 Math: Sectors * Sector Size = Size / Block Size = Blocks
 Partition 1: 
 8160 * 512 = 4177920 / 4096 = 1020
 Partition 2:
 [From fdisk]
 976510976 * 512 = 499973619712 / 4096 = 122063872
 [From blockdev with /dev/loop2]
 972836120 * 512 = 498092093440 / 4096 = 121604515

fdisk 报告的块非常接近正确的块......(仅剩 32 个块)但在我的书中,fsck 获取其块大小信息的方式与 blockdev 相同(或使用它),但根据 dumpe2fs 和检查实际分区表,超级块实际上是正确的,分区表也是如此。

由于担心丢失磁盘上的原始数据(10 年的家庭照片/视频和重要文件),我不愿意在原始磁盘上运行这些东西。所以我将磁盘复制到此映像,然后,为了以防万一我搞砸了什么,我还复制了映像。(别担心,我有磁盘空间可以放这些)。

我在这里做错了什么?我该如何解决这个问题?

注意:由于旧驱动器开始出现故障(假设,我遇到了一些问题),这就是我这样做的原因。
另外,由于某种原因,驱动器丢失了分区表,我不得不使用 testdisk 来恢复它。恢复后,我能够挂载大分区并读取所有数据。
因此,我认为 testdisk 要么做对了,要么非常接近,因为一切都在那里。

(更新#1)我还应该注意,当我在原始驱动器上运行 fsck 时,我没有收到此错误...

fsck -nfv /dev/sda2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       60735 inodes used (0.20%, out of 30523392)
        1510 non-contiguous files (2.5%)
          49 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 23779/2425/0
    25124595 blocks used (20.58%, out of 122063840)
           0 bad blocks
           1 large file

       56022 regular files
        4704 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
       60726 files

(更新 #2)我发现映像文件与驱动器不同,映像文件较小。
驱动器大小:500107862016(这里有一个错误,我只得到了第二个分区的大小,已更新为正确信息)映像大小
:498226311168
映像文件缺少 1881550848 字节,超过 1.88GB 的​​数据。(这也已更正)
似乎 dd 没有得到所有内容,而且我可能是对的,驱动器有问题,有没有办法让 dd 用空白填充读取错误,以便我可以获得匹配的大小?

我正在循环设备上运行 fsck 来查看它的作用,我想如果我把它搞乱了,我就会恢复后面的图像。

另一个重要说明:这是一个无头服务器系统,没有 GUI,只有 CLI。

答案1

损坏的磁盘映像导致的错误

听起来你看到的图像错误是由驱动器故障引起的。我会使用救援相反,它会尝试处理读取错误。

Gddrescue 手册信息丰富,这是部分10 带有示例的小教程以。。开始

示例 1:将 /dev/sda 中带有两个 ext2 分区的整个磁盘全自动恢复到 /dev/sdb。
注意:您不需要事先对 /dev/sdb 进行分区,但如果 /dev/sda 上的分区表损坏,则需要以某种方式在 /dev/sdb 上重新创建它。

ddrescue -f -r3 /dev/sda /dev/sdb mapfile
fdisk /dev/sdb
e2fsck -v -f /dev/sdb1
e2fsck -v -f /dev/sdb2

与其直接将数据恢复到设备 (/dev/sdb),不如使用文件。与其一开始-r 3就重试坏扇区 3 次,不如先使用默认值 (0) 和-n/--no-scrape来“跳过抓取阶段”,以便尽可能快地获取尽可能多的数据。

还有一个ddrescueview提供 gddrescue 地图文件图形视图的包,可能会很有趣:

在此处输入图片描述

并且监控 syslog 或 dmesg 应该早点显示读取错误,我会在使用该驱动器时监控它们。

有那么多重要的文件需要备份吗?

如果文件仍然可读,尤其是当您想要备份的重要文件比整个驱动器小得多时,只需复制这些文件,而不必考虑整个驱动器映像。操作系统很容易重新安装。

挂载完整磁盘映像

好像 losetup -P除 之外,还会自动创建适当的分区循环设备,或者partprobe或。gnome-disk-image-mounterkpartx

相关内容