Восстановление контроллера домена Active Directory в Windows Server 2008 (Часть 2)

Два и более контроллеров домена

Продолжаю тему восстановления контроллера домена Active Directory в Windows Server 2008. Контроллеров домена должно быть несколько, это золотое правило, которому необходимо следовать во всех средних и крупных организациях. Принцип восстановления при наличии нескольких контроллеров существенно меняется. Давайте попробуем понять почему. Представим, что вы имеете два контроллера домена с именами DC1 и DC2 (это контроллеры одного домена). Оба будут иметь идентичную базу данных Active Directory, и если вы измените ее на одном, она автоматически обновится на другом, это процесс репликации.

Теперь определимся с расписанием резервного копирования:

Воскресенье – полная резервная копия системного раздела (описана в первой части статьи)

Понедельник – Суббота – создание состояния системы systemstate (описано в первой части статьи)

Все было отлично, но в четверг из-за неполадок перестал работать контроллер домена DC1. У вас есть несколько путей для восстановления контроллера, рассмотрим их.

• Путь первый: восстановить состояние системы (systemstate), которое было сделано в среду. Для этого вам понадобится запустить контроллер в режиме DSRM (Режим восстановления службы каталогов) и используя программу Windows Server Backup восстановить состояние. Но для этого контроллер должен загрузиться в DSRM, такой возможности может и не быть.
• Путь второй: если загрузить контроллер в DSRM не получается, процедура восстановления начинается с запуска восстановления системного раздела, архив которого был создан в воскресенье. После того как вы восстанавливаете DC1 из этого архива ваш компьютер идет в нормальную загрузку.

И вот здесь что при первом варианте, что при втором появляется два контроллера, у которых не синхронизованы базы Active Directory. DC1 имеет версию базы на день резервной копии, а DC2 текущую, самую новую версию.

Какая из версий будет иметь приоритет?

Если вы будете проводить восстановление способом, описанным мной в первой части статьи, то приоритет будет иметь тот контроллер, который оставался работать, в нашей ситуации это DC2. Все что находится в Active Directory на DC1 после восстановления, будет обновлено до состояния DC2. Этот способ называется не принудительное восстановление.

А может ну его этот Windows Server Backup?

Недавно столкнулся с позицией сотрудника Microsoft, который на вопрос как восстановить контроллер домена ответил «А зачем?». Вначале я немного задумался, не шутит ли он, но потом его доводы мне стали понятны. Идея выглядит следующим образом. В организациях среднего размера, как правило, 3-4-5 и больше контроллеров домена и шанс потерять их разом близок к 0. Чтобы избежать и этого шанса мы осуществляем резервное копирование только 2-х. При этом резервное копирование происходит того или тех контроллеров которые владеют ролями FSMO и представляют особенную ценность. Все остальные просто живут своей жизнью и если какой-то выходит из строя мы просто ставим новую ОС и поднимаем новый контроллер домена, следует заметить что по времени это будут равнозначные процедуры.

Может возникнуть желание вообще перестать делать копии, авось все не потеряем, а роли FSMO можно и захватить при желании. Желание совершенно вредное и вот почему. Потеря объектов Active Directory это не только случайное удаление пользователя, вы можете случайно стереть скриптом организационное подразделение со всем содержимым и просто так вернуть из контейнера удаленных объектов, все в первоначальном виде у вас не получится. А изменения уже прореплицировались. И каждый контроллер знает об удалении. В этой ситуации вам и понадобится резервная копия.

Следуйте правилу – «Лишних резервных копий не бывает»

Приоритет при репликации

Поскольку при стандартном восстановлении на «отремонтированный» контроллер реплицируется Active Directory с рабочих контроллеров, такой способ нам не подойдет. Нам нужно заставить изменить приоритет репликации и прореплицировать информацию с восстановленного контроллера на остальные. Это называется принудительное восстановление.

В Windows Server 2003 мы могли выполнить принудительное восстановление тремя способами:

1. Принудительное восстановление всей базы данных.

2. Принудительно восстановление организационного подразделения с содержимым

3. Принудительное восстановление отдельного объекта

Делалась эта процедура с помощью утилиты ntdsutil. В Windows Server 2008 утилита ntdsutil осталась, но теперь мы не можем принудительно восстановить всю базу данных.

Только:

1. Принудительно восстановление организационного подразделения с содержимым

2. Принудительное восстановление отдельного объекта

Поэтому мы всегда должны знать, какие объекты были удалены. Естественно, держать такую информацию в голове вы не сможете. Для этого в Windows 2008 было создано средство «Active Directory database mounting tool»

Active Directory database mounting tool создана для улучшения, а конкретно упрощения процесса восстановления службы каталогов. В Windows 2003, если мы имели множество архивов и не знали, какой именно содержит информацию нужную для восстановления, приходилось играть в рулетку, восстанавливая тот или иной архив и проверяя его содержимое.

В Windows 2008 ситуация меняется. Используя Database Mounting Tool мы можем просматривать содержимое базы на тот или иной процесс времени.

К сожалению, мы не можем просматривать содержимое AD на любой интересующий период времени, а лишь в те моменты, когда был создан Snapshot. Скажу сразу Snapshot не является тем Snapshot-ом к которому мы привыкли, используя VmWare. Он содержит информация о наличии объектов в базе, но никоим образом не участвует в восстановлении этих объектов.

Из вышесказанного можно сделать вывод:

Для того чтобы иметь актуальное представление о содержимом сделанной резервной копии, перед ней должен создавать Snapshot. Текст пакетного файла, запускаемого перед созданием резервной копии, должен быть следующий:

ntdsutil.exe "activate instance NTDS" snapshot create quit quit

