что такое резервный домен

Резервное копирование контроллеров домена с помощью Veeam

Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.

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

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

Если у вас виртуальный DC

Так как сервисы Active Directory потребляют малую часть ресурсов системы, то контроллеры домена обычно становятся первыми кандидатами для виртуализации. Чтобы защитить виртуализованный контроллер с помощью Veeam, нужно установить и настроить Veeam Backup & Replication.

Важно! Решение работает с ВМ контроллера домена на Windows Server 2003 SP1 и выше, минимальный поддерживаемый функциональный уровень леса — Windows 2003. Учетной записи нужно предоставить права администратора Active Directory –— можно работать под учетной записью администратора предприятия или домена.
Процесс установки и настройки Veeam Backup & Replication уже неоднократно освещался – например, в видео, подготовленном системным инженером Veeam, поэтому обойдемся без подробностей. Предположим, что все настроено и готово к работе. Теперь нужно создать задание бэкапа контроллера домена. Процесс настройки довольно прост:

AAIP — технология Veeam, которая обеспечивает бэкап ВМ с учетом состояния приложений. Она выполняет поиск приложений гостевой ОС, сбор их метаданных, «заморозку» с помощью соответствующих механизмов (Microsoft VSS Writers), подготовку процедуры восстановления с использованием VSS для приложений, которая будет выполнена при первом запуске восстановленной ВМ, а также усечение журналов транзакций в случае успешного завершения бэкапа. Если функция AAIP не будет включена, гостевая ОС контроллера домена не поймет, что был выполнен ее бэкап и обеспечена защита. Поэтому через некоторое время вы можете обнаружить внутреннее предупреждение в журналах сервера Event ID 2089: backup latency interval (т.е. бэкап не выполнялся в течение интервала задержки архивации).

Если у вас физический DC

Честно говоря, я надеюсь, что вы идете в ногу со временем, и в вашей компании контроллеры домена давно виртуализованы. Если это не так, то надеюсь, что вы их регулярно обновляете и они работают на относительно современных версиях ОС Windows Server —Windows Server 2008 (R2) и выше. (О нюансах работы с более старыми системами будет отдельная статья).

Итак, у вас есть один или несколько физических контроллеров домена, работающих под Windows Server 2008 R2 и выше, и вы хотите их защитить. В этом случае вам потребуется Veeam Endpoint Backup — решение, предназначенное специально для защиты данных физических компьютеров и серверов. Veeam Endpoint Backup копирует нужные данные с физической машины и сохраняет их в файл резервной копии. В случае аварии вы сможете восстановить данные «на голое железо» или выполнить восстановление на уровне логического диска. Кроме того, вы сможете восстанавливать отдельные объекты с помощью Veeam Explorer для Microsoft Active Directory.

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

Примечание: Если в вашей среде уже установлен 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.

Источник

Резервация доменов

После окончания срока регистрации домена администратор может продлить его в течение периода преимущественного продления — 30 дней. При включенной опции резервации домена у администратора будет еще 30 дополнительных дней на восстановление домена.

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

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

Если администратор не продлевает домен в течение 30 дней преимущественного продления, то:

При подключенной опции резервации в случае, если продление домена не было оплачено в течение 30 дней после даты окончания срока регистрации (период преимущественного продления), у администратора есть 30 дополнительных дней для восстановления домена — период восстановления.

Если доменное имя не было восстановлено и в этот период, то право администрирования доменом утрачивается.

Подключить резервацию может только администратор домена.

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

Подключить резервацию можно на странице домена в разделе «Для клиентов».

Поскольку при отключении резервации администратор домена лишается возможности его восстановления, необходимо предоставить заявление в офис RU-CENTER.

Подключение резервации для домена бесплатно, как и ее отключение.

Чтобы восстановить домен:

1. Перейдите в раздел «Для клиентов — Услуги — Мои домены».

3. Нажмите «Восстановить».

4. Оплатите заказ на восстановление домена.

5. Как только домен будет восстановлен, вы получите уведомление на контактный email.

Стоимость восстановления указана в Приложении 2.

Источник

Что такое резервный домен

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

