Есть ли способ ускорить ddrescue?

Это может быть очень трудно увидеть прогресс 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работы ...

Если ваша цель - получить большую часть данных без изменений, вы можете ускорить их извлечение. Но если вы действительно хотите спасти как можно больше данных, то путь к ddrecue - это путь.

Я обнаружил, что играя с параметром -K, вы можете ускорить процесс. Из того, что я видел, обнаруживает ли ddrescue ошибку при запуске с опцией -n, пытается перескочить фиксированное количество секторов. Если он все еще не может прочитать, он прыгает вдвое больше. Если у вас есть большие поврежденные области, вы можете указать большое значение K (например, 100M) и, таким образом, скачок на ошибку будет больше в первый раз, и в первом прошлом будет легче быстро избежать проблемных областей.

Кстати, есть замечательное графическое приложение для анализа логов.

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

One more way to monitor ddrescue's progress (on Linux, at least) is through the use of strace.

First, find the PID for the ddrescue process using "ps aux | grep ddrescue"

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 

Then run "strace" against that process. You'll see something like:

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 

...and so on. The output is fast and ugly, so I then pipe it through "grep" to filter out the stuff I care about:

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 

In that example, the "1702212676608" equates to "the amount of data that still needs to be processed on that 2 Tb disk you're trying to salvage." (Yeah. Ouch.) ddrescue is spitting out a similar number -- albeit as "1720 GB" -- in its screen output.

strace gives you a MUCH higher granularity data stream for you to examine; it's one more way to evaluate the speed of ddrescue and estimate a completion date.

Running it constantly is probably a bad plan since it would compete with ddrescue for CPU time. I've taken to piping it to "head" so I can grab the first 10 values:

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

Hope this helps someone.

В какой файловой системе жесткого диска вы сохраняете образ восстановления и файл журнала? Я только что понял, что восстановление внутреннего жесткого диска емкостью 500 ГБ (подключенного через SATA) на ноутбуке, работающем под управлением Linux Mint, с USB-накопителя, сохранение образа восстановления и файла журнала на exFatотформатированном жестком диске USB начиналось довольно медленно (1-2 МБ / сек), но примерно после 250 ГБ он полз со скоростью <100 КБ / с. Казалось, что чем медленнее становился файл спасательного образа, тем медленнее он становился.

Затем я переместил образ восстановления и файл журнала в другое временное место, переформатировал жесткий диск USB с ext4файловой системой, переместил файлы обратно на него и возобновил процесс ddrescue - и теперь он снова работает со скоростью 1-20 МБ / с (колеблется но около 7 МБ / с в среднем)!

Похоже 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 для очистки, что может ускорить.

Вы можете использовать -R после финиша с опцией -A один раз, чтобы развернуть и удалить все ошибки, а затем снова начать обратно. Значит он будет читать ошибки по-разному.

dd_rhelp - это сценарий оболочки, который использует dd_rescue «[...] на весь ваш диск, НО он будет пытаться собрать максимально допустимые данные, прежде чем пытаться целую вечность работать с группами плохих секторов»

Это довольно старый (2012), но все еще работает. еще не пробовал