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

Question

У меня был сбой жесткого диска на 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...

Answer 1

Я заметил, что использование опции -n (без разделения) вместе с -r 1 (повторите попытку) и установкой -c (размер кластера) на меньшее значение может помочь.

У меня сложилось впечатление, что шаг разделения очень медленный, поскольку ddrescue разделяет и снова разделяет поврежденные области. Это занимает много времени, потому что ddrescue пытается восстановить очень маленькие порции данных. Поэтому я предпочитаю использовать -n (без разделения) вместе с -c 64 , -c 32 , -c 16 , aso

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

Поскольку я использую файл журнала, я без колебаний отменяю команду с помощью Ctrl+C, когда скорость чтения данных становится низкой.

Я также использую режим -R (Reverse), и после первого прохода он часто дает мне большую скорость чтения назад, чем вперед.

Мне не ясно, как обрабатываются уже повторные секторы (-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

Еще один способ отслеживать прогресс 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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Похоже, exFat не очень хорошо играет с очень большими файлами (несколько сотен гигабайт).

Answer 7

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

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

Answer 8

Для более быстрого и быстрого восстановления диска вы можете использовать файл сценария 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 один раз, чтобы развернуть и удалить все ошибки и снова начать обратно. Значит он будет читать ошибки по-разному.