这个ddrescue命令有什么作用吗？

在尝试从出现故障的硬盘驱动器中恢复数据的过程中，我正在运行命令ddrescue。

该命令已经运行了9天，从磁盘活动的声音中我认为它可能正在做某事。一直以来，命令行输出看起来或多或少是静态的：

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

一直在变化的一部分是它所说的ipos和opos。起床大约需要9天500000 MB，这是发生故障的磁盘驱动器的大小。但是，到达目的地后，它回落至最低点0并再次开始上升。在我写这篇文章的时候，它是在不断增加2580 MB。

正在创建的图像文件的长度为0个字节。

日志文件大小约为3MB，如下所示：

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

我开始担心这只是浪费时间，根本没有恢复任何数据。

此输出是否表明正在发生有用的事情？

是否有任何理由让ddrescue命令按原样继续执行，还是应该停止它并执行其他操作？

这是最新的内容 /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

我不知道您是否仍在尝试从该硬盘驱动器中提取数据，或者您是否已经成功，但是如果您不成功并且想尝试一下，看看是否可以恢复（也许丢失了）比特币或其他，我对您的ddrescue命令行参数做了一些修改，我添加了以下内容：

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d告诉ddrescue使用直接磁盘访问，
• --force告诉ddrescue强制使用和读取/写入日志文件，以防万一抱怨无法将其用于读取/写入目的
• -R（是的，使用CAPITAL R），它告诉您ddrescue以反向方式执行恢复操作，而不是以正向模式读取发生故障的硬盘驱动器。有时，当损坏严重时，反向读取会有所帮助，因为如果硬盘出现问题，它将绕过硬盘的缓存。

目前，我正在使用这些命令（除非我不使用该3命令，因为我不希望[YET] ddrescue重试坏扇区，在完成第一次扫描后，我将把该命令保留下来，并获得了很大的成功）我的1TB Seagate发生故障的硬盘驱动器上的数据是I ASSUME可能持有我可能在2009年至2010年开采的一些比特币，可能我发现了1-3个50 BTC的区块，我希望它位于此硬盘驱动器上，以平均634 kbps的读取速率，我总共要花费15天以上的时间才能完成操作。

另外，我想补充一下，根据您过去9天“上次读取活动”的记录，您可能而且很可能会遇到这样的情况，硬盘将拒绝进一步读取数据：在这种情况下，由于使用的是日志文件，请按CTRL + C取消，将SATA电缆从出现故障的硬盘驱动器上拔下，但不要将USB控制器从USB端口上拔下（是的，请使用USB SATA控制器而不是将其连接到主板，这样就不会锁定整个计算机，从而迫使您硬重启，然后重新插入SATA电源以重新启动硬盘驱动器，等待10秒钟，然后按向上或向下箭头重新加载上一个终端命令并重新启动ddrescue操作，由于您以前的日志，它将在上次中断的地方继续，并且将完成读取，并且“上次成功读取”应始终保持在应为的“ 0s”（零秒），表示ddrescue在从硬盘驱动器读取数据，并且如果您发现“最后一次读取”开始计数秒数，只需再次ddrescue用CTRL+ 终止C，重新启动硬盘驱动器，然后重新启动ddrescue，没有必要等着看“最后一次读取”是否会自行重新恢复为0，根据我的经验，这永远不会发生，您将等待永恒。我必须将坏的1 TB硬盘驱动器重新开机总共进行大约20次，好像是7天，我已经接近恢复到500GB的水平，还有一半的路要走，希望我不会遇到任何重大故障，因为我接近100％，因为在过去3天中，它一直以634 kbps以上的速度完美运行。

另外，不要为获得更快的数据吞吐量读取率而感到贪婪，因为我尝试许多参数和不同块大小的尝试几乎使我陷入了彻底死路，在重启电源后一秒钟内将停止工作（那是5天前），但值得庆幸的是，它再次开始显示生命迹象，最初的读取速度为2,000 bs（是每秒BYTES），略低于2kbps，我非常失望，但是取消后ddrescue使用CTRL + C并再次将其重新启动（添加-R相反），然后速度回到630，在以930 kbps的速度向前读取之前，至少我对我正在反向进行630 kbps感到满意并且不必以2 kbps的速度延迟，因此，如果您在任何读取速度下都取得了成功，例如在500 kbps的范围内坚持使用它，并且不尝试任何将速度提高到更高的尝试，这可能是您最后一次成功获得任何读取速度。

另外，如果ddrescue对您不利，因为无论您尝试使用什么参数都无法读取任何内容，则可能要考虑从硬盘驱动器上更换逻辑板，因为90％的时间都是逻辑板不好，但是首先，取下逻辑板，并清理所有与硬盘驱动器引脚相连的触点，有时这些触点中混入了黑色的粘糊糊，切断了触点，这可能是导致故障的原因。但是请注意，如果必须更换硬盘驱动器的逻辑板，则必须获得相同品牌，序列号（相近），型号，修订号之一，因为它必须与原始版本相近。捐助委员会工作。

您应该能够停止，ddrescue因为它使用日志文件能够重新开始其操作（靠近它所在的位置）。但是，我将通过查看时间戳或执行操作来检查日志文件是否最近已更新tail -f /home/dave/recovery_usb500.logfile。

您的映像文件仍然很小，可能与从驱动器中成功检索到的块没有关系。但是，在所有这些时间运行之后，这将是一个糟糕的结果。假设设备上只有几个坏块，而且这些坏块不在开头，则您的第一个条目状态为+。IIRC ddrescue开始读取，直到发现错误，然后开始拆分光盘的其余部分。您的光盘似乎从一开始就失败了。

除非+日志中有（多个）条目，并且您的文件大小仍然是0我认为ddrescue没有错。并不+意味着驱动器中的任何内容都无法恢复。这可能意味着油炸的电子产品或坏头，因为如果只有几个扇区出现故障，您将可以更快地得到结果。

至于做其他事情。我假设您已经尝试使用正常的dd读取一些块。您是否基于此查看了syslog并在其中搜索了所有消息？

搜索“结果：hostbyte =无效的驱动程序字节= DRIVER_SENSE”会产生一些有趣的读物（部分为德语），并提供一些其他建议：

• 尝试通过USB 1.1而不是2.0连接
• 驱动器可能会变热，因此将其包裹在塑料中，然后放入冰箱中10分钟，这样可以在驱动器再次加热之前提供一定的可读性。
• 在BIOS中切换SMART（并与SATA连接）。
• 确保USB驱动器有足够的电源（额外的电源）
• 如果一段时间后无法通过USB读取，请使用远程控制的USB集线器，在其中以编程方式将USB HUB的电源切换到驱动器上几秒钟。

除了用冷却喷雾冷却不可读的磁盘外，我自己都没有尝试过这些方法。