Почему ddrescue не может просто восстановить блоки, используемые файловой системой?

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

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

http://partclone.org/features/

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

Смотрите также: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[email protected]/

5 ответов:

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

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

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

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

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

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

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

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

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

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

В настоящее время это возможно, так как поток, упомянутый в вопросе, был реализован. Вы можете использовать утилиту 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