有没有办法加快ddrescue？

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

原始命令：

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

我观察到使用了 -n （无拆分）选项和 -r 1 （重试一次）和设置 -c （簇大小）到较小的值可以帮助。

我的印象是，分裂步骤非常缓慢 ddrescue 再次分裂和分裂受损区域。这需要花费很多时间，因为 ddrescue 尝试恢复非常小的数据部分。所以，我更喜欢使用 -n （不分裂）与 -c 64， -c 32， -c 16，a.s.o。

可能是 -n （no-split）应始终用于正向和反向的第一次通过。似乎数据分割越多，克隆越慢，尽管我不确定这一点。我假设未经处理的区域越大，跑步时最好 ddrescue 再次，因为更多的连续部门要克隆。

因为我正在使用日志文件，所以我会毫不犹豫地取消命令 按Ctrl + C 当数据读取速度变为两个低时。

我也用了 -R （反向）模式并且在第一次通过之后它通常使我向后读取比向前更高的速度。

我不清楚已经重试的部门（ -r N ）运行时处理 ddrescue 再次命令，特别是交替前进（默认）和反向（ -R ）克隆命令。我不确定他们被尝试的次数是否存储在日志文件中，并且可能再次完成工作无用。

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

很难看到它的进展 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 在跑...

监视ddrescue进度的另一种方法（至少在Linux上）是通过使用strace。

首先，使用“ps aux | grep ddrescue”找到ddrescue进程的PID

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

然后针对该过程运行“strace”。你会看到类似的东西：

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...等等。输出是快速和丑陋的，所以我然后通过“grep”管道来过滤掉我关心的东西：

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

在该示例中，“1702212676608”等同于“您试图挽救的2Tb磁盘上仍需要处理的数据量”。 （是的。哎哟。）ddrescue在其屏幕输出中吐出一个类似的数字 - 尽管是“1720 GB”。

strace为您提供更高粒度的数据流供您检查;这是评估ddrescue速度和估计完成日期的另一种方法。

不断运行它可能是一个糟糕的计划，因为它会与ddrescue竞争CPU时间。我已经把它管到“头”，所以我可以抓住前10个值：

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

希望这有助于某人。

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

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

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

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

保存救援映像和日志文件的硬盘文件系统是什么？我刚刚通过USB记忆棒在运行Linux Mint的笔记本电脑上拯救了500GB内置硬盘（通过SATA连接），将救援图像和日志文件保存在 exFat 格式化的USB硬盘驱动器启动速度相当慢（1-2MB /秒），但在250GB左右之后，只能以<100KB /秒的速度爬行。救援图像文件越大，似乎越慢。

然后我将救援图像和日志文件移动到另一个临时位置，重新格式化USB硬盘驱动器 ext4 文件系统，将文件移回其上并恢复ddrescue进程 - 现在它再次以1-20MB /秒的速度运行（波动但平均大约7MB /秒）！

似乎 exFat 使用非常大的文件（几百千兆字节）不能很好地播放。

要获得更快更快的拯救光盘选项，您可以使用sh脚本文件并使用“sh filename.sh”运行该文件。它包含显示的这一行，只需重复几次“sudo ddrescue”和“sleep 3”，睡眠用于使驱动器休息几秒钟，它可能有一些原因：

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

-r0没有回复。 -e +0用于退出1错误。 -T 1s以1秒的失败读取退出。有些选项可以用作-d用于直接和-n用于无刮，可以加速。

完成选项-A一次后，您可以使用-R，这将反转并删除所有错误大小并再次向后重新开始。意味着它会以不同方式读取错误

dd_rhelp 是一个在整个光盘上使用dd_rescue“[...]的shell脚本，但它会尝试收集最大的有效数据，然后再尝试使用一串badsectors”

这是相当古老的（2012年），但仍然有效。尚未尝试过ddrescue。