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

Question

在尝试从发生故障的硬盘驱动器恢复数据的过程中，我正在运行该命令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

Answer 1

我不知道您是否仍在尝试从该硬盘驱动器中提取数据，或者您是否已经成功，但如果您没有成功并想尝试一下，看看您是否可以恢复，也许，丢失了比特币或其他任何东西，我对您的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 希捷硬盘上的数据出现故障，我假设我可能持有一些比特币，我可能在 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。

另外，不要贪婪地尝试获得更快的数据吞吐量读取速率，因为我尝试尝试许多参数和不同的块大小几乎给我留下了一个完全死机的硬盘驱动器，它会在电源循环后 1 秒内停止工作（那是 5 天前）但幸运的是它再次开始显示出生命的迹象，最初以 2,000 bs（是每秒字节）读取，略低于 2kbps，我非常失望，但取消后ddrescue使用 CTRL + C 并再次重新启动它（与添加 -R 参数相反），然后速度回到 630，然后我以 930 kbps 正向阅读，至少我很满意我正在反向执行 630 kbps并且不必推迟使用 2kbps，所以如果您在任何读取速度下获得成功，例如在 500 kbps 范围内坚持使用它并且不要尝试任何提高速度的方法，这可能是您获得的最后一次成功尝试任何阅读速度。

或者，如果ddrescue这对您没有好处，因为无论您尝试什么参数都无法读取任何内容，您可能需要考虑更换硬盘驱动器上的逻辑板，因为 90% 的时间是逻辑板坏，但首先，取下逻辑板并清洁所有与硬盘驱动器针脚接触的触点，有时这些触点会在其中混入黑色粘稠混合物，切断可能导致故障的触点。但请注意，如果您必须更换硬盘驱动器的逻辑板，您将必须获得相同品牌、序列号（接近）、型号、修订号之一，因为它必须与原始硬盘一样接近捐助委员会工作。

Answer 2

您应该能够停止，ddrescue因为它使用日志文件能够重新启动它的操作（关闭）到它离开的地方。但是，我会通过查看时间戳或执行tail -f /home/dave/recovery_usb500.logfile.

您的图像文件仍然那么小可能与尚未从驱动器中成功检索到任何块有关。然而，经过这么长时间的运行，这将是糟糕的结果。假设设备上只有几个坏块，并且它们不在开头，那么您的第一个条目状态将是+。IIRCddrescue开始读取直到发现错误，然后开始分割光盘的其余部分。您的光盘似乎从一开始就失败了。

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

至于做别的事情。我假设您已经尝试使用普通 dd 读取几个块。您是否查看了基于此的 syslog 并搜索了您在那里找到的任何消息？

搜索“结果：hostbyte=invalid driverbyte=DRIVER_SENSE”会得到一些有趣的内容（部分是德语），还有一些建议：

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

除了冷却无法读取的磁盘（使用冷却喷雾）之外，我自己还没有尝试过任何这些。