Контроллер домена резервный: Как организовать резервный контроллер домена Windows Server 2012 R2? — Хабр Q&A
Как организовать резервный контроллер домена Windows Server 2012 R2? — Хабр Q&A
По следам вопроса задаваемого мной ранее: Как лучше организовать 2 контроллера домена DC? отчастья.
Изначально в организации было 2 DC, оба виртуальных, второй отключили вместо него настраиваю новый. Домен %DOMAIN%.LOCAL
Основной контроллер домена имя DC1(192.168.0.250) является виртуальным, Windows Server 2012 Standard. Крутится на хосте Windows Hyper-V Server 2012.
Второй контроллер домена имя DC3(192.168.0.9), физический Windows Server 2016. Его пытаюсь сделать резервным в случае отказа первого. Да да я знаю что в принципе понятия с формальной точки зрения «резервный DC» не существует, лучше помогите с вопросом чем умничать некоторых советчиков попрошу.
Режим работы леса и домена windows server 2008 r2. Оба в одной локальной сети, Оба DC в домене, оба GC, на обоих установлены роли DNS, DHCP. DNS я так понимаю реплицируется из коробки, да в прямую и обратную зону на DC3 попали машины с DC1 когда я смотрел в MMC DNS. DHCP настроил в режиме горячей замены, насколько это правильно с точки зрения отказ-ти, может другой режим?
При тесте отключил DC1, попытался на клиентской машине зайти под юзером которым еще ни разу не заходил на этой машине, результат ошибка «Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть». При попытке войти существующим пользователем на клиентской машине вроде всё нормально вошел. Кроме того после обратного включения DC1 я смог зайти только через 59manager пока не синхронизировался хост и DC1 который на нем висит, лишь минут так через 10-30. То есть DC3 не отрабатывает как резервный DC насколько я понял.
Пинги в оба конца есть dc1->dc3, dc3->dc1. И да я пробовал ставить DNS перекрестно, для dc1 первый dc3, для dc3 первый dc1. Вопросы в самом конце еще есть.
Я постарался подготовить вопрос собрал параметры обоих DC:
DC1:
ВЫВОД IPCONFIG:
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : DC1
Основной DNS-суффикс . . . . . . : DOMAIN.LOCAL
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Порядок просмотра суффиксов DNS . : DOMAIN.LOCAL
Ethernet adapter Ethernet:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Сетевой адаптер Hyper-V (Майкрософт)
Физический адрес. . . . . . . . . : 00-15-5D-11-FE-01
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::c0a8:fa%12(Основной)
Локальный IPv6-адрес канала . . . : fe80::f459:f53a:6d4f:4507%12(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.0.250(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.0.15
IAID DHCPv6 . . . . . . . . . . . : 251663709
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1B-26-37-01-00-15-5D-11-FE-01
DNS-серверы. . . . . . . . . . . : fe80::c0a8:fb%12
fe80::c0a8:fa%12
fe80::c0a8:fd%12
192.168.0.250
192.168.0.9
NetBios через TCP/IP. . . . . . . . : Включен
Туннельный адаптер Reusable ISATAP Interface {7AC827F7-4A02-4959-9BB2-90F2B86DE671}:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Туннельный адаптер isatap.{24942D37-D692-4B32-9D16-82F8B0811DDF}:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #2
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Туннельный адаптер Teredo Tunneling Pseudo-Interface:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
ВЫВОД NETDOM QUERY FSMO:
Хозяин схемы DC1.DOMAIN.LOCAL
Хозяин именования доменов DC1.DOMAIN.LOCAL
PDC DC1.DOMAIN.LOCAL
Диспетчер пула RID DC1.DOMAIN.LOCAL
Хозяин инфраструктуры DC1.DOMAIN.LOCAL
Команда выполнена успешно.
ВЫВОД NETDOM QUERY TRUST:
Направление доверенный\Доверяющий домен Тип доверия
=========== ============================ ==========
Команда выполнена успешно.
ВЫВОД NSLOOKUP до DC3:
DNS request timed out.
timeout was 2 seconds.
Сервер: UnKnown
Address: fe80::c0a8:fb
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Сервер: UnKnown
Address: fe80::c0a8:fb
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Сервер: UnKnown
Address: fe80::c0a8:fb
DNS request timed out.
timeout was 2 seconds.
ВЫВОД REPADMIN:
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: 7ea06dd2-f3cf-4990-b0ec-7ecaae12c8bd._msdcs.DOMAIN.LOCAL
Кому: f97b0f16-427e-49e5-a480-36f0a3b35506._msdcs.DOMAIN.LOCAL
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: 7ea06dd2-f3cf-4990-b0ec-7ecaae12c8bd._msdcs.DOMAIN.LOCAL
Кому: f97b0f16-427e-49e5-a480-36f0a3b35506._msdcs.DOMAIN.LOCAL
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.
Команда SyncAll завершена без ошибок.
DC3:
ВЫВОД IPCONFIG:
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : DC3
Основной DNS-суффикс . . . . . . : DOMAIN.LOCAL
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Порядок просмотра суффиксов DNS . : DOMAIN.LOCAL
Адаптер Ethernet Ethernet 2:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Физический адрес. . . . . . . . . : 40-61-86-96-A3-92
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::cd10:1e51:e505:3c0b%2(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.0.9(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.0.1
IAID DHCPv6 . . . . . . . . . . . : 121659782
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-20-58-B4-CC-C8-3A-35-D6-55-CC
DNS-серверы. . . . . . . . . . . : ::1
192.168.0.9
192.168.0.250
NetBios через TCP/IP. . . . . . . . : Включен
Адаптер Ethernet Ethernet:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Realtek RTL8139/810x Family Fast Ethernet NIC
Физический адрес. . . . . . . . . : C8-3A-35-D6-55-CC
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
Туннельный адаптер isatap.{9D1F1299-3017-449D-9CB2-575EFA08964F}:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Microsoft ISATAP Adapter
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Туннельный адаптер isatap.{0DD4A79E-C561-4B45-85EE-00BFDE69A870}:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
ВЫВОД NETDOM QUERY FSMO:
Хозяин схемы DC1.DOMAIN.LOCAL
Хозяин именования доменов DC1.DOMAIN.LOCAL
PDC DC1.DOMAIN.LOCAL
Диспетчер пула RID DC1.DOMAIN.LOCAL
Хозяин инфраструктуры DC1.DOMAIN.LOCAL
Команда выполнена успешно.
ВЫВОД NETDOM QUERY TRUST:
Направление доверенный\Доверяющий домен Тип доверия
=========== ============================ ==========
Команда выполнена успешно.
ВЫВОД NSLOOKUP до DC1:
Сервер: UnKnown
Address: ::1
Имя: dc1.DOMAIN.LOCAL
Address: 192.168.0.250
Сервер: UnKnown
Address: ::1
Имя: dc1.domain.local
Address: 192.168.0.250
Сервер: UnKnown
Address: ::1
Имя: dc1.domain.local
Address: 192.168.0.250
ВЫВОД REPADMIN:
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: f97b0f16-427e-49e5-a480-36f0a3b35506._msdcs.DOMAIN.LOCAL
Кому: 7ea06dd2-f3cf-4990-b0ec-7ecaae12c8bd._msdcs.DOMAIN.LOCAL
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: f97b0f16-427e-49e5-a480-36f0a3b35506._msdcs.DOMAIN.LOCAL
Кому: 7ea06dd2-f3cf-4990-b0ec-7ecaae12c8bd._msdcs.DOMAIN.LOCAL
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.
Команда SyncAll завершена без ошибок.
Вопросы которые читал в нете самостоятельно, но интерпретировать инфу пока не могу не мой уровень:
Нужна ли настройка в MMC DNS «передача зон » в моем случае. Для чего нужна вообще не понятно?
«Серверы пересылки» тоже самое?
Нужно ли настраивать доверительные отношения в MMC «домены и доверие», я пробовал у меня не получилось, см скриншот ниже
Настройка резервного контроллера домена Active Directory
- Заметки
- Windows
- Настройка резервного контроллера домена Active Directory
02.06.2020
Как установить и настроить основной контроллер домена Active Directory 2019 смотрите тут: Установка и настройка контроллера домена Active Directory на базе Microsoft Windows Server 2019 Standart.
Настройка сетевых интерфейсов Active Directory 2019
И так. У нас было 2 сервера виртуализации, 50 пользователей домена, 5 марок сетевых коммутаторов, полсотни групповых политик и гора CD-дисков, и всего такого, всех цветов.
Не то, чтобы это всё было нужно в настройке резервного контроллера доменов, но раз начал наводить порядок в конторе, то иди в своём деле до конца.
На самом деле всё не так страшно, даже наооборот. Основной сервер будет называться AD-01, а резервный AD-02. Логично же 🙂 ? На сервере AD-01 прописываем в Альтернативный DNS-сервер
ip адрес нашего будующего сервера. Так как у меня он находится в другом офисе, то и подсеть у него отличается, если бы он был в местной локальной сети, то имел ту же подсеть.
Вводим сервер AD-02 в домен, а затем добавляем в Предпочтительный DNS-сервер ip адрес нашего основного сервера AD-01.
Установка и настройка сервиса Active Directory 2019 через Диспетчер серверов
Через Диспетчер серверов вызываем Мастер добавление ролей и компонентов. Отмечаем чекбоксы DNS-сервер и Доменные службы Active Directory.
Далее ничего особенного, проходим до пункта Подтверждение, соглашаемся и начинаем установку.
После установки нам необходимо повысить роль сервера до уровня контроллера доменов.
Отмечаем Добавить контроллер домена в существующий домен, через кнопку Выбрать вибираем наш основной сервер и чуть ниже вводим наши учётные данные от домена.
В разделе Дополнительные параметры указываем источник репликации основной сервер AD-01. Вот и всё, репликация сервера Active Directory готова!
Проверка. Запускаем принудительное реплицирование домена
Для того чтобы сразу протестировать настройку открываем Диспетчер серверов и запускаем Средства / Active Directory — сайты и службы
В открывшемся окне переходим Sites / Default-First-Site-Name / Servers / AD-02 / NTDS Settings,
выбираем в окне справа наше подключение Правая кнопка мыши / Реплицировать сейчас.
А после мы должны увидеть уведовление об успешном реплицировании нашего каталога. Надеюсь помог! Если нет, оставляйте свои комментарии, допишу статью. Спасибо!
Установка резервного контроллера домена на Windows Server 2019.
В связи с очень сильной бюджетностью организации и отсутствием резервного сервера и даже резервных ПК, которые хранятся на складе и в любую минуту могут быть использованы, на один администраторский компьютер ADMIN-PC, с параметрами немного лучше, чем у всех остальных в сети, пришлось переносить сервера, на время ремонта основного сервера с несколькими виртуальными машинами. Виртуальные машины этот компьютер не потянет, поэтому решено было установить несколько ОС и запускать их по очереди. Одновременно они могут понадобиться только в аварийной ситуации и к тому же это на непродолжительное время. Рассмотрим установку нескольких ОС на один ПК и затем установим на него контроллер домена Windows Server 2019.
Подготавливаем ПК. Устанавливаем в него несколько жестких дисков HDD и размечаем их как нам требуется. На один HDD желательно устанавливать одну ОС, чтоб в случае поломки HDD, масштабы не были слишком масштабными. В нашем случае это выглядит как на фото ниже.
Создаем по инструкции загрузочную флэшку с Windows Server 2019.
Вставляем загрузочную флэшку в USB-разъем. Запускаем ПК, через BootMenu выбираем флэшку и нажимаем загрузку с неё.
Выбираем Windows Server 2019 Standard (возможности рабочего стола).
Выбираем нужный HDD. Короче говоря, устанавливаем операционную систему стандартным методом до момента перезагрузки системы.
После перезагрузки ПК система не отобразилась в диспетчере загружаемых ОС.
Нужно отметить, что до начала установки этой ОС в ADMIN-PC уже были установлены Windows 7, Windows 10 и Windows Server 2012. Запускаем любую из установленных ранее ОС. Если нет возможности запустить ни одну из операционных систем, тогда нужно править загрузчик вручную. Это отдельный случай.
Загрузив, допустим, Windows 7, скачиваем и запускаем программу для редактирования загрузки EasyBCD.
Выбираем пункт меню – Добавить запись.
Операционные системы – Windows.
Тип – Windows Vista/7/8, в бесплатной версии Win10 нет, поэтому оставляем так.
Имя – любое понятное для нас, латиницей.
Диск – указываем диск, на который начали устанавливать WinSrv2019.
Нажимаем кнопку «Добавить». После этого на вкладке «Текущие настройки» можно убедиться, что добавился дополнительный пункт в загрузочное меню с нашим новым сервером.
В пункте меню «Редактировать меню загрузки» можно поправить отображаемое при загрузке имя ОС и отметить галочкой, какая система будет загружаться по умолчанию.
Нажимаем кнопку «Сохранить». Перезагружаем ПК и проверяем выполненные настройки. Выбираем из появившегося списка Windows Server 2019 и ждем пока завершится установка ОС.
По внешнему виду ОС очень похожа на Windows 10.
Переименовываем сервер. В нашей сети он будет известен как DCSERVER2. Антивирус можно не ставить т.к. есть встроенный Windows Defender.
Подключаем сервер в локальную сеть, назначаем статический IP-адрес. DNS от основного контроллера домена.
Переходим к настройке контроллера домена.
Запускаем диспетчер серверов, в панели мониторинга нажимаем – Добавить роли и компоненты. Откроется мастер добавления.
Перед началом работы >> Далее.
Тип установки – Установка ролей и компонентов >> Далее.
Выбор сервера – выбираем требуемый DCSERVER2 >> Далее.
Роли сервера – отмечаем галочками DNS-сервер и Доменные службы Active Directory >>Добавить компоненты >> Далее. DHCP в нашей сети не используется.
Компоненты >> Далее.
DNS, AD DS >> Далее.
Подтверждение – Установить.
Ждем установку, если понадобится перезагружаем сервер.
Повысим роль сервера до контроллера домена. В диспетчере серверов нажимаем на флажок, затем в раскрывшемся меню выбираем – Повысить роль этого сервера до уровня контроллера домена.
В первом пункте мастера настройки доменных служб Active Directory выбираем – Добавить контроллер домена в существующий домен.
Напротив надписи Домен нажимаем кнопку «Выбрать». Выбираем нужный домен, у нас SCRB.local. Вводим учетные данные администратора из домена. >>Далее.
Следующим пунктом придумываем пароль для режима восстановления служб каталогов DSRM. Можно оставить галочку напротив надписи Глобальный каталог. >>Далее.
Делегирование для этого DNS-сервера невозможно создать… >>Далее.
Дополнительные параметры – указываем источник репликации – основной контроллер домена DCSERVER.
Пути оставляем без изменения. >> Далее.
Параметры подготовки >> Далее.
Просматриваем выбранные параметры >> Далее.
Во время проверки предварительных данных вылез «подводный камень». Не выполнено одно или несколько предварительных требований. Исправьте ошибки и щелкните «Повторить проверку предварительных требований».
Критическая ошибка отмечена красным кружком с крестиком и звучит так:
Сбой проверки предварительных требований для подготовки Active Directory. Не удалось проверить, завершил ли хозяин схемы цикл репликации после последней перезагрузки.
Исключение: Недопустимое критическое расширение. Расширенное сообщение об ошибке сервера:8366. Расширенное сообщение сервера:000020AE: SvcErr: DSID-032103F9, problem 5010 (UNAVAIL_EXTENSION), data 8610.
Программе Adprep не удалось проверить, завершил ли хозяин схемы цикл репликации после последней перезагрузки. Эта схема не обновлена.
Возможную причину сбоя см. в файле журнала ADPrep.log в каталоге C:\Windows\debug\adprep\logs\2019114122331-test.
Для устранения этой ошибки есть два варианта:
1.Устранить из домена все следы контроллера домена, с которым не прошла репликация.
2.Запустить этот контроллер домена, если он еще «живой», и подождать, пока пройдет репликация.
Воспользуемся вторым вариантом, так как сервер с именем WIN-SRV-ST в нашей сети еще не был деинсталирован и его можно запустить.
После запуска старого резервного контроллера домена на виртуальной машине проверка предварительных требований была пройдена. Жмем кнопку >>Установить.
Окно Результаты можно закрыть. Пройдет установка и сервер автоматически перезагрузится.
После перезагрузки в Active Directory – пользователи и компьютеры, можно увидеть новый контроллер домена DCSERVER2.
Контроллер домена работает. Можно проверить пользователей, они все на месте.
Переходим к удалению предыдущего резервного контроллера домена с ОС Windows Server 2008R2 (WIN-SRV-ST, третий в списке) для того, чтоб разобрать главный сервер на ремонт.
Резервное копирование контроллеров домена с помощью Veeam
Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.
А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями — под кат.
Сервисы Active Directory разработаны с учетом избыточности, поэтому привычные правила и тактики бэкапа необходимо адаптировать соответствующим образом. В данном случае будет неправильно использовать ту же политику бэкапа, что уже работает для серверов SQL или Exchange. Вот несколько рекомендаций, которые могут помочь при разработке политики бэкапа для Active Directory:
- Выясните, какие контроллеры домена в вашей среде выполняют роли FSMO (Flexible Single Master Operations).
Полезно: простая команда для проверки через командную строку: >netdom query fsmo
Выполняя полное восстановление домена, лучше начать с контроллера домена с наибольшим числом ролей FSMO — обычно это сервер с ролью эмулятора основного контроллера домена (PDC). В противном случае после восстановления вам придется переназначать соответствующие роли вручную (при помощи команды ntdsutil seize). - Если вы хотите защитить отдельные объекты, то у вас нет необходимости в бэкапе всех контроллеров, имеющихся на продакшен-площадке. Для восстановления отдельных объектов будет достаточно одной копии базы данных Active Directory (файл ntds.dit).
- Всегда есть возможность снизить риск случайного или намеренного удаления или изменения объектов AD. Можно порекомендовать делегирование административных полномочий, ограничение доступа с повышенными правами, а также репликацию на резервную площадку с предустановленной задержкой.
- Обычно рекомендуется выполнять бэкап контроллеров доменов поочередно и так, чтобы оно не пересекалось с репликацией DFS. Хотя современные решения знают, как решать эту проблему.
- Если вы используете виртуальную среду VMware, контроллер домена может быть недоступен по сети (например, он находится в зоне DMZ). В этой ситуации Veeam переключится на соединение через VMware VIX и сможет обработать этот контроллер.
Если у вас виртуальный DC
Так как сервисы Active Directory потребляют малую часть ресурсов системы, то контроллеры домена обычно становятся первыми кандидатами для виртуализации. Чтобы защитить виртуализованный контроллер с помощью Veeam, нужно установить и настроить Veeam Backup & Replication.
Важно! Решение работает с ВМ контроллера домена на Windows Server 2003 SP1 и выше, минимальный поддерживаемый функциональный уровень леса — Windows 2003. Учетной записи нужно предоставить права администратора Active Directory –— можно работать под учетной записью администратора предприятия или домена.
Процесс установки и настройки Veeam Backup & Replication уже неоднократно освещался – например, в видео, подготовленном системным инженером Veeam, поэтому обойдемся без подробностей. Предположим, что все настроено и готово к работе. Теперь нужно создать задание бэкапа контроллера домена. Процесс настройки довольно прост:
- Запустите мастер создания задания бэкапа.
- Выберите нужный контроллер домена.
- Определите политику хранения (Retention) для цепочки резервных копий.
- Включите функцию обработки данных с учетом состояния приложений (рис. 1), чтобы обеспечить согласованность на уровне транзакций для ОС и приложений, работающих на ВМ (в том числе базы для данных Active Directory и каталога SYSVOL). Для этого выберите опцию Enable application-aware image processing (AAIP).
AAIP — технология Veeam, которая обеспечивает бэкап ВМ с учетом состояния приложений. Она выполняет поиск приложений гостевой ОС, сбор их метаданных, «заморозку» с помощью соответствующих механизмов (Microsoft VSS Writers), подготовку процедуры восстановления с использованием VSS для приложений, которая будет выполнена при первом запуске восстановленной ВМ, а также усечение журналов транзакций в случае успешного завершения бэкапа. Если функция AAIP не будет включена, гостевая ОС контроллера домена не поймет, что был выполнен ее бэкап и обеспечена защита. Поэтому через некоторое время вы можете обнаружить внутреннее предупреждение в журналах сервера Event ID 2089: backup latency interval (т.е. бэкап не выполнялся в течение интервала задержки архивации).
- Настройте расписание задания или запустите его вручную.
- Убедитесь, что задание успешно выполнено.
- Найдите вновь созданный файл резервной копии в репозитории — готово!
Резервную копию можно дополнительно сохранить в облако с помощью поставщика услуг Veeam Cloud Connect (VCC). Также ее можно перенести в другой репозиторий резервных копий, используя задания архивирования резервных копий или функционал архивирования на магнитную ленту. Самое главное, что теперь резервная копия хранится в надежном месте, и из нее в любой момент можно восстановить нужные данные.
Если у вас физический DC
Честно говоря, я надеюсь, что вы идете в ногу со временем, и в вашей компании контроллеры домена давно виртуализованы. Если это не так, то надеюсь, что вы их регулярно обновляете и они работают на относительно современных версиях ОС Windows Server —Windows Server 2008 (R2) и выше. (О нюансах работы с более старыми системами будет отдельная статья).
Итак, у вас есть один или несколько физических контроллеров домена, работающих под Windows Server 2008 R2 и выше, и вы хотите их защитить. В этом случае вам потребуется Veeam Endpoint Backup — решение, предназначенное специально для защиты данных физических компьютеров и серверов. Veeam Endpoint Backup копирует нужные данные с физической машины и сохраняет их в файл резервной копии. В случае аварии вы сможете восстановить данные «на голое железо» или выполнить восстановление на уровне логического диска. Кроме того, вы сможете восстанавливать отдельные объекты с помощью Veeam Explorer для Microsoft Active Directory.
Делаем следующее:
- Загрузите Veeam Endpoint Backup FREE и скопируйте установщик на нужный сервер.
- Запустите мастер установки, примите лицензионное соглашение и установите программу.
Примечание: чтобы выполнить установку в автоматическом режиме, используйте соответствующую инструкцию.
- Создайте задание бэкапа, выбрав нужный режим. Самый простой и рекомендуемый способ — резервное копирование всего компьютера целиком. Используя режим бэкапа на уровне файлов (file-level mode), выберите в качестве объекта копирования операционную систему (Operating system). В этом случае программа скопирует все файлы, необходимые для восстановления «на голое железо». База данных Active Directory и каталог SYSVOL также будут сохранены. Подробнее можно почитать, например, в этом посте.
Примечание: Если в вашей среде уже установлен Veeam Backup & Replication, и вы хотите использовать существующий репозиторий Veeam для хранения резервных копий физических машин, вы можете перенастроить его прямо из Veeam Backup & Replication. Для этого на нужном репозитории щелкните правой кнопкой мыши, удерживая нажатой клавишу CTRL, и в открывшемся диалоге разрешите доступ к репозиторию, выбрав нужную опцию. При необходимости, там же включите шифрование, выбрав Encrypt backups stored in this repository.
- Запустите задание и убедитесь, что оно прошло без ошибок:
Вот и все: бэкап выполнен, контроллер домена под защитой. Перейдите в репозиторий и найдите нужную резервную копию или цепочки резервных копий.
Если вы настроили репозиторий Veeam Backup & Replication в качестве целевого хранилища для резервных копий, то вновь созданные резервные копии будут отображаться в панели инфраструктуры Backups > Disk, пункт Endpoint Backups.
Вместо заключения
Разумеется, успешный бэкап — это хорошее начало, но далеко не все. Очевидно, что резервная копия ничего не стоит, если из нее нельзя восстановить данные. Поэтому в следующей статье я расскажу о различных сценариях восстановления Active Directory, включая восстановление контроллера домена, а также восстановление отдельных удаленных и измененных объектов с помощью собственных инструментов Microsoft и Veeam Explorer для Active Directory.
Второй контроллер домена — Windows Server 2016
После того, как установлен и настроен основной контроллер домена, а также установлен и настроен DHCP-сервер, следует установить и настроить второй, дополнительный контроллер домена. Это необходимо для того, чтобы в случае потери связи или выхода из строя первого контроллера домена, добавочный контроллер домена смог обрабатывать запросы пользователей. Тогда работа в сети будет безостановочной, в случае проблем одного из контроллеров, второй будет выполнять все те же функции.
1. На первом контроллере домена открываем сетевые настройки первого сервера. Для этого в поле поиска набираем ncpa.cpl. Далее выбираем нужный сетевой интерфейс, правый клик — «Свойства — IP версии 4(TCP/IPv4). — Свойства». В поле альтернативный интерфейс, вписываем IP-адрес добавочного контроллера домена (в данном случае 192.168.100.6).
2. Затем переходим на второй сервер и задаём имя будущему серверу: «Этот компьютер — Свойства — Изменить параметры — Изменить». В поле «Имя компьютера» задаём имя серверу, далее «ОК». Потребуется перезагрузка компьютера, соглашаемся.
3. После перезагрузки переходим к настройке сетевого интерфейса. Для этого в поле поиск пишем ncpa.cpl. Выбираем нужный интерфейс, правый клик — «Свойства — IP версии 4(TCP/IPv4). — Свойства». В открывшемся окне заполняем поля:
- IP-адрес: IP-адрес сервера (например, 192.168.100.6)
- Маска подсети: например, 255.255.255.0 (маска 24 бит)
- Основной шлюз: например, 192.168.100.1
- Предпочитаемый DNS-сервер: IP-адрес первого сервера (например, 192.168.100.5)
- Альтернативный DNS-сервер: IP-адрес второго сервера (например, 192.168.100.6)
Затем нажимаем «ОК».
4. Добавляем в домен новый сервер. Для этого выбираем «Этот компьютер — Свойства — Изменить параметры — Изменить». Ставим чекбокс «Является членом домена» и вписываем имя домена. Затем «ОК».
5. В диалоге «Изменение имени компьютера или домена» вводим имя пользователя домена с административными правами (пользователь должен иметь возможность добавлять компьютеры в домен), далее «ОК».
6. При успешной операции появится надпись «Добро пожаловать в домен…». Нажимаем «ОК».
7. После перезагрузки компьютера в окне «Просмотр основных сведений о вашем компьютере» можно проверить напротив «Полное имя», что компьютер вошел в состав домена.
8. На этом подготовительный этап закончен, пора устанавливать необходимые роли на сервер. Для этого открываем «Диспетчер серверов» — «Добавить роли и компоненты». Необходимо установить DNS-сервер, Доменные службы Active Directory, DHCP-сервер.
9. Читаем информацию в окне «Перед началом работы», нажимаем «Далее». В следующем окне «Выбор типа установки» оставляем чекбокс «Установка ролей или компонентов» по умолчанию, снова «Далее». Выбираем наш сервер из пула серверов, затем «Далее».
10. В окне «Выбор ролей сервера» выбираем DNS-сервер, Доменные службы Active Directory, DHCP-сервер. При добавлении роли будет появляться предупреждение, например «Добавить компоненты, необходимые для DHCP-сервер». Нажимаем «Добавить компоненты». После выбора нужных ролей нажимаем «Далее».
11. В новом окне «Выбор компонентов» игнорируем «Выберите один или несколько компонентов для установки на этом сервере», нажимаем Далее. В следующем окне «DHCP-сервер» читаем на что обратить внимание при установке DHCP-сервера, затем «Далее». В новом окне «Подтверждение установки» проверяем выбранные роли, нажимаем «Установить».
12. Появится окно с ходом установки выбранных компонентов. Данное окно можно закрыть, оно на процесс установки уже не влияет.
13. После того, как установятся выбранные компоненты, в «Диспетчер серверов» нажимаем значок предупреждения в виде восклицательного знака, выбираем «Повысить роль этого сервера до уровня контроллера домена».
14. Появится «Мастер настройки доменных служб Active Directory». В окне «Конфигурация развертывания» оставляем по умолчанию чекбокс «Добавить контроллер домена в существующий домен», проверяем название домена в поле «Домен». Напротив поля (текущий пользователь) нажимаем кнопку «Изменить».
15. Вводим логин и пароль пользователя в домене с административными правами. Нажимаем «ОК». Затем «Далее».
16. В окне «Параметры контроллера домена» вводим парль для режима восстановления служб каталогов (DSRM), снова «Далее».
17. В окне «Параметры DNS» игнорируем предупреждение о том, что делегирование для этого DNS-сервера невозможно создать, поскольку полномочная родительская зона не найдена», просто жмем «Далее».
18. В окне «Дополнительные параметры» источник репликации оставляем «Любой контроллер домена», снова «Далее».
19. Расположение базы данных AD DS, файлов журналов и папки SYSVOL оставляем по умолчанию, нажимаем «Далее».
20. Просматриваем параметры, настроенные в «Мастер настройки доменных служб Active Directory», затем «Далее».
21. В окне «Проверка предварительных требований» проверяем, что появился зеленый чекбокс. Таким образом все проверки готовности к установке выполнены успешно. Нажимаем «Установить».
22. В следующем окне читаем, что «Этот сервер успешно настроен как контроллер домена». Читаем предупреждения, нажимаем «Закрыть».
23. Пришло время проверить работоспособность Доменных служб Active Directory и DNS-сервера. Для этого открываем «Диспетчер серверов».
24. Выбираем «Средства» — «Пользователи и компьютеры Active Directory».
25. Открываем наш домен и раскрываем подразделение «Domain Controllers». В окне напротив проверяем наличие второго сервера как контроллера домена.
26. Далее в «Диспетчер серверов» выбираем «Средства» — «DNS».
27. Проверяем наличие IP-адреса второго сервера в зоне прямого и в зоне обратного просмотра.
28. Затем выбираем «Active Directory — сайты и службы».
29. Раскрываем дерево «Active Directory — сайты». Проверяем наличие второго контроллера домена напротив «Servers».
30. Пришло время настроить DHCP-сервер. Для этого на втором сервере выбираем в «Диспетчер серверов» — «Средства» — «DHCP».
31. Выбираем добавочный сервер, правой клавишей мыши — «Добавить или удалить привязки».
32. Проверяем настройку сетевого интерфейса, через который будут обслуживать DHCP-клиенты на втором сервере.
33. Объединяем два DHCP-сервера. Конфигурация высокой доступности, режим балансировка высокой нагрузки. Распределяем нагрузку на сервера 50×50. Для настройки на первом сервере, где установлен и настроен DHCP-сервер, выбираем «Диспетчер серверов» — «Средства» — «DHCP».
34. Правый клик на созданную в DHCP-сервере область, далее «Настройка отработки отказа…».
35. Появится мастер «Настройка отработки отказа», затем «Далее».
36. Указываем сервер-партнер для отработки отказа. Для этого в поле «Сервер партнер» с помощью кнопки «Добавить сервер» добавляем второй (дополнительный) сервер, на котором развернута роль DHCP-сервер. Затем нажимаем «Далее».
37. В поле «Общий секрет» вписываем пароль. Остальные настройки можно оставить по умолчанию, в том числе процент распределения нагрузки Локальный сервер — Сервер партнер — 50% на 50%. Снова «Далее».
38. Проверяем параметры настройки отработки отказа между первым сервером и дополнительным сервером. Нажимаем «Готово».
39. Смотрим в ходе настройки отработки отказа, чтобы все было «Успешно» и закрываем мастер.
40. Открываем второй сервер. «Диспетчер серверов» — «Средства» — «Авторизовать».
41. Проверяем «Пул адресов». Будет произведена синхронизация DHCP-серверов.
На этом процесс установки и настройки Active Directory, DHCP, DNS закончен. Посмотреть, что и как делать, можно здесь:
Читайте также:
Установка DNS и Active Directory — Windows Server 2016
Установка и настройка DHCP — Windows Server 2016
Ввод компьютера в домен — Windows Server 2016
Создание и удаление пользователя, восстановление из корзины — Windows Server 2016
Переименование учётной записи администратора домена — Windows Server 2016
Windows server 2019 — установка и настройка Active Directory, DNS, DHCP
Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server
Кирилл Семаев
Безболезненная замена устаревшего
или отказавшего контроллера домена
на базе Windows Server
Если ваш контроллер домена вышел из строя или полностью устарел и требует замены, не спешите планировать провести ближайшие выходные за созданием нового домена на новом сервере и кропотливым переносом в него пользовательских машин. Грамотное управление резервным контроллером домена поможет быстро и безболезненно заменить предыдущий сервер.
Практически каждый администратор, работающий с серверами на базе Windows, рано или поздно сталкивается с необходимостью замены полностью устаревшего основного контроллера домена, дальнейший «апгрейд» которого больше не имеет смысла, на новый и более соответствующий современным требованиям. Бывают ситуации и хуже – контроллер домена просто-напросто пришел в негодность из-за поломок на физическом уровне, а резервные копии оказались не актуальными или потерялись.
Описание процедуры замены одного контроллера домена на другой можно найти на разных форумах. Информация, как правило, даётся отрывками и применима только к конкретной ситуации, поэтому общего плана действий не даёт. Кроме того, даже вдоволь начитавшись форумов [1], баз знаний [2, 3] и прочих ресурсов, я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.
Таким образом, я хочу привести поэтапную инструкцию замены контроллера домена вне зависимости от того, работоспособен он или нет. Единственная разница заключается в том, что при «упавшем» контроллере эта статья поможет, только если вы заранее позаботились и развернули резервный контроллер домена.
Подготовка серверов к повышению/понижению роли
Процедура создания «резервного» контроллера домена элементарна – мы просто запускаем на любом рядовом сервере сети мастер dcpromo и с его помощью создаём контроллер домена в существующем домене. В результате проделанных манипуляций мы получаем развернутую службу каталогов AD на нашем дополнительном сервере (я буду называть его pserver, а основной контроллер – dcserver).
Дальше, если мастер сам не предложил, запускаем установку DNS-сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Хочется обратить внимание на то, что основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS-сервера должен быть указан IP-адрес основного контроллера домена.
Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать учетную запись как на основном, так и на резервном контроллере домена. Сразу после создания она появляется на дублирующем сервере, но где-то в течение минуты (пока происходит репликация) она видна как отключенная, после чего начинает отображаться одинаково на обоих контроллерах.
На первый взгляд, все манипуляции по созданию исправной схемы взаимодействия как минимум двух контроллеров домена выполнены, и теперь в случае выхода из строя основного контроллера домена резервный контроллер будет автоматически выполнять его функции. Однако, хотя разница между основным и резервным контроллерами домена AD чисто номинальная, основной контроллер имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе основного контроллера недостаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена, будут описаны дальше.
Немного теории
Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):
- Schema Master (хозяин схемы) – роль отвечает за возможность изменения схемы – например, разворачивания Exchange server или ISA server. Если владелец роли будет недоступен, схему существующего домена вы изменить не сможете.
- Domain Naming Master (хозяин операции именования доменов) – роль необходима в том случае, если в вашем лесу есть несколько доменов или поддоменов. Без неё не получится создавать и удалять домены в лесу.
- Relative ID Master (хозяин относительных идентификаторов) – отвечает за создание уникального ID для каждого объекта AD.
- Primary Domain Controller Emulator (эмулятор основного контроллера домена) – именно он отвечает за работу с учётными записями пользователей и политику безопасности. Отсутствие связи с ним позволяет входить на рабочие станции со старым паролем, который нельзя сменить, если контроллер домена «упал».
- Infrastructure Master (хозяин инфраструктуры) – роль отвечает за передачу информации об объектах AD прочим контроллерам домена в рамках всего леса.
Об этих ролях подробно написано во многих базах знаний. Зачастую администраторы забывают назначить роль хранителя глобального каталога. Его недоступность не позволит доменным пользователям входить в систему. Что примечательно, роль хранителя глобального каталога могут иметь все контроллеры домена одновременно.
Фактически можно сделать вывод: если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены, то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить.
Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были назначены при работающем контроллере домена и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.
Определение текущих владельцев ролей FSMO
Напомню, что мы хотим заменить контроллер домена, не нанеся вреда работе службы каталогов. Поэтому в том случае, если в домене два или более контроллеров, нам необходимо выяснить, кто является обладателем каждой из ролей FSMO.
Это достаточно просто сделать, использовав следующие команды:
dsquery server -hasfsmo schema
dsquery server -hasfsmo name
dsquery server -hasfsmo rid
dsquery server -hasfsmo pdc
dsquery server -hasfsmo infr
dsquery server -forest -isgc
Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (см. рис. 1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.
Рисунок 1. Владелец роли rid master – dcserver
Добровольная передача ролей FSMO при помощи консолей Active Directory
Вся информация, необходимая для передачи роли основного контроллера домена, у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo – управлением доменом через консоли Active Directory.
Для передачи роли «хозяина именования домена» выполняем следующие шаги:
- Открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем.
- Щёлкаем правой кнопкой мыши на значке Active Directory – домены и доверие и выбираем команду «Подключение к контроллеру домена». Выбираем тот контроллер домена, которому хотим передать роль.
- Щелкаем правой кнопкой мыши компонент Active Directory – домены и доверие и выбираем команду Хозяева операций.
- В диалоговом окне «Изменение хозяина операций» нажимаем кнопку «Изменить» (см. рис. 2).
- После утвердительного ответа на всплывающий запрос получаем успешно переданную роль.
Рисунок 2. Процесс передачи роли хозяина именования доменов серверу pserver
Аналогичным образом при помощи консоли «Active Directory – пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».
Для передачи роли «хозяина схемы» необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory:
regsvr32 schmmgmt.dll
Далее в консоль mmc необходимо добавить оснастку «Схема Active Directory», в которой, аналогично предыдущим пунктам, можно изменить владельца роли.
После того как все роли переданы, остаётся разобраться с оставшейся опцией – хранителем глобального каталога. Заходим в «Active Directory – Сайты и Службы», далее выбираем «сайт по умолчанию», находим контроллер домена, ставший основным, и в свойствах его NTDS settings ставим галочку напротив global catalog (см. рис. 3).
Рисунок 3. Теперь глобальный каталог лежит на pserver
Итог – мы поменяли владельца ролей FSMO для нашего домена. Кому нужно окончательно избавиться от старого контроллера домена – понижаем его до рядового сервера. Однако в ряде ситуаций проведение операции по передаче ролей вышеописанным способом невозможно. В этих случаях нам поможет ntdsutil.exe.
Добровольная передача ролей FSMO при помощи утилиты ntdsutil
NTDSUTIL – программа обслуживания каталога Active Directory. Этот инструмент позволяет выполнять чрезвычайно полезные действия – вплоть до восстановления всей базы данных AD из резервной копии, которую эта утилита сама создала во время последнего изменения в AD. Со всеми её возможностями можно ознакомиться в базе знаний Microsoft (код статьи: 255504). В данном случае мы говорим о том, что утилита ntdsutil.exe позволяет как передавать роли, так и «отбирать» их.
Если мы хотим передать роль от существующего основного контроллера домена к резервному, мы заходим в систему на основной контроллер и начинаем передавать роли (команда transfer). Если у нас по каким-то причинам отсутствует основной контролер домена или мы не можем войти под административной учетной записью, мы входим в систему на резервный контроллер домена и начинаем «отбирать» роли (команда seize).
Итак, первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:
ntdsutil.exe
roles
connections
connect to server имя_сервера (того, кому хотим отдать роль)
q
Если выскакивают ошибки, нужно проверить связь с тем контроллером домена, к которому мы пытаемся подключиться. Если ошибок нет – значит мы успешно подключились к указанному контроллеру домена с правами того пользователя, от имени которого вводим команды.
Полный список команд доступен после запроса fsmo maintenance с параметром «?». Пришла пора передавать роли. Я с ходу, не задумываясь, решил передавать роли в том порядке, в каком они указаны в инструкции к ntdsutil, и пришёл к тому, что не смог передать роль хозяина инфраструктуры. Мне в ответ на запрос о передаче роли возвращалась ошибка: «невозможно связаться с текущим владельцем роли fsmo». Я долго искал информацию в сети и обнаружил, что большинство людей, дошедших до этапа передачи ролей, сталкиваются с этой ошибкой. Часть из них пытается отобрать эту роль принудительно (не выходит), часть оставляет всё как есть и благополучно живёт без этой роли.
Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:
- хозяин операции именования доменов;
- хозяин инфраструктуры;
- хозяин идентификаторов;
- хозяин схемы;
- контроллер домена.
После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance) и можем начать передавать роли:
- transfer domain naming master;
- transfer infrastructure master;
- transfer rid master;
- transfer schema master;
- transfer pdc master.
После выполнения каждой команды должен выходить запрос о том, действительно ли мы хотим передать указанную роль указанному серверу. Результат удачного выполнения команды показан на рис. 4.
Рисунок 4. Так выглядит корректная передача роли rid master серверу pserver
Роль хранителя глобального каталога передаётся способом, описанным в предыдущем разделе.
Принудительное присваивание ролей FSMO при помощи ntdsutil.exe
Второй случай – мы хотим присвоить нашему резервному контроллеру домена роль основного. В этом случае ничего не меняется – единственная разница в том, что мы проводим все операции с использованием команды seize, но уже на том сервере, которому хотим передать роли для присвоения роли.
Обратите внимание – если вы отобрали роль у контроллера домена, отсутствующего в данный момент, то при его появлении в сети контроллеры начнут конфликтовать, и проблем в функционировании домена вам не избежать.
Работа над ошибками
Самое главное, о чём не следует забывать: новый основной контроллер домена сам себе настройки TCP/IP не исправит – ему адресом первичного DNS-сервера теперь желательно (а если старый контроллер домена + DNS-сервер будут отсутствовать, то обязательно) указать 127.0.0.1.
При этом если у вас в сети есть DHCP-сервер, то нужно заставить его выдавать адресом первичного DNS-сервера IP вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же IP, что был у старого.
Теперь необходимо проверить, как всё работает, и избавиться от основных ошибок. Для этого я предлагаю на обоих контроллерах стереть все события с сохранением журналов в папку с прочими резервными копиями и перезагрузить все серверы.
После их включения внимательно анализируем все журналы событий на факт появления предупреждений и ошибок.
Самым распространённым предупреждением после передачи ролей fsmo является сообщение о том, что «msdtc не может корректно обработать произошедшее повышение/понижение роли контроллера домена».
Исправляется просто: в меню «Администрирование» находим «Службы компонентов». Раскрываем «Службы компонентов», «Компьютеры», открываем свойства раздела «Мой компьютер», ищем там «MS DTC» и жмем там «Настройки безопасности». Там разрешаем «Доступ к сети DTC» и нажимаем ОК. Служба будет перезапущена, и предупреждение исчезнет.
Примером ошибки может служить сообщение о том, что основная DNS-зона не может быть загружена либо DNS-сервер не видит контроллер домена.
Рисунок 5. Результат успешного выполнения команды dcdiag на pserver
Разобраться в проблемах функционирования домена можно при помощи утилиты (см. рис. 5):
dcdiag
Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами «successfully passed». Если результатом теста является надпись «failed» (чаще всего это тесты connection или systemlog), то ошибку можно попробовать «вылечить» в автоматическом режиме:
dcdiag /v /fix
Как правило, все ошибки, связанные с DNS, должны пропасть. Если нет – пользуемся утилитой проверки состояния всех сетевых служб:
netdiag
И её полезным инструментом устранения ошибок:
netdiag /v /fix
Если и после этого остаются ошибки, связанные с DNS, проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:
dcdiag /test:dns
По окончании проделанных работ у меня ушло ещё где-то 30 минут на выяснение причины появления ряда предупреждений – я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы – самое главное, не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.
- http://technet.microsoft.com.
- http://www.petri.co.il.
- http://support.microsoft.com.
Резервное копирование домен контроллера | Реальные заметки Ubuntu & Mikrotik
Прочитано:
1 541
Интересную задачу я себе подкинул. В связи с обновление домена до уровня 2008 R2, перед тем как следовать своей заметке (кстати уже не раз проделывал данную операцию), заметил, а почему я не сделал бекап контроллера домена и не проработал на стенде его восстановление в случае если что-то пошло не так. Не правильно. Все нужно резервировать и прорабатывать перед тем, как вносить какие-либо существенные изменения. Еще раз повторюсь, страховка должна иметь место быть, не стоит относится к этому легкомысленно.
И так домен контроллер поднят по заметке:
Все роли у текущего сервера на базе Windows Server 2003 R2:
C:\Documents and Settings\ekzorchik>netdom query fsmo
- Schema owner srv-dc.polygon.local
- Domain role owner srv-dc.polygon.local
- PDC role srv-dc.polygon.local
- RID pool manager srv-dc.polygon.local
- Infrastructure owner srv-dc.polygon.local
The command completed successfully.
Для того, чтобы сделать резервную копию мне понадобится,
либо подключить к системе еще один диск , либо использовать сетевой ресурс.
В рамках этой заметки я проведу Вас по всем шагам, но тестировать поставленную задачу перед тем как проводить на боевой буду с использование тестового окружения под VirtualBox. Я возвращаюсь к данной операционной системе потому, как еще во многих организациях не все так интересно в плане современных технологий, они как бы остались в прошлом и вот от этого прошлого нужно уходить, а перед тем как уходить нужно все задокументировать на последующие разы работы в других организациях, где мой опыт может здорово пригодиться.
Итак диск подключен, далее следующие шаги чтобы осуществить резервное копирование:
Авторизуемся на домен контроллере (name: srv-dc) под учетной записью ekzorchik (полные права над инфраструктурой, группы: Domain Admins, Enterprise Admins, Schema Admins)
Запускаем оснастку:
Start — All Programs — Accessories — System Tools — Backup либо Win+R → ntbackup.exe, далее в режиме Мастера (Backup or Restore Wizard) следуем за ним по шагам, Next, на вопрос ,что мы будем сейчас делать выбираем пункт:
- What do you want to do? Back up files and settings
- What do you want to back up? Let me choose what to back up
Далее из представленного нужно активировать галочкой → System State (в свою очередь это включает в себя: Active Directory, Boot Files, COM+ Class Registration Database,Registry,SYSVOL)
После нажимаем Next и указываем месторасположение и именование создаваемой резервной копии состояния системы:
- Choose a place to save your backup: Browse — My Computer — находим логический диск (который я ранее подключил в систему: Disk E) и указываю именование для бекапа: StateSRVDC30092015 и нажимаю Save в конечном итоге должно получиться вот так:
После нажимаем Next и оказываемся на результирующем этапе где нужно нажать Finish и запуститься процедура резервного копирования, но прежде перехожу (не обязательно) в Advanced…
- Select the type of backup: Normal
- отмечаю: Backup migrated Remote Storage data
- Select the options you want to use: Verify data after backup
- и отмечаю: Replace the existing backups (заменить существующие бекапы)
- When do you want to run the backup? Now
После нажимаем Finish и ожидаем завершения процесса
Полученный размер резервной копии в моем случае составил: 814Mb отлично, но вот так вот по шагам проходить и делать резервную копию как-то совсем не интересно нужно подготовить скрипт который будет делать все за меня:
C:\Documents and Settings\ekzorchik>cd /d c:\
C:\>taskkill /IM "ntbackup.exe" /F
C:\>ntbackup.exe backup systemstate /v:yes /m normal /j "srv-dc system state bac
kup" /l:f /f "e:\StateSRVDC.bkf"
в итоге скрипт для бекапирования и создания резервной копии текущей даты получается таким:
for /f "Tokens=1-4 Delims=/ " %%i in ('date /t') do set dt=%%i-%%j-%%k-%%l
for /f "Tokens=1" %%i in ('time /t') do set tm=-%%i
set tm=%tm::=-%
set dtt=%dt%%tm%
taskkill /IM "ntbackup.exe" /F
ntbackup.exe backup systemstate /v:yes /m normal /j "srv-dc system state backup" /l:f /f "e:\StateSRVDC_%dtt%.bkf"
После отработки скрипта полученный бекап именуется, как: StateSRVDC_Thu-10-01-2015-10-49.bkf — что мне и нужно.
Что есть командные ключи используемые при создании резервной копии:
/v: Задает проверку данных после архивации | |
/J: Имя задания, которое будет упоминаться в журнале архивации. Обычно, оно описывает диски и папки, подлежащие архивации, а также содержит дату и время архивации | |
/L: Задает тип файла журнала: f — полный, s — сокращенный, n — журнал не создается. Вы не можете управлять именем файла журнала, который всегда создается в папке, указанной в разделе Архивация | |
/m: Задает тип архива. Допустимые значения ключа: normal (по умолчанию), copy , differential , incremental , daily | |
systemstate: Указывает, что должно быть выполнено резервное копирование состояния системы. При указании этого ключа возможна только обычная или копирующая архивация | |
/HC:yes При возможности включает использование аппаратного сжатия данных | |
/F: местонахождение куда записывать формируемый бекап (в моем случае на логический диск E:) |
Теперь данный скрипт нужно поместить в планировщик и указать интервал когда его толкать.
А так цель поставленную в начале я достиг, я разобрал шаги, как через GUI интерфейс утилиты ntbackup, как осуществить резервное копирование всего состояния так с иcпользованием командной строки. В следующей заметке я затрону самую интересную часть, а именно имея сделанную резервную копию восстановить работоспособность домен контроллера, но хватит теории, пора прощаться, до встречи с уважением автор блога — ekzorchik.
Active Directory: автоматизация резервного копирования состояния системы — статьи TechNet — США (английский)
Active Directory (AD) — один из важнейших компонентов любой ИТ-инфраструктуры. В среде на базе Windows почти все приложения и инструменты интегрированы с Active Directory для аутентификации, просмотра каталогов,
и единый вход.
Из-за этой сильной зависимости необходимо иметь четко определенный процесс для резервного копирования AD.
В этой статье мы обсудим все важные моменты, касающиеся резервного копирования Active Directory.Мы также увидим, как автоматизировать резервное копирование AD с помощью запланированной задачи.
Прежде чем продолжить, важно иметь в виду следующие моменты:
- Восстановление резервной копии Active Directory должно быть ПОСЛЕДНИМ вариантом для любого аварийного восстановления .
- В случае сбоя одного контроллера домена рекомендуется понизить уровень контроллера домена, подождать несколько часов, чтобы воспроизвести понижение, а затем снова повысить его.
- Нет необходимости восстанавливать резервную копию Active Directory для восстановления / восстановления одного контроллера домена.Восстановление из резервной копии Active Directory требуется только в том случае, если по какой-либо причине необходимо восстановить / восстановить базу данных AD.
- Не восстанавливать резервную копию Active Directory для восстановления удаленных объектов. Мы настоятельно рекомендуем включить корзину AD и использовать эту функцию для восстановления на уровне объектов, а не для восстановления резервной копии AD.
Наша первая цель — создать эффективную политику резервного копирования Active Directory . Политика резервного копирования будет определять подход к резервному копированию, инструмент, частоту, место резервного копирования и многие другие важные моменты.
Подход к резервному копированию
Наиболее распространенный и рекомендуемый подход для резервного копирования AD — это резервное копирование состояния системы контроллера домена .
Резервная копия состояния системы контроллера домена включает следующее:
- Sysvol
- База данных Active Directory и связанные файлы.
- Зоны и записи DNS (только для интегрированного DNS AD)
- Системный реестр.
- База данных регистрации звонков службы компонентов.
- Файлы запуска системы.
Инструмент резервного копирования
На рынке доступно множество инструментов сторонних производителей для резервного копирования и восстановления Active Directory. Тем не менее
Инструмент Windows Server Backup (WBADMIN), поставляемый в комплекте со всеми версиями Windows Server, отлично подходит для этой цели.
В этой статье мы обсудим инструмент WBADMIN, входящий в состав Windows Server 2012 R2. В этом выпуске инструмент WBADMIN снабжен некоторыми замечательными функциями, которые мы обсудим в следующих разделах.
Частота резервного копирования
Мы настоятельно рекомендуем ежедневное резервное копирование . В корпоративной среде, где данные меняются каждую секунду, восстановление старой резервной копии не имеет смысла.
Более того, Microsoft рекомендует следующее: «Любая резервная копия старше времени жизни захоронения, установленного в Active Directory, не является хорошей резервной копией».
Для крупного предприятия мы настоятельно рекомендуем выполнять резервное копирование состояния системы два раза в день. Инструменты резервного копирования Windows Server делают инкрементное резервное копирование, поэтому дисковое пространство здесь не имеет большого значения.
Какие контроллеры домена для резервного копирования
Обратите внимание, что в многодоменном лесу резервное копирование каждого домена требуется отдельно.
Это связано с тем, что существует несколько разделов, которые отличаются для каждого домена, например раздел домена и раздел DomainDnsZone.
Microsoft рекомендует сделать резервную копию как минимум двух контроллеров домена для каждого домена , и один из этих двух контроллеров домена должен быть владельцем роли хозяина операций.Однако Microsoft не рекомендует
восстановление контроллера домена с ролью мастера RID. Это сделано для того, чтобы избежать конфликта блоков RID в будущем.
Основываясь на рекомендации Microsoft, мы решили настроить резервное копирование на двух контроллерах домена в каждом домене, которые находятся в разных географических точках и далеко друг от друга. Это обеспечит лучшую избыточность и
мы запланируем резервное копирование таким образом, чтобы резервные копии обоих контроллеров домена выполнялись в разное время.
Метод резервного копирования
После того, как резервное копирование состояния системы запланировано с помощью инструмента WBADMIN, первое резервное копирование будет полным резервным копированием, за ним последуют 14 последующих инкрементных резервных копий, а затем снова будет еще одно полное резервное копирование.
Таким образом, он будет следовать приведенному ниже шаблону, и это не может быть изменено:
Первая полная резервная копия> 14 дополнительных резервных копий> 1 полная резервная копия> 14 дополнительных резервных копий> 1 полная резервная копия> 14 дополнительных резервных копий … и так далее.
↑ Вернуться к началу
Место резервного копирования
Не храните резервную копию в общей сетевой папке. Управление версиями резервных копий и автоматическое управление пространством (которое мы рассмотрим в следующем разделе) не будут работать через общий сетевой ресурс.
Это связано с тем, что WBADMIN выполняет резервное копирование на уровне блоков с помощью VSS, которое не работает через SMB.
Всегда храните резервную копию на локальном несистемном томе, предназначенном для хранения резервной копии. Локальный диск можно подключить из SAN или (в случае виртуальной машины) из хранилища данных, но он должен быть смонтирован таким образом, чтобы
отображается как локально смонтированный диск в средстве управления дисками.
Как упоминалось ранее, мы не будем хранить на этом томе больше ничего. Кроме того, мы не можем использовать системный диск (обычно диск C) для хранения резервной копии, поскольку WBADMIN не позволяет хранить резервную копию на системном диске.
Диск, на котором хранится резервная копия состояния системы, следует регулярно резервировать. Это будет «Резервное копирование резервной копии», которое гарантирует доступность резервной копии в случае, если диск недоступен или поврежден.
Резервное копирование версий
Windows Server Backup хранит версии резервных копий в теневых копиях тома .После завершения записи данных WBADMIN создает теневую копию тома, на котором хранится резервная копия, с помощью службы теневого копирования тома (VSS).
Эта теневая копия сохраняет состояние на момент времени тома хранилища, где хранится резервная копия, и каждое состояние на момент времени называется версией резервной копии.
Управление версиями резервных копий — одна из наиболее интересных функций инструмента WBADMIN. Для каждой резервной копии не будет отдельной папки, вместо этого будет управление версиями для каждого экземпляра резервной копии.
Каждый раз, когда запускается задание резервного копирования (вручную или с помощью запланированного задания), создается новая версия с уникальным идентификатором моментального снимка и временной меткой.
Команда «WBADMIN получить версии» покажет все моментальные снимки, которые имеются на этом сервере.
Управление дисковым пространством
WBADMIN в Windows Server 2012 R2 предлагает еще одну замечательную функцию — автоматическое управление дисковым пространством.
Когда мы планируем резервное копирование с помощью инструмента WBADMIN, нам не нужно беспокоиться об управлении дисковым пространством, и нам не нужно удалять какие-либо резервные копии, чтобы разместить новые резервные копии.Этим полностью управляет и заботится инструмент, который
удаляет самые старые версии резервных копий по мере необходимости для управления дисковым пространством.
Функция автоматического управления дисками не работает, если резервные копии хранятся в общей сетевой папке.
Сервисный счет
Последнее, что нам нужно запланировать, — это учетная запись службы, которая будет использоваться для выполнения запланированной задачи.
Мы рекомендуем использовать встроенный в NT AUTHORITY \ SYSTEM аккаунт . Преимущество в том, что нам не нужно беспокоиться об управлении паролями и истечении срока действия пароля.Однако это решение зависит от политики организации.
Если мы используем любую другую учетную запись AD для запуска задачи, мы должны убедиться, что «Пароль никогда не истекает», в противном случае резервное копирование прекратится, когда истечет срок действия пароля.
Обзор политики резервного копирования
Теперь, когда мы рассмотрели все моменты, давайте подведем итоги нашей политики резервного копирования. Для организации важно задокументировать эту политику резервного копирования и получить одобрение всех ключевых заинтересованных сторон.
Резервный подход | Резервное копирование состояния системы |
Инструмент резервного копирования | Резервное копирование Windows Server (WBADMIN.EXE) |
Операционная система | Windows Server 2012 R2 |
Частота резервного копирования | Ежедневно |
Контроллеры домена для резервного копирования | Как минимум два контроллера домена на домен, один из которых должен быть держателем роли FSMO |
Метод резервного копирования | Через запланированную задачу (1 полная> 14 инкрементальных> 1 полная> 14 инкрементальных) |
Где хранить резервную копию | На несистемном диске, смонтированном как локальный диск.Не в сетевой папке. |
Резервное копирование версий | Управление версиями будет осуществляться автоматически с помощью средства резервного копирования |
Управление дисковым пространством | Будет автоматически управляться инструментом резервного копирования |
Сервисный счет | NT AUTHORITY \ SYSTEM |
Мы создали нашу политику резервного копирования и проверили ее. Пришло время реализовать решение для резервного копирования.
Мы собираемся настроить его на контроллере домена DC1.subhro.org. Операционная система контроллера домена — Windows Server 2012 R2.
Шаг 1. Подготовьте выделенный том для хранения резервной копии
Мы подготовили новый том (E :), отформатированный в NTFS. Поскольку это тестовая среда, размер диска составляет 20 ГБ. Однако для производственной среды мы рекомендуем не менее 200 ГБ. Диск большего размера
разрешить сохранение на диске количества версий (снимков).
↑ Вернуться к началу
Шаг 2. Снятие ограничения теневого копирования для тома резервной копии
- Выберите «Мой компьютер»> «Резервный диск» (в данном случае — диск)> щелкните правой кнопкой мыши> «Свойства».
- Перейдите в Теневые копии и выберите диск E> Свойства.
- Установите для максимального размера значение «Без ограничений» и сохраните настройки.
Шаг 3. Установка функции резервного копирования Windows Server
- Перейдите в Диспетчер серверов> Добавить роли и компоненты> Функции> Резервное копирование Windows Server.
- Установить инструмент.
- После этого перейдите в «Выполнить»> «Введите wbadmin.msc».
- Теперь мы должны увидеть консоль WBADMIN.
Как мы видим, на этом контроллере домена не настроено резервное копирование и не выполняется резервное копирование вручную.
На этом этапе, если мы запустим команду «WBADMIN получить версии», мы увидим ниже вывод, что резервная версия недоступна.
↑ Вернуться к началу
Шаг 4. Настройка резервного копирования состояния системы
У нас есть инструмент и том, так что теперь давайте настроим запланированную задачу.
- В правой части консоли щелкните «Расписание резервного копирования».
- Щелкните «Выборочная» в конфигурации резервного копирования.
- На следующем экране нажмите Advanced Settings> VSS Settings.
- Поскольку мы не используем сторонние инструменты для резервного копирования AD, выберите «VSS Full backup».
- Выберите «Состояние системы» из списка элементов резервного копирования.
- Настроить расписание резервного копирования.
- Выберите «Резервное копирование на том» в типе места назначения. Как уже говорилось, некоторые ключевые функции не будут работать, если местом назначения является сетевая папка.
- Выберите целевой том.
- Просмотрите конфигурацию.
- Подтверждающее сообщение появится, если конфигурация прошла успешно.
↑ Вернуться к началу
Шаг 5. Настройка задачи расписания
- Перейти к управлению компьютером (Compmgmt.msc) и откройте планировщик заданий.
- Перейдите в библиотеку планировщика заданий> Microsoft> Windows> резервное копирование
- Мы должны увидеть запланированную задачу, уже созданную мастером WBADMIN, который мы запускали в предыдущем разделе.
Откройте запланированное задание и измените значение «Настроено для» на «Windows Server 2012 R2», как показано на диаграмме ниже.
Мы также должны убедиться, что задача выполняется под учетной записью «NT AUTHORITY \ SYSTEM».
↑ Вернуться к началу
Шаг 6: Запустите первое резервное копирование.
Мы запустим первую резервную копию вручную, чтобы убедиться, что все работает должным образом.
Чтобы запустить запланированную задачу, мы должны включить опцию «Запускать задачу по запросу» в настройках задачи. После завершения первого резервного копирования мы должны отключить этот параметр, чтобы никто не запускал его вручную.
Итак, мы включили эту опцию и запустили запланированное задание. Поскольку это первая резервная копия и полная резервная копия, для завершения резервного копирования потребуется некоторое время.
Шаг 7. Выполнение последующих резервных копий
Следующее резервное копирование будет инкрементным, независимо от того, запускаем ли мы его вручную или через запланированное задание.
Когда следующая резервная копия будет завершена, мы сможем снова проверить версии, и теперь мы должны увидеть две доступные версии, созданные с двумя разными отметками времени.
Обратите внимание, что резервные копии будут храниться в формате диска Hyper-V (VHDX).
На скриншоте ниже показаны сведения о версии после 3 запусков.
↑ Вернуться к началу
Мы столкнулись со следующей ошибкой в нескольких контроллерах домена, и сбой резервного копирования с этой ошибкой:
Неправильное имя файла, имя каталога или синтаксис метки тома.
Когда мы получаем эту ошибку, мы должны проверить ниже два раздела реестра и убедиться, что они содержат правильное значение ключа:
Путь к ключу: HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Services \ LSI_SAS
- Значение ключа: system32 \ drivers \ lsi_sas.sys
2) Путь к ключу: HKLM \ SYSTEM \ CurrentControlSet \ Services \ vsock
- Значение ключа: system32 \ DRIVERS \ vsock.sys
Если значение отличается от этого, исправьте значение и перезагрузите контроллер домена. Пожалуйста, примите время простоя и надлежащее одобрение перед изменением значений реестра, и пожалуйста, сделайте резервную копию реестра, прежде чем делать какие-либо
менять.
Кроме того, иногда автоматическое управление пространством работает некорректно, и резервное копирование не удается из-за проблем с дисковым пространством.Обычно эту проблему решает перезагрузка контроллера домена.
В этой статье мы обсудили политику резервного копирования Active Directory. Мы также обсудили, как развертывать и автоматизировать ежедневное резервное копирование состояния системы с помощью встроенного средства резервного копирования Windows. Как упоминалось ранее, восстановление резервной копии AD должно
быть ПОСЛЕДНИМ вариантом в любой производственной среде.
Настройка и автоматизация резервного копирования AD — это одна часть. Другая часть, которая не менее важна, — это мониторинг и обеспечение выполнения заданий резервного копирования по расписанию и, что более важно, успешное резервное копирование.в отличие от
резервное копирование конфигурации, это не разовая задача, а ежедневная или еженедельная; в зависимости от частоты резервного копирования.
Можно ли автоматизировать мониторинг резервного копирования без использования сторонних инструментов? Можем ли мы получать уведомление по электронной почте после каждого задания резервного копирования с указанием статуса успешного / неудачного резервного копирования?
Ответ — да, мы можем автоматизировать это без использования каких-либо дополнительных инструментов и с помощью собственного решения Windows.
Решение, которое я предлагаю здесь, протестировано, и мы используем его в производственной среде в течение последнего года.С тех пор мы получаем все отчеты об успехах и сбоях резервного копирования без каких-либо задержек. Это спасло
нам много времени и усилий, и я считаю, что это сэкономит вам много усилий, как только вы его реализуете.
Прочтите мою следующую статью:
Автоматическое уведомление об успешном завершении резервного копирования
↑ Вернуться к началу
- https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2000/bb727048(v=technet.10)
- https: // блоги.technet.microsoft.com/filecab/2009/06/22/backup-version-and-space-management-in-windows-server-backup/
- https://lennox-it.uk/a-complete-guide-to-wbadmin-windows-backups
.
Ключевые передовые практики резервного копирования Active Directory
Блог NAKIVO> Резервное копирование и репликация NAKIVO> Рекомендации по резервному копированию Active Directory
25 марта 2019
по Майкл Бозе
Active Directory — широко известная служба для централизованного управления и аутентификации пользователей в средах на базе Windows.Администраторы могут централизованно управлять компьютерами, добавленными в домен, что удобно и экономит время для большой и распределенной инфраструктуры. MS SQL и MS Exchange обычно требуют Active Directory. Если контроллер домена Active Directory (AD DC) становится недоступным, связанные пользователи не могут войти в систему, а системы не могут работать должным образом, что может вызвать проблемы в вашей среде. Вот почему так важно создать резервную копию Active Directory. Сегодняшняя запись в блоге объясняет передовые методы резервного копирования Active Directory, включая эффективные методы и инструменты.
NAKIVO Backup & Replication — это комплексное решение для резервного копирования и восстановления сайта, которое помогает защитить ваши данные и следовать передовым методам резервного копирования Active Directory. С помощью Windows Server Backup вы можете выполнять беспрепятственное резервное копирование данных Active Directory, гарантируя, что данные вашего приложения останутся транзакционно согласованными при любых обстоятельствах.
Принцип работы Active Directory
Active Directory — это система управления, состоящая из базы данных, в которой хранятся отдельные объекты и журналы транзакций.База данных разделена на несколько разделов, содержащих различные типы информации — раздел схемы (который определяет структуру базы данных AD, включая классы объектов и их атрибуты), раздел конфигурации (информация о структуре AD) и контекст доменных имен (пользователи, группы, принтер объекты). База данных Active Directory имеет иерархическую древовидную структуру. Файл Ntds.dit используется для хранения базы данных AD.
Active Directory использует протоколы LDAP и Kerberos для своей работы в сети.LDAP (облегченный протокол доступа к каталогам) — это открытый кросс-платформенный протокол, используемый для доступа к каталогам (например, Active Directory), который также имеет доступ к аутентификации служб каталогов с использованием имени пользователя и пароля. Kerberos — это протокол безопасной аутентификации и единого входа, в котором используется криптография с секретным ключом. Имена пользователей и пароли, проверенные сервером аутентификации Kerberos, хранятся в каталоге LDAP (в случае использования Active Directory).
Active Directory тесно интегрирован с DNS-сервером, защищенными системными файлами Windows, системным реестром контроллера домена, а также с каталогом Sysvol, базой данных регистрации классов COM + и информацией о службе кластера.Такая интеграция напрямую влияет на стратегию резервного копирования Active Directory.
Какие данные необходимо резервировать?
Согласно предыдущему разделу, вам необходимо сделать копию не только Ntds.dit , но и всех компонентов, интегрированных с Active Directory. Список всех компонентов, которые являются неотъемлемыми частями системы контроллера домена, выглядит следующим образом:
- Доменные службы Active Directory
- Системный реестр контроллера домена
- Sysvol справочник
- База данных регистрации класса COM +
- Информация о зоне DNS интегрирована с Active Directory
- Системные файлы и загрузочные файлы
- Сервисная информация кластера
- База данных служб сертификатов (если ваш контроллер домена является сервером службы сертификатов)
- Мета-папки IIS (если на вашем контроллере домена установлены службы Microsoft Internet Information Services)
Общие рекомендации по резервному копированию AD
Давайте взглянем на некоторые общие рекомендации по резервному копированию Active Directory.
По крайней мере, один контроллер домена в домене должен быть зарезервирован
Очевидно, что если у вас есть только один контроллер домена в вашей инфраструктуре, вы должны создать резервную копию этого DC. Если у вас более одного контроллера домена, вы должны создать резервную копию по крайней мере одного из них. Вы должны создать резервную копию контроллера домена, на котором установлены роли FSMO (Flexible Single Master Operation). Если вы потеряли все контроллеры домена, вы можете восстановить основной контроллер домена (содержащий роли FSMO) и развернуть новый дополнительный контроллер домена, реплицируя изменения с основного контроллера домена на дополнительный контроллер домена.
Включите резервную копию Active Directory в план аварийного восстановления
Составьте план аварийного восстановления (DR) с несколькими сценариями восстановления вашей инфраструктуры при подготовке к гипотетическим авариям. Лучшая практика — создать тщательный план аварийного восстановления до того, как произойдет катастрофа. Обратите особое внимание на последовательность восстановления. Имейте в виду, что перед восстановлением других компьютеров со службами, связанными с Active Directory, необходимо восстановить контроллер домена, поскольку они могут стать бесполезными без AD DC.Создание работоспособного плана аварийного восстановления, учитывающего зависимости различных служб, работающих на разных машинах, гарантирует вам успешное восстановление. Вы можете создать резервную копию контроллера домена на локальном сайте, удаленном сайте или в облаке. Одна из лучших практик резервного копирования Active Directory — иметь более одной копии вашего контроллера домена в соответствии с правилом резервного копирования 3-2-1.
Регулярное резервное копирование Active Directory
Следует регулярно выполнять резервное копирование Active Directory с интервалом, не превышающим 60 дней.Службы AD предполагают, что возраст резервной копии Active Directory не может превышать время жизни объектов захоронения AD, которое по умолчанию составляет 60 дней. Это связано с тем, что Active Directory использует объекты-захоронения, когда объекты необходимо удалить. Когда объект AD удаляется (удаляется большинство атрибутов указанного объекта), он помечается как объект захоронения и не удаляется физически, пока не истечет период существования захоронения. Если в вашей инфраструктуре несколько контроллеров домена и включена репликация Active Directory, объект захоронения копируется на каждый контроллер домена до истечения срока службы захоронения.Если вы восстановите один из контроллеров домена из резервной копии, возраст которой превышает срок службы захоронения, вы столкнетесь с противоречивой информацией между контроллерами домена Active Directory. В этом случае восстановленный контроллер домена будет иметь информацию об объектах, которые больше не существуют. Соответственно, это может вызвать ошибки.
Если вы установили какие-либо драйверы или приложения на контроллер домена после создания резервной копии, они не будут работать после восстановления из указанной резервной копии, поскольку состояние системы (включая реестр) будет восстановлено до предыдущего состояния.Это еще одна причина для резервного копирования Active Directory чаще, чем раз в 60 дней. Мы настоятельно рекомендуем делать резервную копию контроллера домена Active Directory каждую ночь.
Используйте программное обеспечение, обеспечивающее согласованность данных
Как и для любой другой базы данных, для базы данных Active Directory необходимо создать резервную копию таким образом, чтобы обеспечить целостность базы данных. Согласованность лучше всего сохранить, если выполнить резервное копирование данных AD DC при выключенном сервере или при использовании службы теневого копирования томов Microsoft (VSS) на работающем компьютере.Резервное копирование сервера Active Directory в выключенном состоянии может быть не очень хорошей идеей, если сервер работает в режиме 24/7. Рекомендации по резервному копированию Active Directory рекомендуют использовать VSS-совместимые приложения резервного копирования для резервного копирования сервера, на котором работает Active Directory. Писатели VSS создают моментальный снимок, который замораживает состояние системы до завершения резервного копирования, чтобы предотвратить изменение активных файлов, используемых Active Directory во время процесса резервного копирования.
Используйте решения для резервного копирования, которые обеспечивают детальное восстановление
Когда дело доходит до восстановления Active Directory, вы можете восстановить весь сервер с Active Directory и всеми его объектами.Выполнение полного восстановления может занять значительное время, особенно если ваша база данных AD имеет значительный размер. Если некоторые объекты Active Directory были случайно удалены, вы можете восстановить только эти объекты и ничего больше. Передовые практики резервного копирования Active Directory рекомендуют использовать методы и приложения резервного копирования, которые могут выполнять детальное восстановление, то есть просто восстанавливать определенные объекты Active Directory из резервной копии. Это позволяет ограничить время, затрачиваемое на восстановление.
Собственные методы резервного копирования Active Directory
Microsoft разработала серию собственных инструментов для резервного копирования серверов Windows, включая серверы с контроллерами домена Active Directory.
Резервное копирование Windows Server
Windows Server Backup — это служебная программа, предоставляемая Microsoft с Windows Server 2008 и более поздними версиями Windows Server, которая заменила служебную программу NTBackup , встроенную в Windows Server 2003.Чтобы получить к нему доступ, вам просто нужно включить резервное копирование Windows Server в меню Добавить роли и компоненты . Windows Server Backup имеет новый графический интерфейс (графический пользовательский интерфейс) и позволяет создавать инкрементные резервные копии с помощью VSS. Резервные копии данных сохраняются в файл VHD — тот же формат файла, что и для Microsoft Hyper-V. Вы можете подключить такие диски VHD к виртуальной машине или к физической машине и получить доступ к данным резервной копии. Обратите внимание, что, в отличие от VHD, созданного MVMC (Microsoft Virtual Machine Converter), образ VHD в этом случае не является загрузочным.Вы можете создать резервную копию всего тома или состояния системы только с помощью команды wbadmin start systemstatebackup . Например:
wbadmin start systemstatebackup —backuptarget: E:
Следует выбрать цель резервного копирования, которая отличается от тома, с которого выполняется резервное копирование данных, и не является удаленной общей папкой.
Когда пришло время восстановления, вам следует загрузить контроллер домена в Режим восстановления служб каталогов (DSRM), нажав F8 , чтобы открыть дополнительные параметры загрузки (как при входе в безопасный режим).Затем вы должны использовать команду wbadmin get versions -backupTarget: path_to_backup machine: name_of_server , чтобы выбрать соответствующую резервную копию и начать восстановление необходимых данных. Вы также можете использовать NTDSutil для управления определенными объектами Active Directory в командной строке во время восстановления.
Преимуществами использования резервного копирования Windows Server для резервного копирования Active Directory являются доступность, возможность VSS и возможность резервного копирования всей системы или только компонентов Active Directory.
К недостаткам
можно отнести необходимость обладать соответствующими навыками и базой знаний для настройки процесса резервного копирования и восстановления.
System Center Data Protection Manager
Microsoft рекомендует использовать System Center Data Protection Manager (SC DPM) для резервного копирования данных, включая Active Directory, в инфраструктуре на базе Windows. SC DPM — это централизованное решение для резервного копирования и восстановления корпоративного уровня, которое является частью System Center Suite и может использоваться для защиты Windows Server, который включает такие службы, как Active Directory.В отличие от встроенного бесплатного Windows Server Backup, SC DPM — это платное программное обеспечение, которое необходимо развертывать отдельно как комплексное решение. Установка может показаться несколько сложной по сравнению с Windows Server Backup. Действительно, должен быть установлен агент резервного копирования, чтобы обеспечить полную защиту вашей машины.
Основные функции System Center Data Protection Manager, связанные с резервным копированием Active Directory:
- Поддержка VSS
- Инкрементное резервное копирование
- Резервное копирование в облако Microsoft Azure
- Нет детального восстановления объектов для Active Directory
Использование SC DPM наиболее практично, когда вам нужно защитить большое количество компьютеров Windows, включая серверы MS Exchange и MS SWL.
Резервное копирование виртуального контроллера домена
Перечисленные собственные методы резервного копирования Active Directory могут использоваться для резервного копирования серверов Active Directory, развернутых как на физических серверах, так и на виртуальных машинах. Запуск контроллеров домена на виртуальных машинах предлагает ряд преимуществ специально для виртуальных машин, таких как резервное копирование на уровне хоста, возможность восстановления в виде виртуальных машин, работающих на разных физических серверах, и т. Д. Передовой опыт резервного копирования Active Directory рекомендует использовать решения резервного копирования на уровне хоста, когда создание резервных копий контроллеров домена Active Directory, работающих на виртуальных машинах, на уровне гипервизора.
Использование NAKIVO Backup & Replication для резервного копирования Active Directory
NAKIVO Backup & Replication — это решение для резервного копирования на уровне хоста, которое может оптимальным образом выполнять резервное копирование виртуальных машин VMware и виртуальных машин Hyper-V с контроллером домена Active Directory. Этот продукт позволяет выполнять резервное копирование целых виртуальных машин контроллера домена, даже если виртуальная машина находится в рабочем состоянии, с учетом осведомленности о приложении (используется VSS), а также обеспечивает мгновенное восстановление объектов AD. Никаких агентов не требуется. NAKIVO Backup & Replication поддерживает детальное восстановление Active Directory, в результате чего вы можете восстанавливать определенные объекты и контейнеры AD, не тратя время, необходимое для полного восстановления виртуальной машины.Конечно, также поддерживается полное восстановление виртуальной машины контроллера домена.
Установка продукта быстрая и простая. Поддерживаются резервное копирование в облако, инкрементное резервное копирование и несколько точек восстановления. Вы можете получить доступ к объектам Active Directory непосредственно из сжатых и дедуплицированных резервных копий виртуальных машин в удобном веб-интерфейсе NAKIVO Backup & Replication и выполнить следующие действия:
- Поиск объектов и контейнеров AD
- Просмотрите базу данных AD
- Просмотр атрибутов объектов AD
- Выберите определенные элементы AD для восстановления
- Загрузите объекты AD в формате.Формат LDF для дальнейшего импорта на восстановленный сервер
NAKIVO Backup & Replication поддерживает следующие случаи:
- Полное восстановление базы данных Active Directory или нескольких баз данных AD в рабочий экземпляр Active Directory
- Восстановление одного или нескольких объектов в рабочий экземпляр Active Directory
- Полный экспорт базы данных в файлы .DIT в определенные папки
Вы можете запланировать выполнение задания резервного копирования виртуальной машины AD DC каждую ночь в соответствии с передовыми методами резервного копирования Active Directory.Восстановление Active Directory — не сложный процесс, по крайней мере, если вы используете NAKIVO Backup & Replication.
Заключение
Active Directory классифицируется как одно из наиболее важных бизнес-приложений, нарушение работы которого может вызвать простои пользователей и служб. В сегодняшнем сообщении блога описаны передовые методы резервного копирования Active Directory, которые помогут защитить вашу инфраструктуру от сбоев AD. Выбор правильного решения для резервного копирования — важный вывод в этом случае.
Рекомендации по резервному копированию Active Directory
5 (100%) 5 голосов
.
Acronis Backup and Recovery: резервное копирование и восстановление контроллера домена
Последнее обновление: Ср, 2020-08-12 12:28
Создание снимков с помощью теневого копирования тома
Эта статья относится к:
- Acronis Backup 11.5
- Acronis Backup and Recovery 11
- Acronis Backup and Recovery 10
Введение
Безопасный способ резервного копирования сервера Active Directory — создать резервную копию системы с помощью Acronis Backup and Recovery 10 с опцией Создание моментальных снимков с помощью VSS .
Процедура восстановления может отличаться в зависимости от доступности других контроллеров домена.
Подробные инструкции по резервному копированию и восстановлению Active Directory см. В техническом документе Acronis: Резервное копирование и восстановление Active Directory с помощью Acronis Backup and Recovery 11
Решение
Резервное копирование
Чтобы сделать базу данных активного каталога согласованной в резервной копии, активируйте поддержку VSS:
- Выберите Параметры резервного копирования на странице создания плана резервного копирования, чтобы выбрать этот параметр для конкретной задачи резервного копирования, или перейдите в Параметры -> Параметры резервного копирования и восстановления по умолчанию , чтобы установить параметры по умолчанию;
- в Acronis Backup 11.5 предустановлен поставщик Microsoft VSS. В нормальных условиях вносить здесь какие-либо изменения не нужно. Чтобы проверить, используется ли предустановка, следуйте инструкциям для Acronis Backup and Recovery 11 в таблице ниже.
(!) В некоторых случаях база данных Active Directory и журналы транзакций могут храниться на разных томах, поэтому убедитесь, что оба тома включены в резервную копию.
Если в вашем домене только один контроллер домена, рекомендуется создавать резервную копию хотя бы раз в день, чтобы избежать значительной потери информации в случае сбоя.
Восстановление
Существует два возможных сценария восстановления контроллера домена:
- Восстановление одного контроллера домена (другие контроллеры домена недоступны):
- Убедитесь, что для восстановления используется последняя резервная копия;
- Восстановите контроллер домена из резервной копии с помощью загрузочного носителя Acronis;
- Перезагрузите компьютер. Убедитесь, что служба Active Directory успешно запущена.
- Восстановление контроллера домена, если доступны другие контроллеры домена:
- Восстановите контроллер домена из резервной копии с помощью загрузочного носителя Acronis;
- Перезагрузите компьютер.Убедитесь, что служба Active Directory успешно запущена. Репликация записей Active Directory будет выполняться автоматически.
Дополнительная информация
См. Также:
Теги:
.