Продолжаем публикацию серии статей, написанных коллегой для корпоративного блога и посвященных резервному копированию и восстановлению контроллеров домена и собственно Active Directory.
В предыдущей статье из этой серии рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.
Сразу скажу, что этот пост не является руководством по восстановлению Active Directory. Его задача — рассказать о том, что необходимо учитывать при восстановлении AD или конкретного контроллера домена из резервной копии, а также показать, как можно выполнить эти действия с помощью решений Veeam.
Доскональное знание своей инфраструктуры очень помогает при планировании восстановления AD. Вот лишь часть вопросов, ответы на которые вам необходимо знать, чтобы успешно восстанавливать данные:
Примечание: Начиная с Windows Server 2008, репликация DFSR стала вариантом настройки по умолчанию для репликации каталога SYSVOL.
Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим non-authoritative или потребуется воспользоваться режимом authoritative.
Разница между этими двумя режимами заключается в том, что при режиме восстановлении non-authoritative контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. А при authoritative восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.
В большинстве сценариев восстановления вам потребуется режим non-authoritative, поскольку в среде имеется несколько контроллеров домена. (Кроме того, authoritative восстановление может привести к новым проблемам.)
Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется non-authoritative восстановление, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров.
Чтобы выполнить authoritative восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые будут описаны позже.
Полезно: Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.
Итак, вернемся к файлам резервных копий, создание которых было описано в предыдущей статье. Для того, чтобы восстановить контроллер домена из резервной копии Veeam Backup & Replication, нужно:
Самое примечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя вот такую последовательность действий:
Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.
С большой долей вероятности вам не потребуется этот режим восстановления. Однако давайте познакомимся с ним поближе, чтобы вы поняли, почему это так.
Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации, разумеется, предпочтительно, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.
Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.
Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:
Процедура authoritative восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:
Процедура authoritative восстановления SYSVOL (при использовании службы FRS):
Теперь немного о восстановлении физической машины из резервной копии с помощью Veeam Endpoint Backup.
Вам потребуется:
Важно! Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет.
После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний Veeam будет полезна.
Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup более подробно.
Итак, мы рассмотрели восстановление отдельного контроллера домена. Однако чаще всего при работе с AD требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не самый эффективный вариант. Поэтому в следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.
В предыдущей статье из этой серии рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.
Сразу скажу, что этот пост не является руководством по восстановлению Active Directory. Его задача — рассказать о том, что необходимо учитывать при восстановлении AD или конкретного контроллера домена из резервной копии, а также показать, как можно выполнить эти действия с помощью решений Veeam.
Доскональное знание своей инфраструктуры очень помогает при планировании восстановления AD. Вот лишь часть вопросов, ответы на которые вам необходимо знать, чтобы успешно восстанавливать данные:
- Сколько контроллеров домена в вашей среде — один или несколько?
- Это контроллеры домена, доступные для чтения и записи (RWDC) или только для чтения (RODC)?
- Вышел из строя только один контроллер, или повреждена вся инфраструктура AD?
- Если у вас несколько контроллеров, используете ли вы для синхронизации изменений между разными контроллерами домена службу репликации файлов (FRS) или перешли на распределенную DFSR для синхронизации изменений между разными контроллерами домена?
Примечание: Начиная с Windows Server 2008, репликация DFSR стала вариантом настройки по умолчанию для репликации каталога SYSVOL.
Восстановление виртуализованного контроллера домена
Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим non-authoritative или потребуется воспользоваться режимом authoritative.
Разница между этими двумя режимами заключается в том, что при режиме восстановлении non-authoritative контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. А при authoritative восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.
В большинстве сценариев восстановления вам потребуется режим non-authoritative, поскольку в среде имеется несколько контроллеров домена. (Кроме того, authoritative восстановление может привести к новым проблемам.)
Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется non-authoritative восстановление, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров.
Чтобы выполнить authoritative восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые будут описаны позже.
Полезно: Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.
Восстановление в режиме «non-authoritative»
Итак, вернемся к файлам резервных копий, создание которых было описано в предыдущей статье. Для того, чтобы восстановить контроллер домена из резервной копии Veeam Backup & Replication, нужно:
- Запустить мастер восстановления в консоли Veeam Backup.
- Найти нужный контроллер домена.
- Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM).
- Указать точку восстановления.
- Выбрать исходное или новое место восстановления.
- Завершить процедуру.
Самое примечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя вот такую последовательность действий:
- Восстановление файлов и дисков ВМ.
- Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode).
- Применение настроек.
- Перезапуск в обычном режиме.
Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.
Восстановление в режиме «authoritative»
С большой долей вероятности вам не потребуется этот режим восстановления. Однако давайте познакомимся с ним поближе, чтобы вы поняли, почему это так.
Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации, разумеется, предпочтительно, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.
Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.
Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:
- Выберите в Veeam операцию восстановления ВМ полностью: программа автоматически выполнит стандартное восстановление DC в режиме «non-authoritative» (см. выше).
- При втором перезапуске DC откройте мастер загрузки (нажмите F8), выберите пункт DSRM и войдите в систему с данными учетной записи DSRM (та учетная запись, которую вы указали, когда назначали данный компьютер контроллером домена).
- Откройте командную строку и запустите утилиту ntdsutil
- Используйте следующие команды:
activate instance ntds;- затем
authoritative restore; - затем
restore object “distinguishedName”илиrestore subtree “distinguishedName”
Пример:restore subtree “OU=Branch,DC=dc,DC=lab, DC=local
- Подтвердите authoritative восстановление и перезапустите сервер после завершения операции.
Процедура authoritative восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:
- Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
- При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\DFSR, создайте ключ Restore, а затем создайте строку SYSVOL со значением authoritative.
Это значение будет считано службой DFSR. Если значение не установлено, по умолчанию производится восстановление SYSVOL в режиме non-authoritative. - Перейдите к HKLM\System\CurrentControlSet\Control\BackupRestore, создайте ключ SystemStateRestore, затем создайте строку LastRestoreId с любым значением GUID, например, 10000000-0000-0000-0000-000000000000.
- Перезапустите службу DFSR.
Процедура authoritative восстановления SYSVOL (при использовании службы FRS):
- Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
- При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup и измените значение ключа Burflag на 000000D4 (hex) или 212 (dec).
Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS можно почитать здесь.
- Перезапустите службу NTFRS.
Восстановление физического контроллера домена с Veeam Endpoint Backup
Теперь немного о восстановлении физической машины из резервной копии с помощью Veeam Endpoint Backup.
Вам потребуется:
- Заранее подготовленный аварийный загрузочный диск Veeam.
- Доступ к самой резервной копии (на USB-носителе или сетевом диске).
Важно! Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет.
После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний Veeam будет полезна.
Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup более подробно.
Итак, мы рассмотрели восстановление отдельного контроллера домена. Однако чаще всего при работе с AD требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не самый эффективный вариант. Поэтому в следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.
Полезные ссылки:
Поделиться с друзьями
Комментарии (2)
anoronn
26.10.2016 15:09А разве в случае authoritative не нужно зделать non-authoritative восстановление на ВСЕХ оставшихся DC?
В зависимости от потребностей. Можно и просто пересоздать их. Но вообще вопрос не в том, нужно ли делать восстановление всех DC, а «у нас всё сломалось, нужно чтобы быстро хоть как-то заработало».
Что делаете с lingering objects?
Veeam ничего из коробки не делает, это оставлено на откуп админу. Можно repadmin или ликвидатор объектов использовать. Хотя как я понимаю, это всё же проблема старых систем и с Windows Server 2012 не должно беспокоить.
NevRA
Пару вопросов. А разве в случае authoritative не нужно зделать non-authoritative восстановление на ВСЕХ оставшихся DC? Что делаете с lingering objects?