Спасение жесткого диска с поврежденными секторами: dd vs gddrescue

Где-то в интернете я читал, что gddrescue превосходит dd, по крайней мере, с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе. Это действительно так?

время dd if = / dev / sda skip = 900343967 of = a.bin count = 4 iflag = direct conv = noerror, sync

дд: чтение `/ dev / sda ': ошибка ввода / вывода
2 + 0 записей в
2 + 0 записях,
1024 байта (1,0 кБ) скопировано, 18,6057 с, 0,1 кБ / с
3 + 1 записей в
4 + 0 записей,
2048 скопировано байтов (2,0 кБ), 18,6707 с, 0,1 кБ / с

реальный 0m18.672s
пользователь 0m0.000s
sys 0m0.004s

Кстати, прямой флаг действительно помогает, без него я смог прочитать только 1 сектор из 4 (против 3/4 с ним). Тем не менее, это заметно замедляет скорость передачи - для меня она как минимум примерно в 5 раз медленнее: 5 МБ / с против 25 МБ / с без этого флага. Во всяком случае, теперь для gddrescue (ddrescue) часть ..

время ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b / dev / sda b.bin

Собирается скопировать 2048 байт из / dev / sda в b.bin
Исходные позиции: infile = 460976 МБ, outfile = 0 B
Размер блока копирования: 1 жесткий
блок Размер жесткого блока: 512 байт
Max_retries: 0
Прямой: да Разреженный: нет Разделение: нет нет усекать: нет

Нажмите Ctrl-C, чтобы прервать
спасение: 1536 B, размер ошибки: 512 B, текущая скорость: 53 B / s
ipos: 460976 MB, ошибки: 1, средняя скорость: 53 B / s,
opos: 1536 B, время после последнего успешного чтения: 0 с
закончено

реальный 0m18.736s
пользователь 0m0.004s
sys 0m0.000s

Как показано выше, для выполнения потребовалось столько же времени. Как и ожидалось - такая же статистика: 3/4. Однако, хотя я мог бы заполнить проблемные секторы 0x00 для dd (conv = sync), gddrescue, похоже, не хватает этой функциональности? Вместо этого он просто пропускает проблемный сектор без записи чего-либо на свою позицию и переходит к следующему следующему сектору (если у меня уже есть данные, записанные по этому сектору в выходном файле - это не будет перезаписано: иногда это может быть нежелательно) ). Я не уверен, как опция -t (truncate) будет работать для блочного устройства с gddrescue(Полагаю, он будет полностью перезаписан 0x00), но в обычном файле он, как и предполагалось, обрезает весь файл без выполнения только в пределах измерений смещения (т.е. -o1). Таким образом, это немного похоже на синхронизацию dd , но далеко не то же самое, что будет имитировать только идентичность функциональности, если вы готовы перезаписать все устройство вывода / файл.

Хотя, благодаря наличию подробной опции и возможности регистрировать поврежденные сектора / блоки, gddrescue кажется лучшим выбором. Важно отметить, что оба приложения были запущены с (в значительной степени) одинаковыми параметрами.

Выход из

diff? .bin

пусто (выход 0), то есть файлы точно такие же.

Теперь это часть, которую я не понимаю

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

Что это вообще такое? Особенно часть « она тратит много времени на пережевывание ошибочных частей диска, а не на чтение как можно большего количества безошибочных вещей, ТО, ЧТО вернется к трудным вещам »? Это заняло столько же времени, как показано выше (хотя я проверил очень маленькую порцию данных, но должно ли это иметь значение?).

gddrescue предлагает ключ -r , который должен контролировать количество повторных чтений в «плохом секторе», однако, dd, кажется, все время работает с -r0 (так как это заняло то же время). Итак, эта опция просто для «постобработки»? Я имею в виду , что изначально и dd, и gddrescue, кажется, работают с -r0, и dd , похоже, не пережевывает ошибочные части больше, чем gddrescue (кажется, что оба они останавливаются на плохом блоке на 15-18 секунды дают или берут, так в чем же дело, как быстрее работает gddrescue ???)

Кроме того, для чего нужна опция -D (использовать синхронную запись для выходного файла)? Я не заметил никакой разницы с некоторыми из проведенных испытаний.

Кто-нибудь может прокомментировать все это? Спасибо.

Я не уверен, как цитируемый автор пришел к своему выводу. Я не спорю, прав он или нет, у меня просто нет такого опыта.

С другой стороны, что касается этого заявления ...

gddrescue превосходит dd по крайней мере с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе.

Настоящая «хотя бы» причина использования gddrescue заключается в том, что gddrescue не усекает вывод при повторных попытках чтения / записи. gddrescue также полностью автоматический, в отношении определенных ошибок чтения, которые остановят dd.

Таким образом, цитируемый автор может быть прав, он не может ... но все утверждение пропускает смысл gddrescue.

ОБНОВЛЕНИЕ: Подробные различия между dd и gddrescue.

dd conv = noerror, будет продолжать работать после ошибки, но просто пропустит плохой блок. даже добавление опции синхронизации просто поставит нули вместо пропуска. Если вы используете dd для повторного чтения с использованием того же вывода, вы просто перезапишите / потеряете все, что восстановили ранее.

gddrescue, также будет продолжать работать после ошибки. Он может восстановить частичную доходность из плохого блока, и вернется назад и попытается выполнить блок сектор за сектором. gddrescue будет вести подробный журнал ошибок с хорошими блоками, плохими блоками и сектором за сектором от любых плохих блоков. Если вы попытаетесь выполнить чтение снова, gddrescue отключит (усечет) и добавит все дополнительные восстановленные данные.

Имейте в виду, даже с обоими инструментами, если целый блок на 100% не читается. Вы все равно не получите никаких данных от него. gddrescue потенциально может получить больше данных, если некоторые сектора в блоке остаются читаемыми.

В зависимости от того, когда был изготовлен жесткий диск, а также от производителя и какой версии микропрограммы он работает, с современными жесткими дисками, когда обнаруживаются плохие сектора, они удаляются из микропрограммы, и накопитель знает, как пропустить поврежденные сектора. Таким образом, понятие «спасение» жесткого диска от плохих секторов может быть спорным в этом отношении. Вопрос о том, имели ли теперь плохие секторы когда-то действительные данные, является подходящим решением, которое вы ищете - без каламбура!

На grc.com есть программное обеспечение spinrite 6, которое утверждает, что может исправлять жесткие диски с поврежденными секторами. Это платное программное обеспечение, и я никогда не пробовал его. Об этом стоит прочитать, особенно если кто-то пытается «воскресить» жесткий диск, и он действительно работает, как описано. FAQ на grc.com относительно spinrite 6 указывает на то, что существует 30-дневная гарантия возврата денег (и нет пробной или бесплатной версии). Примечание: я не связан с grc.com и не рекомендую его для вашей ситуации. Я просто знаю, что он существует и может работать как рекламируется, но не верьте мне на слово - будьте бдительны.

Что касается оценки того, превосходит ли gddrescue «dd», по крайней мере, с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе, любое количество операций чтения в поврежденном секторе (поскольку оно помечено как не Мне кажется, что функциональный сектор в списке поврежденных секторов, хранящихся в списке встроенного ПО) не будет полезен при качественном использовании gddrescue или dd.

Может оказаться полезным прочитать веб-страницу dd (Unix) по адресу: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd.

Вам также может быть полезно взглянуть на: Как создать образ поврежденного жесткого диска с помощью UBCD, dd-rescue и P2 eXplorer по адресу: http://www.myfixlog.com/fix.php?fid= 21