Как я могу эффективно использовать ddrescue для чтения раздела NTFS с жесткого диска с поврежденной GPT?

Я пытаюсь использовать ddrescue для восприятия failing hard drive и не хочу тратить время на неиспользуемые сектора или другие разделы, однако таблица разделов нечитаема, так что я не могу воспользоваться ddru_ntfsbitmap.

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

Как это сделать?

Предварительные заметки

• Если вы просто хотите смонтировать файловую систему напрямую с диска, смотрите мой другой ответ. Если вы хотите использовать ddrescue для восстановления файловой системы, читайте дальше.
• Большинство команд в этом ответе нужно выполнять от имени root. Для краткости я не добавляю sudo повсюду.
• ddru_ntfsbitmap создает несколько файлов и использует их, когда вы снова запускаете его в той же директории (см. info ddrutility -n ddru_ntfsbitmap). Убедитесь, что вы не запускаете ddru_ntfsbitmap с присутствующими старыми файлами, особенно если вы меняете устройство, с которого хотите восстановить данные (например, когда переходите от “самого простого способа” к “лучшему способу”, описанному ниже). При сомнении начните заново в пустой директории.
• Если вы хотите копировать в обычный файл, лучше создать и хранить файл в файловой системе, поддерживающей разреженные файлы.

Самый простой способ

Наиболее простой (хотя, на мой взгляд, не самый лучший) способ — использовать опцию --inputoffset команды ddru_ntfsbitmap:

-i, --inputoffset <bytes>
Установить смещение ввода (смещение раздела)

^{(источник)}

Чтобы получить смещение в байтах, нужно умножить логический размер сектора на номер начального сектора раздела. Вы упомянули testdisk, и я предполагаю, что он может показать вам начальный сектор (я думаю, что старые версии показывали CHS, а не LBA; предполагаю, что fdisk или gdisk могут помочь, если резервный GPT в порядке).

Например, если логический размер сектора составляет 512 байт и раздел начинается с номера сектора 24680, то команда будет следующей:

ddru_ntfsbitmap --inputoffset "$((512*24680))" /dev/sdx domain_mapfile

А позже вы используете domain_mapfile с ddrescue:

ddrescue --domain-mapfile domain_mapfile /dev/sdx image rescue_mapfile

Вы можете записать на блочное устройство вместо image. В любом случае имеются недостатки и предостережения:

1. domain_mapfile описывает позиции внутри всего устройства /dev/sdx, а не внутри раздела (или файловой системы). Это нормально, поскольку нам нужно, чтобы ddrescue читал с /dev/sdx в любом случае (поскольку это единственный специальный файл, который у нас есть, нет /dev/sdx1, /dev/sdx2; если бы они были, то проблемы бы не возникло, верно?). Но это также означает, что image будет (частичным) образом всего устройства, так что файловая система будет там с указанным смещением.

   • Если вы пишете на блочное устройство, это устройство должно быть достаточно большим, чтобы вместить файловую систему, начинающуюся с оригинального смещения. Например, если первоначально файловая система составляет 2 GiB, но начинается с смещения в 1800 GiB, то вам нужно блочное устройство как минимум на 1802 GiB.

2. Это не было бы так плохо, если бы информация о смещении находилась внутри самого image. Что ж, ddru_ntfsbitmap достаточно умна, чтобы создать domain_mapfile, который заставляет ddrescue пытаться восстановить не только желаемую файловую систему, но и таблицу разделов. В лучшем случае таблица разделов была бы скопирована в image. В вашем случае таблица разделов (частично) нечитаема, и вы это знаете, поэтому нагружать оборудование, пытаясь ее прочитать, не лучшая идея.

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

3. В общем, таблица разделов может быть скопирована в image. В общем, логический размер сектора может составлять 4096 байт, и таблица разделов будет использовать такие сектора в этом случае. Операционная система получает информацию о логическом размере сектора через ioctl от оборудования, эта информация не принадлежит к тому содержимому, которое вы можете прочитать с помощью ddrescue (чтобы было понятно: фактическая таблица разделов принадлежит). Наш image не будет содержать этой информации.

   В общем, инструменты, которые вы, возможно, захотите использовать позже для получения данных из image, могут предполагать логический размер сектора 512 байт, они могут использовать некоторые эвристики или могут позволить вам указать его. Может произойти, что используется неправильное значение, и, следовательно, таблица разделов неправильно истолкована (или не найдена).

   • Если вы пишете на блочное устройство, тогда его логический размер сектора будет иметь значение. В случае несоответствия вам необходимо будет восстановить таблицу разделов. Если логический размер сектора источника составляет 512, а логический размер сектора назначения — 4096, и оригинальный начальный сектор неудобен (не делится на 8), то вы не сможете построить таблицу разделов, которая соответствует фактическому расположению файловой системы.

