3

Кажется, что ddrescue пытается восстановить все блоки на диске или разделе, даже те, которые не содержат файлов. Разве не было бы возможно для него выяснить, какие блоки на самом деле содержат файлы, посмотрев на файловую систему, например, таблицу основных файлов в NTFS?

Изменить: кажется, это может быть возможно в сочетании с partclone:

http://partclone.org/features/

Для спасательной ситуации, режим восстановления Partclone будет пытаться пропускать плохие блоки и делать резервные копии всех хороших блоков для разделов. Программа ddrescue - это еще одно лучшее решение для сохранения поврежденного диска, в то время как с помощью partclone, перечисляя все используемые блоки в виде файла домена, она может сделать ddrescue умнее и быстрее при выгрузке раздела.

Смотрите также:http://sourceforge.net/p/partclone/mailman/partclone-user/thread/4DDB8E29.1030403@mev.co.uk/

5 ответов5

6

Краткий ответ: потому что это не его цель. Ddrescue делает одну вещь (1: 1 копирует отказавший жесткий диск) и делает это хорошо.

3

Я не верю, что это возможно, поскольку ddrescue, как и сам dd, предназначен для работы на любом блочном устройстве, даже на тех, у которых нет файловой системы или повреждено. Просмотр файловой системы, если она существует, только усложнит ее.

2

Старый поток, но может быть полезным для других ...

Если вход представляет собой том в формате NTFS, вы можете использовать ddru_ntfsbitmap из ddrutility, чтобы сгенерировать файл map для ddrescue с помощью системного файла $ Bitmap, который является точной картой используемых / неиспользуемых кластеров в разделе NTFS. Конечно, для правильной работы требуется, чтобы файл $ Bitmap был неповрежденным, находился в полностью читаемой области (как правило, он находится в начале раздела). Если это так, то это происходит быстро (в моем первом и пока единственном опыте потребовалось около 2 минут, чтобы сгенерировать файл карты из раздела размером 1 ТБ). Затем вы запускаете ddrescue с помощью этой базовой команды:

ddrescue [options] [input path] [output path] [logfile] -m [mapfile]

В последних версиях ddrescue, термин «logfile», например, файл, в котором спасенные / непробованные / поврежденные области входного тома сохраняются во время восстановления, был заменен на «mapfile», что делает это довольно запутанным , Итак, если, например, вы хотите восстановить жесткий диск с именем / dev / sdc в образ на / media / sdd1 с именем Recovery, используя файл карты, сгенерированный ddru_ntfsbitmap с именем Recovery_bitmap.log, команда должна быть:

ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
1

Основная причина, вероятно, заключается в том, что это сделает ddrescue значительно более сложным, так как он должен будет включать информацию о различных файловых системах и анализировать их внутренние структуры.

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

В этом случае единственный безопасный вариант - это захватить все и разобраться в деталях позже.

0

В настоящее время это возможно, поскольку упомянутая в вопросе нить реализована. Вы можете использовать утилиту Parclone, чтобы создать файл, который сообщает, какие части следует сканировать.

Вот пример того, как использовать это из упомянутой темы:

# produce a domain file for NTFS partition on /dev/sda1
partclone.ntfs -s /dev/sda1 -D -o sda1.domain
# copy /dev/sda1 to /dev/sdb1 using ddrescue with domain log file
ddrescue --domain-log sda1.domain /dev/sda1 /dev/sdb1 rescue.log

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .