Восстановление контроллера домена из резервной копии

В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State, созданной ранее (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.

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

Восстановление контроллера домена AD через репликацию

Восстановление DC через репликацию – это не совсем процесс восстановления DC из бэкапа. Этот сценарий может использоваться, если у вас в сети есть несколько дополнительных контроллеров домена, и все они работоспособны. Этот сценарий предполагает установку нового сервера, повышение его до нового DC в этом же сайте. Старый контроллер нужно просто удалить из AD.

Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.

Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа.

Типы восстановления Active Directory: полномочное и неполномочное

Есть два типа восстановления Active Directory DS из резервной копии, в которых нужно четко разобраться перед началом восстановления:

    Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно.

Восстановление контроллера домена AD из system state бэкапа

Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.

У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.

Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.

Active Directory repair mode" srcset="http://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, http://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w" sizes="(max-width: 575px) 100vw, 575px" />

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.

В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

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

wbadmin get versions -backupTarget:D:

Выберите дату, на которую нужно восстановить резервную копию.

Укажите, что вы восстанавливаете состояние System State.

Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files).

Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.

Согласитесь с еще одним предупреждением:


После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).

Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)

Авторизуйтесь на сервере под учетной записью с правами администратора домена.

При первом запуске консоли ADUC я получил ошибку:

При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:

  1. Запустите regedit.exe;
  2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  3. Измените значение параметра SysvolReady с 0 на 1;
  4. Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.

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

Восстановление отдельных объектов в AD

Если вам нужно восстановить отдельные объекты в AD, воспользуйтесь корзиной Active Directory. Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитаивного восстановления.

Вкратце процедура выглядит следующим образом:

  1. Загрузите DC в DSRM режиме;
  2. Выведите список доступных резервных копий: wbadmin get versions
  3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
  4. Подтвердите восстановление DC (в не полномочном режиме);
  5. После перезагрузки запустите: ntdsutil
  6. activate instance ntds
  7. authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

Или один объект:

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.

Этой статьей я завершаю тему восстановления данных в Active Directory. Напоследок я приберег самый тяжелый вариант — авторитативное восстановление Active Directory из резервной копии. Авторитативное восстановление (англ. Authoritative restore) — процесс достаточно сложный и долгий, могущий привести к различным неприятным последствиям, поэтому применять его стоит очень аккуратно. Однако ситуации бывают разные, поэтому все, кто работает с Active Directory, должны знать об этом способе восстановления и уметь им пользоваться.

Вот что представляет из себя авторитативное восстановление:

1) Контроллер домена загружается в режиме Directory Services Restore Mode (DSRM). В этом режиме служба AD не запускается, а база данных переводится в автономный режим;
2) База данных AD восстанавливается из резервной копии;
3) Восстанавливаемые объекты помечаются как авторитативные с помощью утилиты Ntdsutil;
4) Контроллер домена загружается в нормальном режиме.

Это если коротко. Более подробно рассмотрим процесс авторитативного восстановления на примере восстановления удаленной организационной единицы. Все действия будут проводится на Windows Server 2008 R2 с использованием встроенных средств, уровень леса Server 2008 R2.

Для авторитативного восстановления Active Directory нам потребуется резервная копия состояния системы (System State). System State включает в себя:

• Файл ntds.dit – база данных Active Directory;
• Системный реестр контроллера домена;
• База данных Certification Authority (служб сертификации);
• Системный том SYSVOL, хранящий сценарии входа в систему и групповые политики домена;
• Системные файлы, необходимые для загрузки операционной системы;
• База данных регистрации классов COM+, которая содержит информацию о приложениях COM+ ;
• Сведения Cluster Services (служб кластеров), если данный сервер является компонентом кластера.

Для создания резервной копии я воспользуюсь встроенной в Windows Server 2008 программой для резервного копирования Wbadmin. Открываем командную консоль и создаем бэкап System State на диске E следующей командой:

wbadmin start systemstatebackup -backupTarget:E:

Создав резервную копию, открываем оснастку Active Directory Users and Computers (ADUC) и, совершенно случайно 🙂 удаляем подразделение Managers со всем содержимым.

