Чтобы завершить мои комментарии выше (извините за формальные неудобства / несоответствия): я бы сказал, что это того стоило, хотя я не совсем понимаю, почему. Вторая попытка, восстановление в раздел Ext4, вначале имела значительно более высокую скорость копирования (в среднем около 90 МБ / с, тогда как в первой попытке у меня было в лучшем случае всего около 50 МБ / с, при восстановлении в раздел NTFS) и никаких ошибок или даже замедлений. Но затем, после копирования около 165 ГБ (так раньше, чем раньше), он стал очень нестабильным и замедлился до ползания, снова издал щелчки и жужжащие звуки (это был очень жаркий период, который не помог - я попытался охладить его максимально опустите, используя охлаждающую подставку для ноутбука внизу и пакет для замораживания поверх нее, меняйте каждый час или около того);
Вот ddrescueviewкарта первого восстановления:
Есть интересный паттерн: полосы легко восстанавливаемых данных чередуются с очень медленными или нечитаемыми данными. Из того, что я знаю, это, кажется, указывает на то, что головка вступила в контакт с пластиной, повредив поверхность и выпустив магнитную пыль, которая затем распространяется с центробежной силой. А поскольку серво-трек (который содержит важную информацию для процесса запуска) расположен на внешнем крае жесткого диска (это 3,5-дюймовый Hitachi 1 ТБ), часть этой пыли, возможно, достигла его, затрудняя доступ, что может объяснить частые щелчки при запуске. (Поправьте меня, если я ошибаюсь.)
Вот ddrescueviewкарта второго восстановления:
Таким образом, жесткий диск стал очень нестабильным, а восстановление стало более трудным после примерно 165 ГБ, но до этого скорость копирования была постоянно высокой, без пропусков. Позже я использовал этот ddru_ntfsbitmapметод для последних попыток, поэтому свободное место в основном пропускалось.
Вот ddrescueviewкарта файла журнала, созданного с помощью ddru_ntfsbitmap, показывающая области жесткого диска, содержащие фактические данные, зеленым цветом и свободное пространство серым цветом:
К счастью, большинство фактических данных было найдено в первом квартале и было успешно восстановлено. Теперь мне еще предстоит объединить хорошие части этих двух образов и извлечь реальные файлы, возможно, с помощью R-Studio (лучшее программное обеспечение для восстановления данных, которое я пробовал).
Одна вещь, которую я позже выяснил, которая интересна и необычна, относительно моего первоначального вопроса (я думаю, я должен был бы поместить это как комментарий, согласно формальным правилам, но это было бы слишком долго, и я не мог предоставить скриншоты) ,
Я попытался скопировать спасенные области изображения 2 в разделе Ext4, которые отсутствовали в изображении 1, в это изображение 1 в разделе NTFS , что должно было быть выполнено с очень высокой скоростью (вход и выход находясь на здоровом жестком диске 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] Скриншот:
Я заметил, что файлы изображений в обоих разделах имели «размер на диске» , соответствующий объему фактически записанных данных, очень далеко от общего размера (1 ТБ или 931,5 ГБ), хотя я этого не делал. t использовать -Sпереключатель («использовать редкие записи для выходных файлов»). Изображение 2 (после заполнения дополнительными спасенными областями из изображения 1) имеет «размер на диске» 308,5 ГБ, а изображение 1 имеет «размер на диске» 259,8 ГБ. Может ли это быть связано с низкой скоростью копирования, если драйвер Linux NTFS каким-то образом испытывает затруднения при работе с разреженными записями? И как получилось, что весь размер не был выделен, как только были написаны сектора в конце, учитывая, что я не использовал этот -Sпереключатель?
Я пытался использовать -pпереключатель («preallocate») в самом начале процесса, думая, что он будет «чище», проще, проще в случае, если что-то пойдет не так (если восстановление необходимо восстановить. ..), но я должен был остановиться, так как это было слишком долго, и я хотел начать как можно скорее. Затем я решил, что с помощью -Rпереключателя («реверс») временно он запишет самые последние сектора в выходной файл, выделив таким образом полный размер, как я и предполагал; это действительно привело к увеличению размера выходного файла до 931,5 ГБ, но «размер на диске» был на самом деле гораздо меньше (я заметил это позже, когда обращался к жесткому диску, используемому для этого восстановления в Windows, и наблюдал необычно большое количество свободного места). пространство).
________________
Я до сих пор не понимаю, как вторая попытка восстановления могла привести к гораздо лучшему результату для первых 100 ГБ или около того, несмотря на то, что состояние здоровья жесткого диска за это время ухудшилось.
Кстати, слово «диск» следует заменить, как в системах Windows, так и в Linux, так как существуют блоки хранения данных, которые не являются «дисками» ...