Acronis восстановление active directory
Резервное копирование Active Directory и обеспечение успешного восстановления в случае повреждения, компрометации или аварии является важной частью обслуживания Active Directory.
В этой статье описаны надлежащие процедуры резервного копирования и восстановления контроллеров домена Active Directory (виртуальных машин или локальных серверов Azure) с помощью Azure Backup. В ней рассматривается сценарий, в котором необходимо восстановить состояние всего контроллера домена до состояния на момент резервного копирования. Чтобы определить, какой сценарий восстановления подходит для вас, ознакомьтесь с этой статьей.
В этой статье не рассматриваются восстановление элементов из Azure Active Directory. Сведения о восстановлении пользователей Azure Active Directory см. в этой статье.
Рекомендации
Убедитесь, что создается резервная копия по крайней мере для одного контроллера домена. При резервном копировании нескольких контроллеров домена убедитесь, что резервное копирование выполняется для всех контроллеров с ролями FSMO (Flexible Single Master Operation — операции с одним исполнителем).
Регулярно создавайте резервные копии Active Directory. Срок резервного копирования никогда не должен превышать отметку полного удаления (TSL), поскольку объекты, существующие дольше срока TSL, полностью удаляются и больше не считаются допустимыми.
Значение TSL по умолчанию для доменов, созданных на базе Windows Server 2003 SP2 и более поздних версий, составляет 180 дней.
Чтобы проверить настроенный срок TSL, используйте следующий сценарий PowerShell:
Составьте четкий план аварийного восстановления, включающий инструкции по восстановлению контроллеров домена. Чтобы подготовиться к восстановлению леса Active Directory, ознакомьтесь с руководством по восстановлению леса Active Directory.
Если необходимо восстановить контроллер домена и сохранить оставшийся работоспособный контроллер домена в домене, вместо восстановления из резервной копии можно создать новый сервер. Добавьте роль сервера доменных служб Active Directory для нового сервера, чтобы сделать его контроллером домена в существующем домене. Тогда данные Active Directory будут реплицированы на новый сервер. Чтобы удалить предыдущий контроллер домена из Active Directory, выполните действия, описанные в этой статье, для очистки метаданных.
В Azure Backup не предусмотрено восстановление на уровне элементов для Active Directory. Если вы хотите восстановить удаленные объекты и можете получить доступ к контроллеру домена, используйте корзину Active Directory. Если этот метод недоступен, вы можете воспользоваться резервной копией контроллера домена для восстановления удаленных объектов с помощью средства ntdsutil.exe, как описано здесь.
Сведения о выполнении заслуживающего доверия восстановления SYSVOL см. в этой статье.
Резервное копирование контроллеров домена виртуальных машин Azure
Если контроллер домена является виртуальной машиной Azure, можно выполнить резервное копирование сервера с помощью резервного копирования виртуальных машин Azure.
Ознакомьтесь с замечаниями по эксплуатации виртуальных контроллеров домена, чтобы обеспечить успешное резервное копирование (и будущие операции восстановления) контроллеров домена виртуальных машин Azure.
Резервное копирование локальных контроллеров домена
Чтобы создать резервную копию локального контроллера домена, необходимо выполнить резервное копирование данных о состоянии системы сервера.
- Если вы используете функцию MARS, выполните эти инструкции.
- Если вы используете MABS (Azure Backup Server), выполните эти инструкции.
Восстановление локальных контроллеров домена (из состояния системы или виртуальных машин) в облаке Azure не поддерживается. Если вы хотите выполнить отработку отказа из локальной среды Active Directory в Azure, рассмотрите возможность использования Azure Site Recovery.
Восстановление Active Directory
Данные Active Directory можно восстановить в одном из двух режимов: заслуживающем доверия или не заслуживающем доверия. При заслуживающем доверия восстановлении восстановленные данные Active Directory переопределят данные, находящиеся на других контроллерах домена в лесу.
Однако в этом сценарии выполняется перестройка контроллера домена в существующем домене, поэтому восстановление должно быть не заслуживающим доверия.
Во время восстановления сервер будет запущен в режиме восстановления служб каталогов (DSRM). Для режима восстановления служб каталогов необходимо указать пароль администратора.
Если вы забыли пароль DSRM, его можно сбросить, следуя этим инструкциям.
Восстановление контроллеров домена виртуальных машин Azure
Сведения о восстановлении контроллера домена виртуальной машины Azure см. в разделе Восстановление виртуальных машин контроллера домена.
Если вы восстанавливаете одну виртуальную машину контроллера домена или несколько виртуальных машин контроллера домена в одном домене, восстановите их как любую другую виртуальную машину. Кроме того, доступен режим восстановления служб каталогов, следовательно, все сценарии восстановления Active Directory также являются приемлемыми.
Если необходимо восстановить виртуальную машину для одного контроллера домена в конфигурации с несколькими доменами, восстановите диски и создайте виртуальную машину с помощью PowerShell.
При восстановлении последнего оставшегося контроллера домена в домене или нескольких доменов в одном лесу рекомендуется восстановить лес.
Начиная с Windows 2012, виртуализированные контроллеры домена используют средства безопасности на основе виртуализации. С помощью этих средств безопасности служба Active Directory определяет, является ли восстановленная виртуальная машина контроллером домена, и выполняет необходимые действия для восстановления данных Active Directory.
Восстановление локальных контроллеров домена
Чтобы восстановить локальный контроллер домена, следуйте указаниям по восстановлению состояния системы в Windows Server, придерживаясь рекомендаций, касающихся особых замечаний по восстановлению состояния системы на контроллере домена.
В этой статье мы покажем, как восстановить контроллер домена 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.
Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.
В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).
Заметем выберите диск, на котором находится резервная копия старого контроллера AD, или укажите UNC путь к ней.
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
Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.
Сказ о том что SystemState сделанный NTBackup не такой уж и помощник при восстановлении DC.
Начну с далека.
Устроился и на место админа, ранее работал разрабом, но тут платили существенно больше, поэтому решил пока сменить сферу деятельности.
Было 4 сервера в моей компетенции:
dc — контроллер домена
fs — файловый + принт сервер
av — сервер с антивирусом + местный чат
db — для базы
Через месяцок приехало 2 новых сервера: один пошел для одного спецпроекта вне моей компетенции, и один для нужд инфраструктуры, т.е. для меня.
Ранее я уже работал с hyper-v, поэтому решил не заморачиваться и развернул его, а не vmware, хоть тоже пробовал и ее.
Завел еще один контроллер домена dc2, wsus, новый fs, принт сервер и т.д.
Списали старые сервера: av, db с помощью Acronis True Image Universal Restore перенесли на hyper-v, старый fs просто убрали.
И так у нас было: dc1 (старый dc физический), под hyper-v крутилось dc2, новый fs и т.д. что надо для жизни.
Через годика полтора приехало еще много оборудования и решили существующий сервер hyper-v отдать для других задач, а развернуть кластер из двух сервер hyper-v. Потиху перекидывали сервера со старого hyper-v на кластер. Решили пока контроллеры домена не трогать.
Сервер dc1 стал хереть и мы решили что надо бы от него избавится. Сделали копию с помощью disk2vhd и был свеженький SystemState, делавшийся ежедневно с помощью NTBackup.
Решаем начать с vhd файл dc1. Создали виртуальную машину с этим vhd — при старте получаем BSOD. C помощью Acronis True Image Universal Restore добились чтобы сервер запускался, но AD ругается, что ему плохо и AD фактически не пашет. В инете отыскали, что нельзя с DC так поступать: снимать образы разделов.
Привалило работы и немного отвлеклись. dc2 выполнял функции DC.
Напарник решил перекинуть со старого hyper-v сервер dc2 на кластер. Просто перекинул vhd файл, создал новую виртуальную машину с этим файлом и запустил сервер. ОС загрузилась, но оказалась новая сетевая карта и AD работать не будет.
Случайно xml файл описания виртуальной машины на старом hyper-v он удалил. Теперь и на старом hyper-v сервере dc2 ругалось аналогично.
Решили восстановить dc1 из SystemState на кластере hyper-v, т.к. физический сервер dc1 не поддерживает загрузку с cd, а сама ОС уже перестала загружаться. Ставлю такую же Windows Server 2003. Восстанавливаю SystemState, но после ребута BSOD *** Stop: 0x0000007B.
Находим на technet как можно попробовать оживить dc2.
Создаем новую виртуальную машину, подключаем к ней vhd файл dc2, грузимся в нее. В ней добавляем переменную окружения DEVMGR_SHOW_NONPRESENT_DEVICES со значением 1. Потом в device manager показываем скрытые устройства, находим старую сетевую и сохраняем GUID устройства. У созданной виртуальной машины удаляем vhd файл и делаем экспорт ее (без vhd файла это проходит быстрее :) ). В эскортированном xml файле правим GUID сетевой карты. Потом импортируем виртуальную машину и подключаем нетронутый vhd файл от dc2.
Вывод
1 — С самого начала надо было развернуть еще один дополнительный dc, понизить d1, а потом пересоздать его
2 — не удалять ничего раньше времени: надо просто выключить dc2 на старом hyper-v и воспользоваться экспортом виртуальной машины
3 — Советоваться и обсуждать действия перед началом работ
Необходимо восстановить тома, на которых хранятся файлы базы данных Active Directory (стр.
225). Если на этих томах хранятся ценные данные помимо Active Directory, скопируйте их в
другое хранилище, прежде чем выполнять восстановление.
Как восстановить контроллер домена при отсутствии других контроллеров домена
Для восстановления должна использоваться самая последняя резервная копия из
имеющихся. Это важно, так как все изменения, внесенные в объекты Active Directory после
резервного копирования, будут потеряны.
Восстановите контроллер домена из резервной копии с помощью загрузочного носителя.
Перезагрузите контроллер домена. Убедитесь, что служба Active Directory успешно
11.4.3 Восстановление базы данных Active Directory
Если файлы Active Directory повреждены, но контроллер домена запускается в обычном
режиме, можно восстановить базу данных одним из следующих способов.
Повышение уровня контроллера домена
Этот способ восстановления базы данных возможен только в случае, если у домена есть другие
контроллеры домена. Резервная копия не требуется.
Для восстановления базы данных используйте средство
, чтобы понизить уровень
контроллера домена с поврежденной базой данных, а затем повысить его снова.
Чтобы снова повысить уровень контроллера домена, выполните следующие команды:
Восстановление данных из резервной копии
Этот способ восстановления базы данных может использоваться независимо от того, есть ли у
домена другие контроллеры домена.
Для восстановления базы данных восстановите файлы базы данных Active Directory (стр. 225).
Кроме того, если после создания резервной копии были внесены изменения в объекты
групповой политики (GPO), необходимо будет восстановить и папку SYSVOL (стр. 230).
Как восстановить базу данных Active Directory из резервной копии
Перезапустите контроллер домена и во время запуска нажмите клавишу F8.
На экране Дополнительные варианты загрузки выберите Режим восстановления служб
[Необязательно] Создайте копию файлов текущей базы данных Active Directory, чтобы в
случае необходимости отменить изменения.
Смените учетную запись службы агента Acronis на учетную запись администратора режима
Откройте оснастку Службы.
В списке служб дважды щелкните службу Acronis Managed Machine Service.
(NDB-файлы и LDF-файлы) также найдены.
Подробнее. Файлы базы данных SQL Server могут быть не найдены автоматически, если:
Они находятся в расположении, отличном от расположения по умолчанию, или если
они не находятся в одной папке с основным файлом базы данных (MDF).Решение.
Укажите путь к требуемым файлам вручную в столбце Путь к текущему файлу.
Вы восстановили неполный набор файлов, составляющих базу данных. Решение.
Восстановите отсутствующие файлы базы данных SQL Server из резервной копии.
7. Когда все файлы будут найдены, нажмите кнопку ОК.
11.3 Восстановление данных Exchange Server
В случае аварии можно восстановить весь сервер Exchange, восстановив все его диски из
резервной копии диска. Все службы Exchange Server будут работать без дополнительных
действий, если вы следовали рекомендациям в разделе Резервное копирование сервера
приложений (стр. 227). Данные сервера будут восстановлены по состоянию на момент
создания резервной копии.
С помощью Acronis Backup & Recovery 11.5 можно восстановить файлы баз данных Exchange из
резервной копии диска. Чтобы привести базу данных в оперативный режим, подключите ее.
Дополнительные сведения см. в разделе Подключение баз данных Exchange Server (стр. 242).
Если требуется фрагментарное восстановление отдельных почтовых ящиков и их элементов,
подключите восстановленную базу данных как базу данных восстановления (RDB) в Exchange
2010 или как группу хранения для восстановления (RSG) в Exchange 2003/2007. См. раздел
Фрагментарное восстановление почтовых ящиков (стр. 243).
Подключение баз данных exchange server, 2 подключение баз данных exchange server
Copyright © Acronis International GmbH, 2002-2013
11.3.1 Восстановление файлов баз данных Exchange Server из
резервной копии диска
В этом разделе показано, как с помощью Acronis Backup & Recovery 11.5 восстановить файлы
баз данных Exchange Server из резервной копии диска.
Инструкции по поиску путей к базам данных см. в разделе Поиск файлов баз данных (стр. 231).
Как восстановить базы данных Exchange Server
1. Подключите консоль к машине, на которой будет выполняться операция.
2. Перейдите к хранилищу, содержащему резервную копию диска с файлами данных
3. Щелкните вкладку Представление «Данные». В списке Показать щелкните Папки/файлы.
4. Выберите необходимые файлы баз данных Exchange и нажмите кнопку Восстановить. По
умолчанию данные будут восстановлены по состоянию на момент создания последней
резервной копии. Если требуется вернуть данные к состоянию на другой момент времени,
сделать это можно с помощью списка Версии.
5. На странице «Восстановление» в разделе Что восстанавливать сделайте следующее:
a. В поле Пути к данным выберите Пользовательские.
b. В окне Обзор укажите папку, в которую должны быть восстановлены файлы.
6. Оставьте остальные настройки «как есть» и нажмите кнопку ОК, чтобы приступить к
11.3.2 Подключение баз данных Exchange Server
Восстановив файлы баз данных, можно перевести базы данных в оперативный режим,
подключив их. Для подключения базы данных используйте консоль управления Exchange,
диспетчер Exchange или командную консоль Exchange.
Восстановленная база данных будет в состоянии «грязного отключения». Если база данных
находится в состоянии «грязного отключения», она может быть подключена системой, если
была восстановлена в исходном расположении (т. е. сведения об исходной базе данных
присутствуют в Active Directory). Если база данных восстанавливается в другое расположение (в
новую базу данных или базу данных восстановления), она не может быть подключена, пока не
будет приведена в состояние «чистого отключения» с помощью команды
указывает префикс файлов журнала для базы данных (или группы хранения,
содержащей эту базу данных), где необходимо применить файлы журнала транзакций.
Учетной записи, используемой для прикрепления базы данных, должна быть делегирована
роль «Администратор сервера Exchange Server» и локальная группа «Администраторы» для
Дополнительные сведения о подключении баз данных см. в следующих статьях:
Читайте также: