ddrescue очень медленный, пишет в NTFS — стоит ли сейчас конвертировать в Ext4?

Question

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

Сначала он вел себя непредсказуемо, часто внезапно отключался и издавал пугающие звуки, скорость копирования колебалась от нескольких КБ в секунду до примерно 50 МБ в секунду (день был жаркий, я пытался предотвратить его перегрев с помощью охлаждающей подставки для ноутбука снизу и охлаждающего блока сверху, которые я менял примерно каждый час). Затем, в течение первого вечера, он стал более стабильным, но средняя скорость копирования значительно снизилась, примерно до 3-4 МБ/с. Теперь, восстановив 250 ГБ, я снизил среднюю скорость примерно до 400 КБ/с, что мучительно медленно (по крайней мере, похоже, что она не снижается дальше).

Итак, мои вопросы:

• Я делаю это восстановление на раздел NTFS, который, как я прочитал довольно поздно в процессе (наэтот французский путеводитель), не рекомендуется, так как это может значительно замедлить восстановление. Это (все еще) правда, и если да, то почему?
  • Или это осталось в прошлом, когда драйвер NTFS для Linux был недостаточно зрелым? (Я использую последнюю версию Knoppix Live DVD, скопированную на карту памяти, поскольку она не загружается с DVD-RW.)
• Стоит ли на данном этапе тратить силы на преобразование раздела в родной формат Linux, например Ext4? Я имею в виду, значительно ли это улучшит скорость копирования?
  • Или это нормально — испытывать такое замедление при отказе диска после первого прохода, когда большинство «здоровых» секторов уже восстановлено? (Параметры SMART ухудшаются, «результат теста самооценки общего состояния» изменился с «ПРОШЕЛ» на «НЕ ПРОШЕЛ», количество перераспределенных секторов увеличилось со 144 до 1360.)
• Могу ли я сделать что-то еще, чтобы улучшить коэффициент восстановления и/или скорость восстановления?
• Есть ли варианты, ddrescueкоторые я мог бы попробовать и получить реальную пользу?

Первые запуски я выполнил с помощью этой команды:

ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log

( Предположительно, переключатели -n& -Nобходят фазы очистки и обрезки, хотя я не уверен, на каком этапе процесса программа пытается выполнить эти действия и действительно ли это полезно для их обхода. Затем я указал минимальную скорость копирования 500000 байт в секунду и значение 1 МБ для «начального размера для пропуска при ошибке чтения», пытаясь как можно быстрее скопировать области, которые все еще исправны или к которым легко получить доступ. & означает -u«однонаправленный»: в предыдущем восстановлении с другим жестким диском копирование в обратном направлении с помощью переключателя, -Rказалось, улучшило ситуацию, но с этим оно, похоже, сеет хаос, и, по-видимому, с этим переключателем все более стабильно.)

Теперь, после того как он завершил один проход, я удалил большую часть этих параметров, оставив только -u. Я попробовал -dпереключиться в какой-то момент («использовать прямой доступ к диску»), но тогда ничего не копировалось, «размер ошибки» рос очень быстро.

Answer 1

Завершая свои комментарии выше (извините за формальные неудобства/несоответствия): я бы сказал, что оно того стоило, хотя и не совсем понимаю, почему. Вторая попытка, восстановление на раздел Ext4, имела значительно более высокую скорость копирования в начале (около 90 МБ/с в среднем, тогда как у меня было всего около 50 МБ/с в лучшем случае для первой попытки, восстановления на раздел NTFS), и никаких ошибок или даже замедлений. Но затем, после копирования около 165 ГБ (то есть раньше, чем раньше), он стал очень нестабильным и замедлился до улитки, снова издавал щелчки и жужжащие звуки (это был очень жаркий период, который не помог – я пытался охладить его как можно сильнее, используя охлаждающую подставку для ноутбука снизу и охлаждающий пакет сверху, который менялся примерно каждый час); Я пробовал снова и снова (иногда скорость возвращалась к 120 МБ/с на несколько секунд, а затем снова падала до 0), но через некоторое время мне приходилось отказываться от этого.

Вот ddrescueviewкарта первого восстановления:

Наблюдается интересная закономерность: полосы легко восстанавливаемых данных чередуются с очень медленными или нечитаемыми данными.[Насколько мне известно, это, по-видимому, указывает на то, что головка соприкоснулась с пластиной, повредив поверхность и высвободив магнитную пыль, которая затем распространилась под действием центробежной силы. А поскольку серводорожка (которая содержит важную информацию для процесса запуска) расположена на внешнем крае жесткого диска (это 3,5-дюймовый Hitachi 1 ТБ), часть этой пыли могла достичь ее, что затруднило доступ к ней, что могло бы объяснить частые щелчки при запуске.](Поправьте меня, если я ошибаюсь.) => [EDIT 20200501] Это было неверно, на самом деле эта схема обычно указывает на то, что одна головка накопителя полностью вышла из строя и больше ничего не считывает. Данные на пластинах в этот момент могут быть все еще читаемы, но для этого потребуется замена узла стека головок, что может безопасно выполнить только специализированная лаборатория по восстановлению данных.

