Как сделать резервную копию active directory 2016

Обновлено: 05.07.2024

14 января, 2020 kevich

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

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

Восстановление контроллера домена 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.

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

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

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

Чтобы WSB увидел бэкап на диске, нужно поместить каталог WindowsImageBackup с резервной копией в корень диска. Можете проверить наличие резервных копий на диске с помощью команды: wbadmin get versions -backupTarget:D:

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

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

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

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

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

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

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

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

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

Загрузите DC в DSRM режиме;
Выведите список доступных резервных копий: wbadmin get versions
Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
Подтвердите восстановление DC (в не полномочном режиме);
После перезагрузки запустите: ntdsutil
activate instance ntds
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

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

Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях . Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Неполномочное восстановление AD DS

Выполнять неполномочное восстановление будем через бэкап System State нашего КД.

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

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

Перед началом процесса восстановления контроллера домена необходимо четко себе представлять что же произойдет после, а произойдет следующее:

Система возвратится в состояние на момент снятие бэкапа (это очевидно);
Будет сгенерирован новый DSA Invocation ID;
Текущий пул RID будет сброшен и получен новый;
Произойдет неполномочное восстановление SYSVOL.

Теперь о каждом пункте подробнее, начиная со 2.

DSA Invocation ID

Этот механизм необходим, чтобы избежать отката номеров последовательных обновлений (USN Rollback 2 ), который заключается в следующем.

RID Pool

Любой принципал безопасности (пользователь, компьютер, группа) в AD имеет уникальный идентификатор, называемый SID. SID, в свою очередь, состоит из нескольких значений, последним из которых является относительный идентификатор — RID.

Примечание: за выдачу пулов относительных идентификаторов отвечает держатель роли FSMO RID Master, о котором я подробно рассказывал в статье RID master — Хозяин относительных идентификаторов.

Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.

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

Примечание: может так получиться, что восстанавливать из бэкапа придется хозяина RID. На этот счет Microsoft рекомендует не выполнять восстановление, а захватить все необходимые роли с других КД и вместо утраченного контроллера развернуть другой. Тем не менее, восстановление хозяина RID вполне возможно. Главное, чтобы на момент восстановления хозяина RID остальные КД были реплицированы друг с другом и хотя бы один из их был доступен восстановленному КД для выполнения начальной репликации, иначе роль RID master не стартанет.

Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4 .

Переходим к последнему пункту.

SYSVOL restore

Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5 , то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.

Когда нужно неполномочное восстановление

Неполномочное восстановление может понадобиться в нескольких ситуациях:

Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
При откате к снимку виртуальной машины. Если:
- КД имеет ОС старше Windows Server 2012;
- Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.

Во всех остальных случаях используются другие сценарии восстановления.

Подготовка

К моменту восстановления у вас должны быть:

Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.

Примечание: если пароль DSRM безвозвратно утерян, его можно сбросить 6 . Разумеется такой вариант возможен только при локальном входе на КД.

Переходим к кульминации.

Восстановление

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

Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них — нажатие F8 во время загрузки.

Примечание: если вам интересно, то второй способ — с помощью утилиты bcdedit, выполнив последовательно команды:

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ — использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory). После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.

Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:

Вводим пароль DSRM, дожидаемся пока система загрузится.

Не забудьте выбрать Восстановление системы:

После этого увидите предупреждение:

Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.

Сегодня, когда распределенные системы и сложные ИТ-ландшафты утвердились повсеместно, сохранение и восстановление данных остается чрезвычайно актуальной темой. Аминистраторы ИТ вынуждены изучать стратегии резервного копирования данных и сценарии восстановления после катастроф, чтобы быть готовыми ко всему. Времена, когда речь шла исключительно о резервном копировании и восстановлении отдельных файлов, давно прошли. Между тем, реализация полноценной концепции сохранения данных требует высокого уровня компетентности. Выяснить, как надо действовать в конкретной аварийной ситуации, не всегда просто.

Одной из наиболее важных и сложных систем является служба каталогов Active Directory (AD), которая на многих предприятиях используется для авторизации и аутентификации пользователей. На что же следует обращать внимание в связи с сохранением данных? Какие меры предосторожности позволяют администратору спать спокойно? Мы постараемся дать ответы на эти вопросы и предложить некоторые практические идеи для повседневного применения, которые базируются на подручных средствах.

Сохранение Active Directory не должно зависеть от помпезных пакетов управления резервным копированием данных — при желании ее можно осуществить бесплатно и с сохранением наглядности.

СОХРАНЕНИЕ И УДАЛЕНИЕ ДАННЫХ В ACTIVE DIRECTORY

