☰

BS选项会导致数据与dd不一致吗？

tag-icon • tag-icon linux dd
BS选项会导致数据与dd不一致吗？

我有一个用 dd 备份的笔记本电脑分区（truecrypt），因为不可能用其他任何东西来备份它，只能进行原始的一点一点复制，例如：

dd if=/dev/sda of=imagefile.img

我当然也可以成功恢复它，但是使用默认 bs (512) 恢复时间很长。

如果我将 BS 大小增加到 1MB，是否会导致任何不一致？该机器有 8Gb 内存，在将其写入磁盘之前将 1mb 或 10mb 或 100mb 读入内存应该不重要，但我很好奇当它到达图像文件末尾和分区末尾时它会做什么。它不会尝试覆盖下一个磁盘区域上的数据吗？

假设最后一次读取图像中仅剩下 512 字节，它是否会尝试将 512 字节+剩余的 0.00048828125 Mbyte 写入磁盘？

dd if=imagefile.img of=/dev/sda1 bs=1M

谢谢

答案1

很好的问题，让我们来看看。制作一些随机数据

dd if=/dev/urandom of=/tmp/rand1Mx10.dat bs=1M count=10

通过多种方式复制它：

$ dd if=rand1Mx10.dat of=1Mx10copy_3M.dat bs=3M status=progress
10485760 bytes (10 MB, 10 MiB) copied, 0.0196387 s, 534 MB/s

$ dd if=rand1Mx10.dat of=1Mx10copy_1M.dat bs=1M status=progress
10485760 bytes (10 MB, 10 MiB) copied, 0.0176384 s, 594 MB/s

$ dd if=rand1Mx10.dat of=1Mx10copy_nbs.dat  status=progress
10485760 bytes (10 MB, 10 MiB) copied, 0.083932 s, 125 MB/s

$ dd if=rand1Mx10.dat of=1Mx10copy_333.dat bs=333 status=progress
10485760 bytes (10 MB, 10 MiB) copied, 0.0649439 s, 161 MB/s

$ dd if=rand1Mx10.dat of=1Mx10copy_pi.dat bs=314159265 status=progress
10485760 bytes (10 MB, 10 MiB) copied, 0.0103404 s, 1.0 GB/s

出去：

$ shasum /tmp/*.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/1Mx10copy_1M.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/1Mx10copy_333.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/1Mx10copy_3M.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/1Mx10copy_nbs.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/1Mx10copy_pi.dat
9303b1c6a72ab0ed4c6d7f091ec9f16b8c5ecda1  /tmp/rand1Mx10.dat


$ ls -l *.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:15 1Mx10copy_1M.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:16 1Mx10copy_333.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:14 1Mx10copy_3M.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:15 1Mx10copy_nbs.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:17 1Mx10copy_pi.dat
-rw-rw-r-- 1 mike mike 10485760 Feb 15 09:11 rand1Mx10.dat

一切都检查完毕。dd报告相同的字节数。文件大小匹配。哈希值排队。dd知道一旦用完输入文件或用完空间就停止写入。为了彻底起见，让我们再做一次，我们将创建一个有点太小的文件系统：

制作一个 10MB 的文件：

$ dd if=/dev/zero of=/tmp/myfs.img bs=1M count=10

将其变成文件系统：

$ mkfs.ext4 myfs.img

挂载它（使用root）

$ sudo mount myfs.img /mnt/myfs
$ sudo chown -R $USER:$USER /mnt/myfs

查看空间（由于元数据、索引节点等原因，它小于文件大小：

$ df -h /mnt/myfs 
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      8.7M   92K  7.9M   2% /mnt/myfs

向其中写入 10MB：

$ dd if=rand1Mx10.dat of=/mnt/myfs/1Mx10copy_pi.dat bs=314159265 status=progress
dd: error writing '/mnt/myfs/1Mx10copy_pi.dat': No space left on device
0+1 records in
0+0 records out
8269824 bytes (8.3 MB, 7.9 MiB) copied, 0.205584 s, 40.2 MB/s

空间不足，但它不会“写入超出”，因为从内核的角度来看，没有其他地方可写入。它与以前的文件不同（因为我们截断了它）：

$ shasum /mnt/myfs/1Mx10copy_pi.dat 
2c7330b75e1fa573de4d13ce3c7cbcad8139454d  /mnt/myfs/1Mx10copy_pi.dat

但是当我们克隆整个“设备”时（注意更大的块大小）

$ dd if=myfs.img of=myfs2.img bs=1G status=progress
0+1 records in
0+1 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0255448 s, 410 MB/s
$ sudo mkdir -p /mnt/myfs2     
$ sudo mount myfs2.img /mnt/myfs2
$ shasum /mnt/myfs2/1Mx10copy_pi.dat
2c7330b75e1fa573de4d13ce3c7cbcad8139454d  /mnt/myfs2/1Mx10copy_pi.dat

我们得到一份原始副本。

答案2

最好的办法是在备份之前对所有文件运行 MD5 哈希值，然后进行恢复并检查它们的 MD5 哈希值。

dd if=imagefile.img of=/dev/sda1 bs=4M

您甚至可以尝试 16M 或更大。只需确保偶尔检查 MD5 哈希值即可。

数据不一致可能是由许多不同的原因引起的，我怀疑 BS 选项本身会导致它们，通常这取决于机器在备份期间正在做什么，这可能会导致数据不一致。

相关内容