Похоже, что ddrescue пытается восстановить все блоки на диске или разделе, даже те, которые не содержат файлов. Разве не возможно выяснить, какие блоки на самом деле содержат файлы, посмотрев на файловую систему, например, на главную таблицу файлов в NTFS?
Редактировать: Кажется, это возможно в сочетании с partclone:
http://partclone.org/features/
В случае необходимости восстановления режим восстановления Partclone попытается пропустить плохие блоки и сделать резервную копию всех хороших блоков для разделов. Программа ddrescue — еще одно лучшее решение для сохранения плохого диска, а с помощью partclone, перечисляя все используемые блоки как файл домена, это может сделать ddrescue умнее и быстрее при дампе раздела.
Смотрите также: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[email protected]/
решение1
Короткий ответ: потому что это не его цель. Ddrescue делает одну вещь (копирование 1:1 неисправного жесткого диска), и делает это хорошо.
решение2
Я не верю, что это возможно, поскольку ddrescue, как и сам dd, предназначен для работы на любом блочном устройстве, даже на тех, на которых нет файловой системы или она повреждена. Просмотр файловой системы, если она существует, только усложнит задачу.
решение3
Старая тема, но может быть полезна другим...
Если входные данные представляют собой том, отформатированный в NTFS, вы можете использовать ddru_ntfsbitmap из ddruutility, чтобы сгенерировать mapfile для ddrescue, используя системный файл $Bitmap, который является именно картой используемых/неиспользуемых кластеров на разделе NTFS. Конечно, для правильной работы требуется, чтобы файл $Bitmap был целым и находился в полностью читаемой области (обычно он находится в начале раздела). Если это так, то процесс выполняется быстро (в моем первом и пока единственном опыте на генерацию mapfile из раздела объемом 1 ТБ ушло около 2 минут). Затем вы запускаете ddrescue с помощью этой базовой команды:
ddrescue [options] [input path] [output path] [logfile] -m [mapfile]
В последних версиях ddrescue термин «logfile», как в файле, где во время восстановления сохраняются восстановленные/неисправные/плохие области входного тома, был заменен на «mapfile», что делает это довольно запутанным. Так что, если, например, вы хотите восстановить жесткий диск с именем /dev/sdc в образ на /media/sdd1 с именем Recovery, используя mapfile, сгенерированный ddru_ntfsbitmap с именем Recovery_bitmap.log, команда должна быть такой:
ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
решение4
Основная причина, вероятно, в том, что это ddrescueзначительно усложнит код, поскольку ему придется включать информацию о различных файловых системах и анализировать их внутренние структуры.
Однако, даже игнорируя дополнительные усилия по разработке, попытка выяснить, в каких блоках есть данные, в целом затруднительна. ddrescueобычно используется в ситуациях, когда данные уже повреждены и, возможно, несогласованны. Попытка найти используемые блоки в такой ситуации рискованна — что, если сам список свободных блоков поврежден (но все еще читаем)? Или, может быть, текущая версия файла больше не подлежит восстановлению, но старая версия файла все еще присутствует в свободных блоках (потому что файловая система не перезаписала их на месте).
В этом случае единственный безопасный вариант — собрать все и разобраться с деталями позже.