Вот ddrescueviewкарта второго восстановления:

Итак, жесткий диск стал очень нестабильным, а восстановление все более сложным после 165 ГБ, но до этого скорость копирования была стабильно высокой, без пропусков областей. Позже я использовал этот ddru_ntfsbitmapметод для последних попыток, поэтому нераспределенное пространство в основном пропускалось.

Ниже представлена ddrescueview​​карта файла журнала, созданного с помощью ddru_ntfsbitmap, на которой области жесткого диска, содержащие фактические данные, показаны зеленым цветом, а свободное пространство — серым:

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

---

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

Я попытался скопировать восстановленные области образа 2 на разделе Ext4, которые отсутствовали на образе 1, в этот образ 1 на разделе NTFS ^{1} , что должно было быть сделано на очень высокой скорости (ввод и вывод осуществлялись на исправном жестком диске емкостью 2 ТБ), однако я получил среднюю скорость всего 660 КБ/с, что очень близко к скорости первоначального восстановления на более позднем этапе, когда я достаточно обеспокоился, чтобы задать этот вопрос в первую очередь...

Используемая команда (файл журнала для изображения 2 используется как файл журнала домена):

ddrescue -m [image2.log] [image2] [image1] [image1.log]

Скриншот:

Поэтому я остановился и сделал наоборот: скопировал восстановленные области в образе 1 (NTFS), которые отсутствовали в образе 2 (Ext4), в этот образ 2 — и теперь скорость копирования составила около 43000 КБ/с или 43 МБ/с в среднем (возможно, немного медленнее, чем следовало бы ожидать для копирования на тот же жесткий диск, для Seagate 2 ТБ, максимальная скорость записи которого близка к 200 МБ/с, поэтому он должен достичь около 100 МБ/с для копирования с одного раздела на другой, но все равно почти в 100 раз лучше, чем при первой попытке). Каково объяснение столь колоссального расхождения?

Используемая команда (файл журнала для изображения 1 используется как файл журнала домена):

ddrescue -m [image1.log] [image1] [image2] [image2.log]

Скриншот:

Я заметил, что файлы образов на обоих разделах имели «размер на диске» ^{2}, соответствующий объему фактически записанных данных, что очень далеко от общего размера (1 ТБ или 931,5 ГБ), хотя я не использовал переключатель -S(«использовать разреженные записи для выходных файлов»). Образ 2 (после завершения с дополнительными восстановленными областями из образа 1) имеет «размер на диске» 308,5 ГБ, в то время как образ 1 имеет «размер на диске» 259,8 ГБ. Может ли это быть связано с низкой скоростью копирования, если драйвер Linux NTFS каким-то образом испытывает трудности с обработкой разреженных записей? И как так получилось, что весь размер не был выделен сразу после записи секторов в конце, учитывая, что я не использовал этот -Sпереключатель?

Я попытался использовать -pпереключатель («preallocate») в самом начале процесса, думая, что это будет «чище», проще, проще в обращении, если что-то пойдет не так (если восстановление нужно будет восстановить...), но мне пришлось остановиться, так как это было слишком долго, а я хотел начать как можно скорее (судя по всему, он на самом деле записывает пустые данные вместо того, чтобы просто выделить требуемые сектора). Затем я решил, что -Rвременное использование переключателя («reverse») запишет самые последние сектора в выходной файл, тем самым выделив полный размер, как я и предполагал; это действительно привело к увеличению размера выходного файла до 931,5 ГБ, но «размер на диске» на самом деле был намного меньше (я заметил это позже, когда получил доступ к жесткому диску, использованному для этого восстановления в Windows, и увидел ненормально большой объем свободного места).
________________
{1} Я все еще не понимаю, как вторая попытка восстановления могла дать настолько лучший результат для первых 100 ГБ или около того, несмотря на то, что состояние здоровья жесткого диска тем временем ухудшилось. [EDIT 20200501] => Возможно, это из-за параметра, a500000использованного в первый раз, который пропускал области, для которых скорость чтения была ниже порогового значения 500 КБ/с. Без этой опции во второй раз он сразу считывал более медленные области. Фактически, эти более медленные области были связаны со слабой головкой, поэтому все еще остается загадкой, как эта неисправная головка смогла получить столько данных во второй раз, хотя она уже показывала признаки неисправности. Я все еще учусь...

{2} Кстати, слово «диск» следует заменить как в системах Windows, так и в Linux, поскольку существуют устройства хранения данных, которые не являются «дисками»...

Answer 2

1. Возможно, вам сначала захочется скопировать образ диска с помощьюддкоманда

   sudo dd bs=[размер_блока] count=[Кол-во_блоков] if=[входной_файл] of=[выходной_файл]

где

[in_file] - может быть сломанным диском, например /dev/sdd2

[out_file] - расположение выходного файла изображения.

2. Смонтируйте образ и попробуйте восстановить его.