有没有办法加快ddrescue？

Question

大约 5 天前，我的 500GB 驱动器硬盘崩溃。我ddrescue前几天在重要分区上用过，现在“修剪失败块”已经快2天了。

原始命令：

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

电流输出：

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

原始命令使用了该ddrescue -n参数，并且我根据需要重新启动了该过程几次（并且似乎每次都从它停止的地方开始）。

有什么办法可以加快这个过程吗？

编辑：六个小时后，这是当前状态：

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

看起来，虽然“错误”倒计时非常缓慢，但 ipos/opos 正在倒计时它必须处理的数据量，它似乎以 750MB/小时的速度运行。按照这个速度，它将在大约 53 小时内完成。哎呀。

编辑＃2：两天后，仍在运行。然而，还有希望。它已经通过了“修剪失败块”部分，并进入下一阶段“拆分失败块”。如果有的话，从查看这个问题应该带走的是，当涉及大量数据/错误时，这肯定需要很长时间。我唯一的希望是，当一切都完成后，我可以成功恢复一些重要数据。

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

Answer 1

我观察到将-n(no-split) 选项与-r 1(retry once)一起使用并将-c(cluster size) 设置为较小的值会有所帮助。

我的印象是分裂步骤非常缓慢，因为ddrescue分裂并再次分裂受损区域。这需要很多时间，因为ddrescue尝试恢复非常小的数据部分。所以，我更喜欢将-n(no-split) 与-c 64, -c 32, -c 16, aso一起使用

可能-n(no-split) 应该始终用于正向和反向的第一次传递。似乎数据分割得越多，克隆越慢，尽管我不确定这一点。我假设未处理的区域越大，ddrescue再次运行时最好，因为要克隆更多连续的扇区。

由于我正在使用日志文件，因此当数据读取速度降低两倍时，我会毫不犹豫地使用Ctrl+取消该命令C。

我也使用-R（反向）模式，在第一次通过后，它通常会给我比向前读取更快的反向读取速度。

我不清楚-r N在ddrescue再次运行命令时如何处理已重试的扇区 ( ) ，尤其是在交替向前（默认）和反向 ( -R) 克隆命令时。我不确定他们尝试的次数是否存储在日志文件中，并且可能这些工作再次无用。

可能-i（输入位置）标志也可以帮助加快速度。

Answer 2

可能很难看到 的进度ddrescue，但还包含另一个名为ddrescuelog.

一个简单的命令ddrescuelog -t YourLog.txt将输出这些不错的信息：

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

您甚至可以在ddrescue运行时使用它...

Answer 3

如果您的目标是完整地获取大量数据，那么您可以加快提取速度。但是如果你真的想尽可能多地挽救数据，那么让 ddrecue 蚕食每一个是要走的路。

Answer 4

我发现使用 -K 参数可以加快速度。从我所看到的 ddrescue 在使用 -n 选项运行时是否发现错误尝试跳转固定数量的扇区。如果它仍然无法读取，它会跳两倍大小。如果你有大的损坏区域，你可以指定一个大的 K 值（例如 100M），这样第一次错误的跳跃会更大，并且在第一次快速避开有问题的区域会更容易。

顺便说一句，有一个很棒的图形应用程序来分析日志。

http://sourceforge.net/projects/ddrescueview/