Единая база данных, хранящая справочную информацию, предоставляет все то же многообразие возможностей и порождает все то же множество проблем, что и любая другая крупная база данных. Она позволяет осуществлять различные операции поиска, сортировки, модификации и т.п., что очень сильно облегчает жизнь как администраторам, так и пользователям. Набор разрозненных баз данных не предоставляет такого прозрачного доступа к ресурсам сети, как это имеет место в случае использования ОС NetWare 3.x с ее базой bindery, локальной для каждого сервера. В последнем случае пользователь должен заранее знать, на каком сервере находится нужный ему ресурс и производить логическое подключение к этому серверу для получения доступа к этому ресурсу. Для того, чтобы получить доступ к ресурсам какого-нибудь сервера, пользователь должен иметь там свою учетную информацию, которая дублируется таким образом на всех серверах сети. В единой базе данных о каждом пользователе существует только одна запись.

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

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

Проблемы сохранения производительности и надежности при увеличении масштаба сети решаются за счет использования распределенных баз данных справочной информации. Разделение данных между несколькими серверами снижает нагрузку на каждый сервер, а надежность при этом достигается за счет наличия нескольких копий (называемых часто репликами) каждой части базы данных. Для каждой части базы данных можно назначить своего администратора, который обладает правами доступа только к объектам своей порции информации о всей системе. Для пользователя же (и для сетевых приложений) такая распределенная база данных представляется единой базой данных, которая обеспечивает доступ ко всем ресурсам сети вне зависимости от того, с какой рабочей станции осуществил свой вход в сеть пользователь.

Доменный подход

Доверительные отношения (trust relationships) обеспечивают транзитную аутентификацию, при которой пользователь имеет только одну учетную запись в одном домене, но может получить доступ к ресурсам всех доменов сети.

Рис. 3.20. Доверительные отношения между доменами

Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.

Основной и резервные контроллеры домена

В домене должен находится сервер, выполняющий роль основного контроллера домена (primary domain controller). Этот контроллер хранит первичную копию базы данных учетной информации пользователей домена. Все изменения, производимые в учетной информации, сначала производятся именно в этой копии. Основной контроллер домена всегда существует в единственном экземпляре. Пользователь, который администрирует домен, не должен явно задавать имя компьютера, который выполняет роль основного контроллера, утилита, в помощью которой осуществляется администрирование (в Windows NT это User Manager for Domains), должна по имени домена самостоятельно, в соответствии с заранее разработанным протоколом провести диалог с основным контроллером домена и сделать нужные изменения в его базе данных.

Кроме основного контроллера в домене могут существовать несколько резервных контроллеров (backup domain controllers). Эти контроллеры хранят реплики базы учетных данных. Все резервные контроллеры в дополнение к основному могут обрабатывать запросы пользователей на логический вход в домен.

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

Четыре модели организации связи доменов

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

Модель с одним доменом

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

Таблица 3.1.
Преимущества и недостатки модели с одним доменом

Модель с главным доменом

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

Рис. 3.21. Модель с главным доменом

Таблица 3.2.
Преимущества и недостатки модели с главным доменом

Модель с несколькими главными доменами

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

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

Рис. 3.22. Модель с несколькими главными доменами

Каждый главный домен доверяет всем остальным главным доменам. Каждый домен отдела доверяет всем главным доменам, но доменам отделов нет необходимости доверять друг другу.

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

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

Таблица 3.3.
Преимущества и недостатки модели с несколькими главными доменами

Модель с полными доверительными отношениями

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

Рис. 3.23. Модель с полными доверительными отношениями

Из-за резкого увеличения числа доверительных отношений эта модель не подходит для больших предприятий. Для n доменов нужно установить n(n-1) доверительных отношений.

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

Таблица 3.4.
Преимущества и недостатки модели с полными доверительными отношениями

Служба каталогов

База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.

Распределенность заключается в том, что информация не хранится на одном сервере, а разделена на части, называемые разделами (partitions). NetWare хранит эти разделы на нескольких серверах сети (рисунок 3.24). Это свойство значительно упрощает администрирование и управление большой сетью, так как она представляется администратору единой системой. Кроме этого, обеспечивается более быстрый доступ к базе данных сетевых ресурсов за счет обращения к ближайшему серверу.

Рис. 3.24. Разделы базы данных NDS

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

Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть. После чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для процесса идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право использовать данный ресурс.

В NDS информация о сетевых ресурсах организована с помощью объектов. Каждый объект представляет собой ресурс, такой как принтер, том, пользователь или сервер.

