Как оценить циклы / время для завершения GNU ddrescue (1.18.1), используя текущий статус?

9

Предпосылки / Контекст:

В настоящее время я использую GNU ddrescue 1.18.1 для восстановления данных с USB, который испытал отсоединение кабеля, когда я записывал образ виртуального диска в раздел disk2s1. Сначала я восстанавливаю свой второй раздел (disk2s2) и замечаю, что достиг третьего этапа (разделение). Я помещаю изображение в сетевое хранилище.

Вопрос:

Я заметил, что эта фаза зацикливается. Есть ли способ рассчитать количество циклов, которые я могу испытать, учитывая информацию о моем текущем состоянии (я показываю только две ошибки)?

Положение дел:

положение дел

Обновление / Edit:

Поэтому мне все еще очень интересно, как можно оценить циклы / время завершения, используя инструмент ddrescue. Согласно комментариям, я добавляю оценку файла журнала для моего раздела disk2s1, так как он запущен в данный момент (disk2s2 завершился через 14,5 часов, с одним прерыванием пользователя на 6 часов).

part1-журнал

Журнал завершенных разделов

Для раздела, который только что завершен, вот результат проверки журнала.

фото-журнал

Ссылка (примечания к алгоритму ddrescue):

4 Алгоритм


GNU ddrescue не является производной от dd и никак не связана с dd, за исключением того, что оба могут использоваться для копирования данных с одного устройства на другое. Основное отличие состоит в том, что ddrescue использует сложный алгоритм для копирования данных с неисправных дисков, что наносит им как можно меньше дополнительного ущерба.

Ddrescue эффективно управляет состоянием выполняемого спасения и пытается спасти хорошие части в первую очередь, планируя чтения в плохих (или медленных) областях на потом. Это максимизирует объем данных, которые могут быть окончательно восстановлены с неисправного диска.

Стандартная утилита dd может использоваться для сохранения данных с неисправного диска, но она считывает данные последовательно, что может привести к износу диска, не спасая ничего, если ошибки возникли в начале диска.

Другие программы считывают данные последовательно, но при обнаружении ошибок переключаются на считывания небольшого размера. Это плохая идея, потому что это означает проводить больше времени в местах с ошибками, повредить поверхность, головки и механику привода, вместо того, чтобы вырываться из них как можно быстрее. Такое поведение снижает шансы на спасение оставшихся хороших данных.

Алгоритм ddrescue заключается в следующем (пользователь может прервать процесс в любой момент, но имейте в виду, что неисправный диск может блокировать ddrescue на долгое время, пока ядро ​​не сдастся):

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

2) (Первая фаза; Копирование) Считайте непробованные части входного файла, пометив сбойные блоки как необрезанные и пропустив их. Пропустить также за медленные области. Пропущенные области пробуются позже в двух дополнительных проходах (перед обрезкой), меняя направление после каждого прохода, пока не будет опробована вся область спасения. Третий проход - это быстрый проход с отключенным пропуском. (Цель состоит в том, чтобы быстро отграничивать большие ошибки, сохранять небольшой размер файла журнала и создавать хорошие отправные точки для обрезки). Только непроверенные области читаются большими блоками. Обрезка, расщепление и повторные попытки выполняются по секторам. Каждый сектор испытывается не более двух раз; первый на этом шаге (обычно как часть чтения большого блока, но иногда как чтение одного сектора), второй на одном из шагов ниже как чтение одного сектора.

3) (Вторая фаза; обрезка) Считывание вперед по одному сектору за один раз от переднего края наименьшего необрезанного блока до тех пор, пока не будет найден плохой сектор. Затем читайте назад один сектор за раз от заднего края того же блока, пока не будет найден плохой сектор. Для каждого необрезанного блока пометьте поврежденные сектора, найденные как поврежденные, и пометить оставшуюся часть этого блока как неразделенные, не пытаясь прочитать их. Повторяйте, пока не останется больше необрезанных блоков. (Большие необрезанные блоки создаются путем объединения меньших блоков, и поэтому их доля полезных данных по краям меньше).

4) (Третья фаза; Разделение) Считывание вперед одного сектора за раз из центра самого большого неразделенного блока, пока не будет найден плохой сектор. Затем, если найденный плохой сектор не первый, который пытался выполнить, считывайте назад по одному сектору за раз из центра того же блока, пока не будет найден плохой сектор. Если файл журнала больше, чем «--logfile-size», последовательно считывайте самые большие неразделенные блоки, пока количество записей в файле журнала не опустится ниже «--logfile-size». Повторяйте, пока все оставшиеся неразделенные блоки не будут иметь менее 7 секторов. Затем прочитайте оставшиеся неразбитые блоки последовательно.

5) (Четвертая фаза; повторная попытка) При желании попробуйте снова прочитать поврежденные сектора, пока не будет достигнуто указанное количество повторных попыток. Каждый плохой сектор пробуется только один раз за каждый проход. Ddrescue не может знать, является ли неисправный сектор невосстановимым или он будет в конечном итоге прочитан после некоторых попыток.

6) При желании напишите файл журнала для последующего использования.