В зависимости от инфраструктуры ИТ среда Active Directory состоит из двух или более контроллеров доменов (Domain Controller). Active Directory можно использовать и с одним контроллером домена, однако из соображений обеспечения отказоустойчивости предпочтительнее избыточная комбинация. Какие-либо ограничения сверху отсутствуют. Дизайн произволен, хотя и определяется некоторыми правилами, не влияющими на функции восстановления информации. Среды Active Directory с 50 и более контроллерами доменов, распределенными по всему миру или по отдельному региону, сегодня встречаются нередко. Точное их количество зависит от требований филиала, доступной пропускной способности и числа пользователей, которые аутентифицируются в Active Directory. Система тиражирования обеспечивает распределение базы данных по всем контроллерам доменов, а также следит за тем, чтобы любой из них обладал каталогом с актуальной информацией.

Каждый пользователь, который вместе со своей учетной записью является членом домена Active Directory, после регистрации взаимодействует только с одним контроллером в своем домене. Определение этого контроллера происходит на основе топологии филиала и подсети.

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

ЕЖЕДНЕВНОЕ СОХРАНЕНИЕ СОСТОЯНИЯ СИСТЕМЫ

Каждая программа резервного копирования, совместимая с Windows, должна справляться с сохранением состояния системы. При этом на контроллере домена автоматически происходит сохранение Active Directory. Поскольку защищаются всегда все серверы, в том числе и контроллеры доменов, после этого ничего плохого уже не случится. Однако в силу ряда причин обычное резервное копирование данных на контроллере домена имеет смысл дополнить выполнением еще одной операции и записать состояние системы в виде файла: с одной стороны, так обеспечивается быстрое восстановление, с другой — локальное сохранение не зависит от внешних носителей. К тому же тем самым достигается независимость от используемого решения резервного копирования.

НЕЗАВИСИМОСТЬ ОТ ИСПОЛЬЗУЕМОГО РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ

ЛЕЧЕНИЕ ПАРАНОЙИ БЕЗ БОЛЬШИХ ЗАТРАТ

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

ВНИМАТЕЛЬНОСТЬ ПРИ СОХРАНЕНИИ

ЧТО МОЖЕТ СЛУЧИТЬСЯ С ACTIVE DIRECTORY

При каких обстоятельствах может возникнуть необходимость в восстановлении Active Directory? В первую очередь следует упомянуть об отказе контроллера домена (Domain Controller, DC) — это простейший случай. Если в домене есть другие контроллеры, достаточно подключить новый DC, тогда обращение к системе резервного копирования оказывается излишним. Единственное затруднение составляет сохраненная в базе данных ссылка на имя уже несуществующего контроллера домена. DCPROMO вызывает отказ, когда в базе данных имеется DC с используемым именем. Эту проблему можно решить двумя способами: для достижения скорейшего результата лучше всего включить контроллер домена в Active Directory под другим именем. Старое имя и впредь остается в базе данных, однако это не важно, поскольку DC не функционирует. Избавиться от этой записи можно позже. Если же имя контроллера домена должно оставаться неизменным, его необходимо предварительно удалить.

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

Очень интересные документы по этой теме предлагает Netpro [4]. Для нас важно то, что благодаря последней версии ntdsutil.exe обратные ссылки не ведут к отрицательным последствиям, поскольку помимо предупреждений инструмент генерирует и файлы импорта LDIF. При помощи ldifde.exe их можно использовать после того, как контроллер домена снова станет доступен, чтобы восстановить отсутствующие обратные ссылки [5] (см. Рисунок 6). В системе, состоящей из нескольких доменов, ntdsutil.exe необходимо запускать на сервере глобального каталога, поскольку только контроллеры доменов глобальных каталогов обладают всеми ссылками на другие домены. В противном случае членство в доменах пользователей в файлах LDIF может быть учтено, а членство в соседних доменах — нет.

Для такого случая существует инструмент ldp.exe, который можно найти на компакт-диске Windows Server среди средств поддержки. Однако использовать его следует с осторожностью. Как и adsiedit.msc, он предоставляет прямой доступ к Active Directory и позволяет манипулировать атрибутами. При неправильном обращении и наличии соответствующих прав службе каталогов можно нанести значительный ущерб.

Групповые директивы — обязательная составная часть Active Directory. Сохранение производится при помощи параметра системного состояния. Однако групповые директивы на контроллере домена сохраняются не только в базе данных, но частично и в файловой системе, что требует иного метода действий при восстановлении. Внутреннее сохранение групповых директив происходит раздельно в двух местах: в контейнере групповых директив (Group Policy Container, GPC) и в шаблоне групповых директив (Group Policy Template, GPT). Контейнер находится в базе данных Active Directory и содержит параметры и настройки групповых директив. Тиражирование происходит при помощи механизмов Active Directory, управление которыми осуществляется с помощью программы контроля целостности знаний (Knowledge Consistency Checker, KCC). Оригинал расположен в папке SYSVOLPolicies и служит, среди прочего, для сохранения административных документов с параметрами реестра.