Готовый пакетный файл можно скачать «здесь». Обязательно убедитесь в том, что Snapshot успевает закончиться до начала резервного копирования.

Увеличить рисунок

Рис. 1. Создание снимка Active Directory

Процесс принудительного восстановления контроллера домена с использованием состояния системы. (systemstate)

Предыстория такова, одним из администраторов было удалено организационное подразделение «BetaTesters», в котором содержалась учетная запись или записи. Точно этого мы не знаем. Информация об удалении успела реплицироваться на все контроллеры домена. У нас есть несколько архивов с Systemstate за предыдущие дни. Когда точно было удалено организационное подразделение, мы не знаем.

1. Для начала, нам необходимо выбрать какое состояние системы мы будем восстанавливать. Дату удаления мы не знаем. Для этого будем использовать Snapshot-ы, которые создаются у нас незадолго до резервной копии. Запустив утилиту ntdsutil, смотрим список снимков нашей AD.



Рис. 2. Просмотр доступных снимков Active Directory

2. Для этого в командной строке набираем ntdsutil -> snapshot -> Activate Instance NTDS -> list all. В результате мы получим список созданных снимков Active Directory. Первый снимок создан 13 апреля. С него я и начну.

3. Там же монтирую командой mount c подставленным идентификатором первый снимок Active Directory. Пример на рисунке 3. После этой операции у вас появится на диске C: ссылочный объект, называющийся $SNAP_дата. Зайдя в него, вы увидите структура вашего системного диска на момент создания копии.


Увеличить рисунок

Рис. 3. Монтирование снимка Active Director

4. Снимок смонтирован. Открываю второе окошко командной строки и запускаю утилиту dsamain. Выполняем хитрую команду, которая позволяет подключить моментальный снимок в качестве LDAP-сервера. В команде укажите путь к файлу ntds.dit в смонтированном снимке и порт LDAP-сервера (я рекомендую 50001)


Увеличить рисунок

Рис. 4. Использование dsamain.

5. Не закрывая окно, запускаем оснастку «Active Directory пользователи и компьютеры». Выбираем подключение к другому контроллеру домена.



Рис. 5. Сменить контроллер домена.

6. В появившемся меню указываем подключение к «Имя Сервера:указанный порт в dsamain», в моей ситуации это «DC:50001»


Увеличить рисунок

Рис. 6. Выбор LDAP сервера

7. Нажав «ОК» мы попадаем в оснастку «Active Directory пользователи и компьютеры», которая содержит данные для чтения по состоянию на момент создания снимка Active Directory. Я нахожу организационное подразделение «BetaTesters» и в нем есть пользователь «Rud Ilya». Вывод можно сделать такой: поскольку снимок был создан 13 апреля и содержит в себе удаленное подразделении, нам необходимо восстанавливать состояние системы на 13 апреля.



Рис. 7. Просмотр информации снимка AD.

8. Перед тем как перезагрузиться в режим восстановления службы каталогов не забудьте размонтировать снимок. Делается это командой unmount с идентификатором снимка.



Рис. 8. Размонтирование снимка

9. Теперь мы готовы перезагрузить один из контроллеров домена в режим восстановления службы каталогов. Как это сделать я писал в первой части статьи. Обратите внимание, что при загрузке в DSRM вы должны использовать DSRM администратора, а не доменного.



Рис. 9. Вход в DSRM. Указываем Имя_Компьютера\Администратор

10. После того как загрузка удалась, открываем командную строку. Вводим команду wbadmin get versions и получаем список созданных состояний системы.



Рис. 10. Список состояний системы (SystemStates)

11. Нам нужно восстановить состояние системы на 13 апреля, поэтому следующая команда будет: wbadmin start systemstaterecovery –version:время_создания_архива


Увеличить рисунок
Рис. 11. Запуск восстановления состояния системы.

12. Остается набраться терпения и дождаться окончания процесса восстановления. Что следует учесть: сразу после завершения процесса восстановления не спешите перезагружать контроллер, если просто уйти в перезагрузку, мы не достигнем результата, поскольку информация об удалении организационного подразделения будет реплицирована на наш контроллер в процессе загрузки.


Увеличить рисунок

Рис. 12. Процесс восстановления состояния системы.

13. Каждый объект Active Directory имеет номер версии и если на двух контроллерах у одного объекта разные номера версии, то правильным (более новым) считается тот объект, у которого версия больше. После окончания процесса восстановления необходимо запустить утилиту ntdsutil  и поднять номер версии для удаленной ветки Active Directory. Т.е для нашего контейнера.

Делается это следующим образом: ntdsutil -> Activate Instance NTDS -> Authoritative restore -> restore subtree “И указать, что должно быть восстановлено принудительно”. Пример на рисунке 13.


Увеличить рисунок

Рис. 13. Выбор того, что будет восстанавливаться принудительно.

14. Далее идет процесс повышения номера версии объектов, после которого, можно перезагружать контроллер домена в штатный режим работы.

Итог: Мы принудительно восстановили организационное подразделение со всем содержимым, используя состояние системы и моментальные снимки Active Directory. В Windows Server 2008 мы можем принудительно восстанавливать либо организационные подразделения со всем содержимым, либо конкретные объекты. Команда «restore database» из ntdsutil была убрана, соответственно принудительно восстановить всю базу данных Active Directory у нас не получится.

Если вы восстанавливаете архив системного диска контроллера домена и хотите добиться принудительного восстановления какой-то части AD, то сразу после восстановления, не давая контроллеру загрузиться в нормальном режиме, входим в режим восстановления службы каталогов. И используя ntdsutil, указываем, какая часть AD должна восстановиться принудительно.

Материал предоставлен ресурсом