Кстати, в отличие от других объектов (учетных записей пользователей, компьютеров и групп) у контейнеров предусмотрена защита от случайного удаления. Поэтому, прежде чем удалять объект, в оснастке ADUC в меню View включаем пункт Advanced Features. Затем открываем свойства объекта и на вкладке Object снимаем галку с чек-бокса «Protect object from accidental deletion».

Теперь мы должны перезагрузить контроллер домена в режиме восстановления Directory Services Restore Mode. Если в Windows Server 2003 для этого достаточно было нажать клавишу F8 при загрузке, то в Server 2008 необходимо внести изменения в загрузочное меню. Сделать это можно двумя способами.

Из командной строки, запущенной с правами администратора, введя команду:

bcdedit /set safeboot dsrepair

И перезагрузить сервер:

Либо нажать Win+R и в строке выполнить (Run) ввести msconfig. Откроется оснастка System Configuration. В ней на вкладке Boot в поле «Boot options» надо отметить режим Safe boot, установить переключатель на Active Directory repair и нажать OK. И затем перезагрузиться.

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

Приступим к восстановлению. Опять задействуем Wbadmin и восстановим созданный ранее System State командой:

wbadmin start systemstaterecovery -version:11/20/2012-08:29

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

Немного теории

У каждого объекта Active Directory существует свойство USN (Update Sequence Numbers), или номер последовательного восстановления. При каждом изменении объекта в Active Directory к его значению USN прибавляется 1. Таким образом Active Directory определяет актуальность информации об объекте, т.е. чем больше USN, тем объект актуальнее.
Каждый контроллер домена имеет свой собственный USN, отличный от других. При репликации контроллеры обмениваются значениями USN и каждый запоминает значение USN партнера по репликации, чтобы после оповещения об изменениях партнер забрал произведенные изменения. Таким образом объект с более низким USN будет при репликации перезаписан объектом с более высоким USN.
Так вот, авторитативное восстановление объекта заключается в том, что значение его USN принудительно увеличивается на 100000. Это делает объект авторитативным, и при последующей репликации он будет сохранен.

На самом деле механизм репликации гораздо сложнее, но для понимания процесса этого хватит.

Чтобы пометить объект как авторитативный:

• В меню Start -> Run набираем ntdsutil и жмем ENTER;
• В строке ntdsutil набираем activate instance ntds и жмем ENTER;
• В строке ntdsutil набираем authoritative restore и жмем ENTER.

Теперь мы находимся в приглашении командной строки утилиты Ntdsutil для авторитативного восстановления. Синтаксис команд следующий:

restore object — помечает одиночный объект (компьютер, пользователя или группу) как авторитативный для репликации;
restore subtree — помечает поддерево (напр. подразделение (OU) со всем содержимым) как авторитативный объект;
restore database — помечает всю базу данных Active Directory как авторитативную. Это приведет к перезаписи содержимого базы данных Active Directory на всех контроллерах домена;
-verinc — параметр, который позволяет вручную задавать USN. По умолчанию при авторитативном восстановлении USN данных увеличивается на 100000. Параметр verinc оказывается полезен, если выполняется авторитетное восстановление данных поверх других авторитетно восстановленных данных, то есть значение USN должно быть увеличено больше, чем на 100000.

Пометим для восстановления подразделение Managers:

restore subtree ″OU=Managers,DC=contoso,DC=com″

Дело практически сделано. Теперь остается загрузить контроллер в нормальном режиме и дождаться репликации. Не забудьте отключить безопасную загрузку, сделать это можно командой bcdedit /deletevalue safeboot или из оснастки System Configuration.

На этом процесс авторитативного восстановления можно считать законченным. Для ускорения репликации можно выполнить команду repadmin /syncall .

Некоторые моменты, с которыми можно столкнуться при авторитативном восстановлении.


В один не очень замечательный день перестал отвечать на запросы сервер контроллера домена Active Directory. Второй контроллер домена тоже оказался неработоспособным. Оба они находились в синем экране смерти с кодом 0xc0002e2. Пришлось проводить восстановление Active Directory.

@duzlov (Дмитрий Узлов) и @sergey_algin (Сергей Альгин) запаслись крепким кофе и начали работу.