По этим причинам лучше копировать только раздел (или точнее файловую систему; это разные концепции) в обычный файл (например, наш image) или блочное устройство, чтобы файловая система начиналась без смещения в файле или устройстве.

Лучший способ

Если бы таблица разделов была в порядке, у вас были бы /dev/sdx1, /dev/sdx2 и т.д. Вы бы использовали ddru_ntfsbitmap и ddrescue на одном из этих файлов, чтобы получить образ правильного раздела, а не всего устройства. Ваша таблица разделов не в порядке, и поэтому у вас нет специальных файлов, связанных с разделами. Здесь я покажу вам, как “извлечь” раздел тем не менее.

Нам понадобится номер начального сектора раздела и (по желанию) количество секторов в разделе. Если вы знаете начальный и конечный сектора, то можете вычислить количество секторов как end-start+1. Инструмент, который мы будем использовать, ожидает значения в байтах, поэтому нам нужно умножить на логический размер сектора.

Например, если логический размер сектора составляет 512 байт и раздел начинается с номера сектора 24680, а раздел заканчивается на номере сектора 18245847, то он занимает 18221168 секторов и вы можете использовать следующее:

losetup --read-only --find --show --offset "$((512*24680))" --sizelimit "$((512*18221168))" /dev/sdx

Команда, если успешна, выведет вам путь к loop-устройству, например, /dev/loop91. Loop-устройство — это раздел. Подтвердите, что там есть NTFS (file -skr /dev/loop91) и скопируйте loop-устройство с помощью ddru_ntfsbitmap и ddrescue, как если бы вы копировали /dev/sdx2 и т.д.

^{Я предполагаю, что мы могли бы опустить --sizelimit и его опцию-аргумент, процедура все равно бы сработала. Это потому, что файловая система знает свой размер, ddru_ntfsbitmap не разрешит ddrescue читать за пределами файловой системы.}

ddru_ntfsbitmap /dev/loop91 domain_mapfile \
&& ddrescue --domain-mapfile domain_mapfile /dev/loop91 image rescue_mapfile

Вы можете записать на блочное устройство вместо image. Если на блочное устройство, тогда рекомендуется использовать раздел, а не целое устройство (вам нужно создать раздел заранее, он должен быть достаточно большим, чтобы удерживать файловую систему).

Когда вам больше не понадобится loop-устройство, удалите его:

losetup --detach /dev/loop91

Теперь, если не было ошибок чтения, которые значительно испортили копию, вы почти готовы даже mount файловую систему, сохраненную внутри image, без каких-либо смещений. Следующая команда может завершиться успехом или провалом:

mount -o ro image /some/mountpoint

Она может завершиться с сообщением об ошибке, таким как Failed to read last sector (18221151).

• Если вы записываете на блочное устройство (раздел) вместо image, и если блочное устройство было достаточно большим изначально, то такой ошибки не должно быть.

Если mount не удался с такой ошибкой, это означает, что конец файловой системы не был использован (в терминах файла битовой карты NTFS), ddru_ntfsbitmap позволил ddrescue пропустить его, image слишком мал. Вы должны исправить размер image, используя номер, который дал вам сообщение об ошибке плюс один (поскольку сектора нумеруются с нуля):

truncate --size="$((512*18221152))" image

Я думаю, что число в сообщении об ошибке всегда относится к 512-байтовым секторам, но я не уверен. Другой способ получить правильное число — использовать file image, чтобы увидеть, насколько велика фактическая файловая система. Если у вас есть сомнения, используйте размер раздела, с которого мы считали файловую систему (18221168 512-байтовых секторов в нашем примере). Раздел может быть больше, чем файловая система (обычно только немного больше), суть в том, что в нормальной настройке он не меньше, так что мы можем безопасно использовать его размер для нашего image.

Надеюсь, файловая система, в которой вы храните image, поддерживает разреженные файлы и, следовательно, файл не занимает место зря.

image готов. Вы можете его mount или делать что угодно.

# монтирование только для чтения
mount -o ro image /some/mountpoint