Общий размер ошибки («errsize») является суммой размеров всех необрезанных, неразделенных и поврежденных блоков. Оно увеличивается во время фазы копирования и может уменьшаться во время обрезки, разделения и повторной попытки. Обратите внимание, что по мере того, как ddrescue разделяет отказавшие блоки, делая их меньше, общий размер ошибок может уменьшаться, а количество ошибок увеличивается.

Файл журнала периодически сохраняется на диск, а также когда ddrescue завершается или прерывается. Так что в случае аварии вы можете возобновить спасение с небольшим повторным копированием. Интервал между сохранениями варьируется от 30 секунд до 5 минут в зависимости от размера файла журнала (большие файлы журнала сохраняются с более длительными интервалами).

Кроме того, один и тот же файл журнала можно использовать для нескольких команд, которые копируют разные области входного файла, и для нескольких попыток восстановления в разных подмножествах. Смотрите этот пример:

Сначала спасите самую важную часть диска. ddrescue -i0 -s50MiB / dev / hdc файл журнала hdimage ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage файл журнала

Тогда спасите некоторые ключевые области диска. ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

Теперь спасите остальных (не переписывает то, что уже сделано). ddrescue / dev / hdc hdimage logfile ddrescue -d -r3 / dev / hdc hdimage logfile

Томми С.
источник
диск все еще подключен под тем же именем устройства? Также вам может понадобиться, ddrescueтолько если на диске имеются поврежденные блоки, которые не будут вызваны «отключением кабеля». Если у вас проблемы с кабелем, попробуйте другой кабель ...
frostschutz
@TommieC. ты можешь попробовать ddrescuelog -t YourLog.txtв другом терминале?
Simply_Me
@Simply_Me Пожалуйста, смотрите обновленный вопрос, отражающий два результата.
Томми С.
@frostschutz Пожалуйста, смотрите обновленный вопрос для более подробной информации. Потерянное кабельное соединение произошло во время записи диска и вызвало проблемы с таблицей разделов. Сам кабель не поврежден.
Томми С.
Отключение кабеля обычно вызывает логические ошибки (т. Е. Данные на диске не являются действительными на 100%), но не приводит к физическим проблемам с диском - если вы не уронили его одновременно. ddrescueможет только попытаться восстановить физические проблемы и не поможет с логическими ошибками вообще. Для последнего, попробуйте fsckили так ..
Udo G

Ответы:

6

Несмотря на то, что вопрос был задан 10 месяцев назад, ответ может быть актуальным, поскольку цикл восстановления может продолжаться в зависимости от нескольких факторов! Не каламбур предназначен.

Причина в том, что оценка времени практически невозможна, однако иногда можно получить приблизительное представление о следующем. Одна из наиболее очевидных причин заключается в том, что вы не можете предсказать, сколько времени потребуется накопителю для чтения поврежденного сектора, и если вы хотите, чтобы ddrescue прочитал и повторил каждый из них, то это может занять очень много времени. Например, в настоящее время я использую восстановление на маленьком диске объемом 500 ГБ, которое продолжается уже более 2 недель, и, возможно, у меня осталось несколько дней. Но у меня более сложная ситуация, потому что диск зашифрован и для успешного чтения чего-либо я должен получить все сектора, в которых есть таблицы разделов, загрузочные сектора и другие важные части диска. Я использую методы в дополнение к ddrescue, чтобы улучшить свои шансы для всех плохих секторов. IOW,

По оценке «циклов», если вы имеете в виду количество повторов, то это то, что вы определяете по параметрам, которые вы используете. Если вы имеете в виду «общее количество проходов», это легко определить, прочитав об алгоритме здесь .. > man ddrescue </ Algorithm: как ddrescue восстанавливает данные

Я специально буду говорить с цифрами на скриншотах, которые вы предоставили. В других ситуациях могут применяться другие факторы, поэтому используйте эту информацию в качестве общего руководства.

В приведенном вами примере взгляните на экран состояния работы ddrescue. Мы получаем общую «оценку» проблемы (область спасения) по «errsize». Это количество данных, которые «еще предстоит прочитать». В образце это 345 ГБ. Следующая строка ниже справа - «средняя ставка». В образце это 583kb / s

Если «средняя ставка» должна была оставаться близкой к постоянной, это означает, что у вас есть еще 7 дней. 345 ГБ / (583 КБ * 60 * 60 * 24) = 7,18 Однако проблема в том, что вы не можете полагаться на 583 КБ / с. На самом деле, чем глубже вы переходите к восстановлению, тем медленнее становится накопитель, поскольку он читает все более сложные области и выполняет больше попыток. Так что время финиша экспоненциально увеличивается. Все это зависит от того, насколько сильно поврежден диск.

Приведенный вами пример показывает, что «успешное чтение» было более 10 часов назад. Это говорит о том, что он действительно ничего не получает от привода в течение 10+ часов. Это показывает, что на вашем диске может быть записано 345 ГБ (или часть) данных. Это очень плохие новости для вас.

Напротив, мой второй диск на 500 ГБ, который только что начал выдавать мне ошибки «SMART», был скопирован с диска на диск (с файлом журнала на другом диске), и вся операция заняла около 8-9 часов. Последняя часть замедлилась. Но это все еще терпимо. В то время как очень плохой диск, как отмечалось выше, уже более 2 недель работает на 500 ГБ, и ему еще остается около 4-5% для восстановления.

HTH и YMMV

LMSingh
источник