Перезагрузка серверов в разных режимах не помогла. Причем один из серверов при загрузке выдавал огромное количество предупреждений и ошибок про контроллер дисков. Вскрытие сервера показало, что вышла из строя батарея raid-контроллера. Похоже, что это и послужило причиной сбоя сервера.

Я перегрузил сервер в режиме восстановления служб Active Directory (Directory Service Restore Mode (DSRM)).

Сделал копии всех файлов, находящихся в каталогах c:windowsNTDS; c:windowsSYSVOL.

В командной строке запустил утилиту ntdsutil, служащую для работы с базой данных ntds.dit:

В командной строке ntdsutil необходимо активировать базу данных Active Directory:

А после проверить базу данных на наличие ошибок:

База данных рассыпалась, виноват сбой в контроллере дисков:

Повреждения базы данных Active Directory (фото из Интернет)

На втором сервере ситуация была схожей. Было решено восстановить сервер из резервной копии.

После восстановления сервера из резервной копии казалось, что все проблемы разрешатся, но этого не случилось.

Сервер уходил в бесконечную перезагрузку. Зато база данных ntds.dit, журналы, SYSVOL были в надлежащем состоянии.

К сожалению, все попытки восстановить работоспособность сервера не привели к успеху.

После чтения документации и статей в Интернет я решил попробовать неописанный в них способ восстановления – попытку подмены файлов базы данных Active Directory, SYSVOL во вновь установленном сервере.

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

IFM (Install from Media) – метод установки дополнительного контроллера в существующий домен с использованием набора файлов. Это помогает уменьшить трафик репликации и применимо в сценариях с удаленными территориальными офисами, связанными медленными WAN-каналами.

Подробнее про IFM можно прочесть в статье technet.

В структуре IFM есть копии файлов ntds, SYSVOL и кусты реестра. Но для использования этих файлов при типовой установке требуется наличие работоспособных контроллеров домена. В нашей ситуации этот способ использовать нельзя.

Для подтверждения гипотезы с подменой необходимых файлов было решено установить новую операционную систему и перезаписать файлы Active Directory.

После установки системы я установил роли AD DS, DNS, DHCP. Это необходимо для того, чтобы в файловой системе уже присутствовали все необходимые бинарные компоненты для запуска служб.

Затем перегрузил сервер с внешнего носителя в Windows PE, сделал копии Windows, ProgramData, Users и начал эксперимент.

Первым делом я перезаписал в каталоги c:windows; c:windowsNTDS и c:windowsSYSVOL файлы с имеющейся копии. Удалил все файлы *.log в каталоге NTDS:

Перезагрузка сервера и снова

Вывод, что для восстановления работоспособного контроллера домена наличия NTDS и SYSVOL недостаточно. Это и так было понятно, но проверить всё-таки стоило.

Снова перезагрузка сервера в Windows PE, восстановление папок Windows, ProgramData и Users. Проверка – сервер загружается.

Вторая попытка – копирование помимо NTDS и SYSVOL ещё и ProgramData, Users и кустов реестра.

Кусты реестра находятся в папке %SystemRoot%System32Config. Скопировал все кусты реестра. Перезагрузка и снова синий экран.

В третьей попытке восстановления я решил не копировать ProgramData, Users и ограничился копированием NTDS, SYSVOL и кустов реестра SAM и SYSTEM.

Перезагрузка – УДАЧА! Сервер загрузился, в него можно было войти под доменной учётной записью, он определился как контроллер домена.

DNS был интегрирован в Active Directory, все записи DNS тоже были на месте. База DHCP не восстановилась. Но, если на клиентском компьютере установить static IP, пользователь и компьютер могут получить доступ к ресурсам.

Но внутри самого сервера были проблемы, связанные с отсутствием прав доступа к меню Пуск, контекстному меню в Проводнике. Можно было запустить командную строку и работать из неё.

Проверка целостности ntds с помощью ntdsutil показала, что всё в порядке.

Было решено заново установить серверную операционную систему и создать новый контроллер домена.

Проверка репликации базы данных показала, что не синхронизируются netlogon и sysvol. Для решения этой задачи необходимо провести процедуру полномочной синхронизации.

Оцените статью
Добавить комментарий