Схема разбиения динамических дисков содержится в базе данных менеджера логических дисков (Logical Disk Manager Database, LDM). Это — протоколируемая (journalled) база данных, поддерживающая транзакции и устойчивая к сбоям. Если в процессе манипуляции с томами вдруг происходит сбой питания, то при последующем включении компьютера будет выполнен откат (rollback) в предыдущее состояние. При переносе винчестера, содержащего один или несколько динамических дисков, на другой компьютер они автоматически распознаются и монтируются, как обыкновенные диски.

База данных LDM хранится в последнем мегабайте жесткого диска, а для дисков, полученных путем обновления базового раздела до динамического, — в последнем мегабайте этого раздела. Как уже говорилось, идентификатор загрузки

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

Сразу же за таблицей разделов по адресу

расположен приватный заголовок , содержащий в себе ссылки на основные структуры LDM (рис. 5.8). Если погибнет, Windows не сможет обнаружить и смонтировать динамические диски. К сожалению, гибнет он удручающе часто. Подавляющее большинство загрузочных вирусов и дисковых менеджеров считают сектор свободным и используют его для хранения своего тела, необратимо затирая прежнее содержимое. Осознавая значимость заголовка , разработчики из Microsoft сохранили его в двух копиях, одна из которых хранится в конце LDM, а другая — в последнем секторе физического диска. Благодаря такой избыточности практически никогда не приходится восстанавливать вручную. Однако если такая необходимость все же возникнет, обратитесь к проекту LINUX-NTFS за подобным описанием его структуры (http://www.linux-ntfs.org/), здесь же оно по соображениям экономии места не приводится.

Рис. 5.8. База данных LDM и ее дислокация

Внутреннее устройство базы данных LDM не документировано. При этом даже поверхностный взгляд на ее структуру сразу же дает понятие о ее мощи и сложности (рис. 5.9). На самом верху иерархии расположено оглавление базы — структура

(Table Of Content Block), состоящая из двух секций, и (причем, вероятно, в будущем их список будет расширен). Секция содержит информацию о текущем разбиении диска на динамические тома, a хранит журнал изменений схемы разбиения. Это — очень мощное средство в борьбе с энтропией! Если удалить один или несколько динамических разделов, информация о старом разбиении сохранится в журнале, что позволит с легкостью восстановить утерянные тома! Будучи очень важной структурой, оглавление диска защищено от случайного разрушения тремя резервными копиями, одна из которых вплотную примыкает к оригинальной версии , в начале базы LDM, а две других находятся в конце диска, между копиями PRIVHEAD.

Рис. 5.9. Внутренняя структура LDM

Внутренне секция

состоит из заголовка () и одного или нескольких 128-байтных структур, называемых , каждая из которых описывает соответствующий ей том, контейнер, раздел, диск или группу дисков. Заголовок не имеет копии и нигде не дублируется. Однако все его изменения протоколируются в журнале () и потому могут быть восстановлены.

Примечание

Строение

VMDB

и

VBLKs

подробно описано в разделе "LDM Documentation" на сайте проекта LINUX-NTFS. Поэтому здесь оно не приводится в целях экономии места. Оно действительно очень громоздко, к тому же, крайне маловероятно, что кому-то потребуется восстанавливать секцию

config

вручную.

Для просмотра базы данных LDM и архивирования ее содержимого можно воспользоваться утилитой LDM-dump Марка Руссиновича, бесплатную копию которой можно скачать с его сайта (http://www.sysinternals.com/files/ldmdump.zip). Как вариант можно зарезервировать последний мегабайт физического диска, а также последние мегабайты всех разделов, для которых значение поля

равно . Сделать это можно с помощью любого дискового редактора (например, Sector Inspector). Эту информацию рекомендуется хранить на надежном носителе (Zip-дискете, CD-R/RW). Помимо этого, не забудьте также создать и резервную копию структуры .

При восстановлении удаленных динамических дисков необходимо учитывать следующие факторы:

1. Во-первых, журнал изменений на интерфейсном уровне недоступен, и выполнить откат штатными средствами операционной системы невозможно.

2. Во-вторых, загрузочные сектора удаляемых дисков автоматически очищаются, и восстанавливать их приходится вручную. Более подробно эта тема будет раскрыта в следующем разделе.

Если размер и тип удаленного динамического диска вам известны (на дисках NTFS его можно извлечь из копии загрузочного сектора), просто зайдите в Менеджер Управления Дисками (Disk Manager) и воссоздайте его заново, от предложения отформатировать раздел любезно откажитесь и восстановите очищенный загрузочный сектор по методике, описанной в следующем разделе.

Как видно, Microsoft тщательно позаботилась о своих пользователях и тщательно проработала структуру динамических дисков, что для нее, вообще говоря, нехарактерно.

Первый сектор логического диска носит название загрузочного (boot). Он содержит код самозагрузки (bootstrap code) и важнейшие сведения о геометрии диска, без которых раздел просто не будет смонтирован. Структура загрузочного сектора определяется архитектурными особенностями конкретной файловой системы. В частности, структура загрузочного сектора NTFS описана в табл. 5.6.