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

Question

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

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

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

• Я делаю это восстановление в раздел NTFS, который, из того, что я прочитал довольно поздно в процессе (в этом французском руководстве), не рекомендуется, поскольку это может значительно замедлить восстановление. Это (все еще) правда, и если так, то почему?
  • Или это в прошлом, когда драйвер NTFS для Linux не был достаточно зрелым? (Я использую последнюю версию живого DVD Knoppix, скопированную на карту памяти, поскольку она не может успешно загрузиться с DVD-RW.)
• Стоит ли на этом этапе конвертировать раздел в собственный формат Linux, такой как Ext4? Я имею в виду, значительно ли это улучшит скорость копирования?
  • Или это нормально испытывать такое замедление с неисправным диском после первого прохода, где большинство «здоровых» секторов уже восстановлено? (Параметры SMART ухудшаются, «результат теста самооценки общего состояния здоровья» изменился с «PASSED» на «FAILED», число перераспределенных секторов изменилось с 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 ТБ), часть этой пыли, возможно, достигла его, затрудняя доступ, который может объяснить частые шумы при запуске. (Поправьте меня если я ошибаюсь.)

Вот карта 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, в это изображение 2 (Ext4) - и теперь скорость копирования составляла около 43000 КБ / с или 43 МБ / с. в среднем (может быть немного медленнее, чем следует ожидать для копии на том же жестком диске, для Seagate 2 ТБ, который имеет максимальную скорость записи, близкую к 200 МБ / с, поэтому должен иметь возможность достигать около 100 МБ / с для копировать с одного раздела на другой, но все же почти в 100 раз лучше, чем с первой попытки). Чем можно объяснить такое колоссальное несоответствие?

Используемая команда:

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

Скриншот:

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

Я пытался использовать ключ -p («preallocate») в самом начале процесса, думая, что он будет «чище», проще, проще работать в случае, если что-то пойдет не так (если нужно восстановить выздоровел ...), но мне пришлось остановиться, так как это было слишком долго, и я хотел начать как можно скорее. Затем я решил, что с помощью ключа -R («реверс») временно он запишет самые последние сектора в выходной файл, выделив таким образом полный размер, как я и предполагал; это действительно привело к увеличению размера выходного файла до 931,5 ГБ, но «размер на диске» был на самом деле гораздо меньше (я заметил это позже, когда обращался к жесткому диску, используемому для этого восстановления в Windows, и наблюдал необычно большое количество свободного места). пространство).
________________
{1} Я до сих пор не понимаю, как вторая попытка восстановления могла привести к гораздо лучшему результату для первых 100 ГБ или около того, несмотря на то, что состояние здоровья жесткого диска за это время ухудшилось.

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

Answer 2

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

   sudo dd bs = [block_size] count = [NofBlocks] if = [in_file] of = [out_file]

где

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

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

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