Удобную возможность для сохранения и восстановления групповых директив предлагает консоль управления групповыми директивами (Group Policy Management Console). Доступная изначально только в качестве загружаемого расширения, она стала обязательной составной частью представителей семейства Windows 2003 Server и значительно облегчает сохранение и восстановление групповых директив. Еще одно преимущество заключается в том, что обслуживание может производиться при помощи как графического интерфейса, так и прилагаемой библиотеки сценариев. Среди прочего имеется возможность сохранения всех групповых директив из командной строки каталога.

Таким образом, обеспечиваются наилучшие условия для расширения работающего по ночам сценария Dcbackup.cmd (см. Рисунок 10). В следующем примере показано, как проводится сохранение всех правил в файловой системе: “c:Program FilesGPMCScriptsBackupAllGPOs.wsf“ c:Backup /comment: “Daily schedule“.

Вставленную в сценарий команду можно произвольно дополнять и подстраивать под соответствующую среду. Однако необходимо позаботиться о периодическом удалении целевого каталога, поскольку новые копии добавляются в соответствующую папку, а уже имеющиеся будут оставаться в ней до бесконечности. Восстановление групповых директив может происходить и через графический интерфейс. Посредством контекстного меню узла Group Policy Objects и команды Manage Backups на экран выводится диалоговое окно управления резервными копиями (см. Рисунки 11 и 12). После указания папки для хранения все сохраненные директивы доступны для выбора и могут восстанавливаться по отдельности. В результате групповые директивы можно перенести из тестовой среды в производственную и наоборот без повторного создания групповой директивы и задания настроек. Библиотека сценариев располагается в программном каталоге GPMC, содержит множество сценариев и представляет собой полезное дополнение к графическому интерфейсу.

Все перечисленные выше методы и инструменты бесплатны и предлагают абсолютно надежное резервное копирование данных службы каталогов Active Directory, целью которого всегда является сохранение состояния системы. Для восстановления данных из Active Directory имеются продукты третьих производителей, расширяющие соответствующие возможности. Благодаря коммерческим продуктам управление обратными ссылками также остается прозрачным для администратора. Как было показано, это достигается простыми средствами и предлагает массу преимуществ. Возможно, изложенный нами подход будет способствовать расширению концепции резервного копирования.

Клаус Биршенк — консультант по технологиям в компании T-Systems Enterprise.

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

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

Чтобы создать резервную копию Active Directory, создайте резервные копии следующих томов

системный том и загрузочный том;

тома, где находятся база данных и журналы транзакций Active Directory (стр. 323);

том с папкой SYSVOL. По умолчанию эта папка находится в %SystemRoot%\SYSVOL. Чтобы

определить текущее расположение этой папки, посмотрите значение Sysvol в следующем

На что обратить внимание для резервного копирования

Для настройки и выполнения резервного копирования Active Directory убедитесь в следующем:

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

контроллер домена, рекомендуется создавать резервные копии по крайней мере

Самая последняя резервная копия не старше половины времени существования отметки

полного удаления. В зависимости от операционной системы, где был создан домен, время

существования отметки полного удаления по умолчанию равно 60 дням или 180 дням.

Неважно, была последняя резервная копия полной или инкрементной. Успешное

восстановление возможно из любой.

Вы создаете дополнительную резервную копию в любом из следующих случаев.

База данных или журналы транзакций Active Directory были перемещены.

Операционная система на контроллере домена была обновлена, или был установлен

Было установлено исправление, изменяющее базу данных Active Directory.

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

Создать эту дополнительную резервную копию необходимо потому, что успешное

восстановление Active Directory из предыдущих резервных копий может оказаться

11.1.3.3 Резервное копирование данных SharePoint

Ферма Microsoft SharePoint состоит из интерфейсных веб-серверов и серверов Microsoft SQL.

Интерфейсный веб-сервер — это хост, на котором работают службы SharePoint. Некоторые

интерфейсные веб-серверы могут быть идентичны друг другу (например, интерфейсные

веб-серверы, на которых выполняется веб-серверное программное обеспечение). Требуются

резервные копии не всех одинаковых интерфейсных веб-серверов, а только уникальных.

Для защиты баз данных SharePoint необходимо выполнить резервное копирование всех

серверов Microsoft SQL и всех уникальных интерфейсных веб-серверов, принадлежащих

ферме. Резервное копирование должно выполняться по одинаковому расписанию. Это

необходимо потому, что база данных конфигурации должна быть синхронизирована с

Читайте также: