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

这个 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... 

一直在变化的部分是它所说的iposopos。花了 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

答案1

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

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d 告诉 ddrescue 使用直接磁盘访问,
  • --force 告诉 ddrescue 强制使用和读/写您的日志文件,以防它抱怨无法将其用于读/写目的
  • -R(是的,大写 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,我非常失望,但在使用ddrescueCTRL + C 取消后,只是再次重新启动它(与-R相反)添加参数,然后速度回到630,然后我以930 kbps的速度向前阅读,至少我满足于我以630 kbps的速度向后阅读并且不必推迟2kbps,所以如果您在任何读取速度(例如在 500 kbps 范围内)获得成功,请坚持下去,不要尝试任何提高速度的方法,这可能是您获得任何读取速度的最后一次成功尝试。

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

答案2

您应该能够停止,ddrescue因为它使用日志文件以便能够重新启动其操作(关闭)到它离开的位置。但是,我会通过查看时间戳或执行以下操作来检查日志文件最近是否已更新tail -f /home/dave/recovery_usb500.logfile

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

+除非日志中有(多个)条目你的文件大小仍然是0我认为没有ddrescue错误的。否+意味着您的驱动器中的任何内容都无法恢复。这可能意味着电子设备损坏或头脑坏了,因为如果只有几个部分出现故障,您会更快地得到结果。

至于干别的事。我假设您已经尝试使用普通 dd 读取几个块。您是否查看过基于此的系统日志并通过谷歌搜索了在那里找到的任何消息?


搜索“结果:hostbyte=invalid driverbyte=DRIVER_SENSE”会产生一些有趣的读物(部分是德语)以及更多建议:

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

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

相关内容