Объекты организованы в иерархическую структуру, соответствующую структуре организации, отражающую реальные информационные потоки и потребности разделения ресурсов. Одни объекты представляют физические сущности, например объект-пользователь представляет пользователя, а объект-принтер представляет принтер. Другие объекты представляют логические понятия, такие как группы или очереди к принтерам.

Еще одна категория объектов, в которую входят, например, объекты типа отдела предприятия, помогают организовывать и упорядочивать другие объекты.

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

NDS использует для хранения информации логическую структуру, называемую деревом каталогов (Directory Tree, DT). Эта иерархическая структура имеет корневой элемент (root) и ветви (рисунок 3.25). Администратору сети NetWare 4.x предоставляется удобная графическая утилита NetWare Administrator, работающая в среде Windows, наглядно представляющая каждый объект дерева каталогов NDS в виде иконки и отражающая связи между объектами. Пользователи также получают удобства прозрачного доступа к ресурсам всей сети, если они пользуются оболочкой NetWare для Windows, которая поддерживает диалог с NDS и представляет доступные пользователю ресурсы в виде вложенных пиктограмм.

Объекты-контейнеры содержат или включают другие объекты. Они используются для логического упорядочивания и организации других объектов дерева.

Рис. 3.25. Типичная структура дерева каталогов NDS

Служба NDS и файловая система

Служба NDS предназначена для управления такими сетевыми ресурсами, как серверы и тома NetWare, но она не обеспечивает управление файловой системой. Файлы и каталоги не являются объектами службы NDS. Однако они представляются в виде иконок при использовании графической утилиты NetWare Administrator. Одним из атрибутов объекта-тома является месторасположение физического тома, который содержит файлы и каталоги. Таким образом, объект-том представляет собой связь между NDS и файловой системой.

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

NDS также использует синхронизацию часов между всеми серверами сети для обеспечения правильного порядка событий в сети.

представляет собой различимое имя объекта-пользователя с сетевым именем Vova S, работающего в сетевом отделе фирмы Microsoft, расположенной в США. Возможен и другой вариант записи различимого имени с указанием типов объектов:

Такой вид записи более содержателен.

Средства защиты объектов в NDS

Служба NDS определяет права доступа одних сетевых объектов к другим. Различаются права доступа к объекту в целом и права доступа к его атрибутам.

С каждым объектом связан список управления доступом (ACL), в котором определяются права доступа к данному объекту со стороны других объектов.

Права доступа наследуются в дереве объектов сверху вниз, поэтому права объекта-контейнера наследуются входящими в него объектами. Для достижении необходимой гибкости в наделении объекта правами используется маска наследования (Inheritance Mask), с помощью которой можно заблокировать некоторые наследуемые права. С помощью наследования прав доступа главный администратор дерева, имеющий доступ ко всем его объектам, может назначить администратора поддерева, который получит права доступа ко всем объектам данного поддерева. Если поддерево соответствует какой-либо структурной единице предприятия (что и подразумевается), например отделу, то это будет администратор отдела, управляющий пользователями и ресурсами данного отдела.

После подробного рассмотрения свойств дерева каталогов NDS можно уточнить понятия раздела (partition) и реплики (replica). Раздел представляет собой поддерево общего дерева сети. Для определения раздела необходимо выбрать объект-контейнер в общем дереве, который будет корневым объектом данного раздела. Создание раздела уменьшает объем хранимой на сервере информации базы данных NDS за счет исключения редко используемой информации и делает доступ к локальным объектам более быстрым, хотя объекты, находящиеся в других разделах, также доступны всем клиентам сети.

Существуют три типа реплик: главная реплика (master replica), вторичная реплика (read/write replica) и реплика только для чтения (read-only replica).

Главная реплика позволяет проводить над ней такие операции, как создание нового раздела, слияние разделов и удаление раздела.

Вторичная реплика разрешает обновлять информацию об объектах, добавлять новые объекты, но не разрешает создавать новые разделы.

Реплика только для чтения позволяет только читать информацию из ее базы и проводить операции поиска.

В сети может существовать произвольное количество реплик. При изменения информации в какой-либо реплике автоматически запускается процесс обновления всех остальных реплик. Этот процесс называется процессом синхронизации службы каталогов (DSS).

Любой сервер NetWare, поддерживающий службу NDS, называется сервером имен.

Источник