所以最近我们有一个快要死的硬盘驱动器，我们试图从使用中复制所有数据safecopy。我能找到的文档以及任何指南都指定safecopy输出必须是图像文件。该命令已处理，但仅XXX作为输出产生，表明数百和数千个块的读取不成功。显然这是不正确的，因为驱动器仍然可以安装并且大多数文件都是可读的。接下来我重试，指定 HDD 分区 ( /dev/sdb2) 作为输出，正如有人建议的那样（我再也找不到该线程了，那是一个多星期前的事了）。命令运行，输出成功读取，预计在 5 天多的时间内完成。
现在驱动器上有所有恢复的数据，但分区已变得无法读取。我们无法重复恢复，因为损坏的驱动器很快就死掉了（磁头崩溃，而且是一个相当暴力的情况），我们必须以某种方式从另一个 HDD 获取数据，自从命令完成并写入以来，该数据肯定就在那里隔断上方。是否有可能以某种方式检索它？我在想，如果预期目标是一个.img文件，那么将原始数据从设备文件复制到 with.img可能dd会给我们带来该命令应该让我们开始的“预期结果”（即safecopy在文件形式.img而不是在设备上），但dd在操作进行了百分之几后就冻结了，甚至在几个小时后也没有恢复。
由于在易失性系统上运行，确切的副本和输出丢失了，但根据我记得的设备和参数，它一定是丢失的sudo safecopy --stage1 -b 4096 -R 2 /dev/sda2 /dev/sdb2，即执行第一阶段副本，并从/dev/sda2（损坏）到dev/sdb2（备份）添加了两次重试，两者都有块大小为 4096 字节。...据我所知，输出大部分产生，表明块读取成功。输出结束时safecopy通知我它已成功完成，写入了约 3TB 的数据。
sudo file -s /dev/sdb2仅产生错误消息/dev/sdb2: ASCII text, with very long lines, with no line terminators，重试可以hexdump -C /dev/sdb2更深入地了解设备上的内容：
00000000 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
01000030 42 61 44 62 4c 6f 43 6b 10 00 00 00 4c 6f 43 6b |BaDbLoCk....LoCk|
01000040 c4 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
01000050 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
0101ef10 c8 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
0101ef20 c9 7b 00 00 ca 7b 00 00 cb 7b 00 00 cc 7b 00 00 |.{...{...{...{..|
0101ef30 cd 7b 00 00 ce 7b 00 00 cf 7b 00 00 d0 7b 00 00 |.{...{...{...{..|
0101ef40 d1 7b 00 00 d2 7b 00 00 d3 7b 00 00 d4 7b 00 00 |.{...{...{...{..|
其余的行看起来就像正常的磁盘数据，奇怪的是，尽管声称至少前几千个块都已成功读取，但第一行却hexdump显示坏块。safecopy