Мне нужно спасти данные с жесткого диска размером около 2 ТБ, и я делаю это в некоторых Live-Linux на некоторых виртуальных машинах, где проблемный жесткий диск подключен к USB 3, а виртуальная машина предоставляет виртуальный диск необходимого размера локально. получить данные. Затем я выполнил следующий вызов, просто чтобы посмотреть, как идут дела:
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdc - это испорченное устройство на USB, sdb - это виртуальный диск для получения данных, sda1 - для временного хранения и форматирования с использованием Ext4.
Все стало работать быстро, ddrescue смог прочитать ~ 45 ГБ данных за считанные минуты, затем все резко замедлилось, считывая только несколько байтов в секунду в течение нескольких дней. Таким образом, устройство было явно сломано в этих частях, и я попытался просто пропустить те, которые использовали несколько вызовов различных --input-position=[...]GB один за другим. В зависимости от того, куда я прыгнул, вещи снова начали быстро читаться, пока они снова не стали медленными, и я снова не прыгнул, используя другой вызов. Важно отметить, что позиция ввода и вывода, напечатанная ddrescue , всегда была синхронизирована! Я также ничего не менял вручную в предоставленном файле карты, не удалял его или что-то в этом роде, он всегда был одним и тем же файлом и управлялся только самим ddrescue .
После этого я немного изменил подход и решил больше не использовать --input-position вручную, а вместо этого следующее:
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
Поэтому всякий раз, когда ddrescue распознавал медленные части, он пропускал разумные битые блоки данных и продолжал чтение. Опять же, положение входа и выхода было синхронизировано, и счетчик считанных и восстановленных данных все время увеличивался. К моменту завершения ddrescue сказано, что он спас ~ 650 ГБ данных.
Проблема заключается в том, что после окончательного просмотра самих файлов виртуального диска кажется, что на самом деле хранится только ~ 160 ГБ данных. Кроме того, время последней записи было слишком старым. По какой-то причине ddrescue считал, что читает много данных, но, похоже, неправильно записал их в тех местах на виртуальном диске, где он считывал их с разбитого диска. В конце концов, насколько я понимаю, виртуальный диск должен был иметь, по крайней мере, размер ddrescue указанный для объема спасенных данных.
У меня такое ощущение, что ddrescue правильно прочитал все данные, которые он сказал, но просто переписал уже спасенные данные при последующих вызовах. Так что, хотя я предполагаю, что он распознал --input-position для чтения, он, кажется, записывал всегда, начиная с позиции 0 снова в цели.
Очевидно, я не указывал начальную позицию для записи данных, но в соответствии с документацией, которая не должна быть необходимой, и ddrescue всегда печатал позиции ввода и вывода в любом случае одинаковыми.
-o bytes
--output-position=bytes
Starting position of the image of the rescue domain in outfile, in bytes.
Defaults to '--input-position'. The bytes below bytes aren't touched if
they exist and truncation is not requested. Else they are set to 0.
Конечно, я не запрашивал усечение, в соответствии с документацией он не включен по умолчанию и даже не работал бы для целевого диска, который я указал:
-t
--truncate
Truncate outfile to zero size before writing to it. Only works for regular
files, not for drives or partitions.
Итак, есть идеи о том, что могло пойти не так? Были ли мои множественные вызовы с разными значениями для --input-position уже неправильными? Связано ли это с чтением и записью на диски вместо разделов или файлов?
Может быть, проблема записи на какой-нибудь виртуальный диск? Хотя я не понимаю, почему это должно иметь какое-то значение, и мне нужно записать на какой-нибудь виртуальный диск и не могу предоставить хранилище необработанных устройств нужного размера.
Спасибо!