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

У меня был сбой жесткого диска на 500 ГБ около 5 дней назад. Я использовал 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 подсчитывает, сколько данных им нужно обработать, и, похоже, работает со скоростью 750 МБ / час. В этом случае он завершится через ~ 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, Асо

Вероятно, -n(без разделения) всегда следует использовать для одного первого прохода в прямом и обратном направлениях. Кажется, что чем больше данных было разделено, тем медленнее клонирование, хотя я не уверен в этом. Я предполагаю, что чем больше необработанные области, тем лучше при 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.

Сначала найдите PID для процесса ddrescue, используя «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

Затем запустите «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» соответствует «объему данных, которые все еще необходимо обработать на том диске 2 ТБ, который вы пытаетесь спасти». (Да. Ой.) Ddrescue выдает аналогичное число - хотя и "1720 ГБ" - в своем выводе на экран.

strace дает вам НАМНОГО более высокую степень детализации потока данных для изучения; это еще один способ оценить скорость ddrescue и оценить дату завершения.

Запускать его постоянно, вероятно, плохой план, поскольку он конкурирует с ddrescue за процессорное время. Я взял трубку в "голову", чтобы я мог получить первые 10 значений:

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

Надеюсь, это кому-нибудь поможет.

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

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

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

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

В какой файловой системе жесткого диска вы сохраняете образ восстановления и файл журнала? Я только что испытал, что восстановление внутреннего жесткого диска емкостью 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), но все еще работает. еще не пробовал ddrescue.