[Перевод] Восстановление контроллера домена из резервной копии с помощью Veeam26.10.2016 15:48

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

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

0f419a86f8454e70a43c3a12b911aff2.png

Доскональное знание своей инфраструктуры очень помогает при планировании восстановления 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, нужно:
  1. Запустить мастер восстановления в консоли Veeam Backup.
  2. Найти нужный контроллер домена.
  3. Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM).
  4. Указать точку восстановления.
  5. Выбрать исходное или новое место восстановления.
  6. Завершить процедуру.

Самое примечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя вот такую последовательность действий:
  1. Восстановление файлов и дисков ВМ.
  2. Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode).
  3. Применение настроек.
  4. Перезапуск в обычном режиме.

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

Восстановление в режиме «authoritative»


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

Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации, разумеется, предпочтительно, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.

Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.

Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:

  1. Выберите в Veeam операцию восстановления ВМ полностью: программа автоматически выполнит стандартное восстановление DC в режиме «non-authoritative» (см. выше).
  2. При втором перезапуске DC откройте мастер загрузки (нажмите F8), выберите пункт DSRM и войдите в систему с данными учетной записи DSRM (та учетная запись, которую вы указали, когда назначали данный компьютер контроллером домена).
  3. Откройте командную строку и запустите утилиту ntdsutil
  4. Используйте следующие команды:
    • activate instance ntds;
    • затем authoritative restore;
    • затем restore object "distinguishedName” или restore subtree "distinguishedName”

      Пример: restore subtree "OU=Branch,DC=dc,DC=lab, DC=local


  5. Подтвердите authoritative восстановление и перезапустите сервер после завершения операции.

Процедура authoritative восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:
  1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
  2. При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\DFSR, создайте ключ Restore, а затем создайте строку SYSVOL со значением authoritative.
    Это значение будет считано службой DFSR. Если значение не установлено, по умолчанию производится восстановление SYSVOL в режиме non-authoritative.
  3. Перейдите к HKLM\System\CurrentControlSet\Control\BackupRestore, создайте ключ SystemStateRestore, затем создайте строку LastRestoreId с любым значением GUID, например, 10000000–0000–0000–0000–000000000000.
  4. Перезапустите службу DFSR.

30ee83d360094890868973707e9b46ec.png

Процедура authoritative восстановления SYSVOL (при использовании службы FRS):

  1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
  2. При второй загрузке перейдите в ветку реестра HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup и измените значение ключа Burflag на 000000D4 (hex) или 212 (dec).

    Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS можно почитать здесь.

  3. Перезапустите службу NTFRS.

Восстановление физического контроллера домена с Veeam Endpoint Backup
Теперь немного о восстановлении физической машины из резервной копии с помощью Veeam Endpoint Backup.

Вам потребуется:

  1. Заранее подготовленный аварийный загрузочный диск Veeam.
  2. Доступ к самой резервной копии (на USB-носителе или сетевом диске).

Важно! Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет.

После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний Veeam будет полезна.

0f419a86f8454e70a43c3a12b911aff2.png

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup более подробно.

Итак, мы рассмотрели восстановление отдельного контроллера домена. Однако чаще всего при работе с AD требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не самый эффективный вариант. Поэтому в следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.

Полезные ссылки:
  • Статья на Хабре о резервном копировании контроллера домена с помощью Veeam: https://habrahabr.ru/company/veeam/blog/309904/
  • Статья на Хабре о работе с Veeam Endpoint Backup FREE: https://habrahabr.ru/company/veeam/blog/266043/
  • Статья базы знаний Microsoft о восстановлении FRS: https://support.microsoft.com/ru-ru/kb/290762

Комментарии (2)

  • 26 октября 2016 в 14:03

    0

    ↑

    ↓

    Пару вопросов. А разве в случае authoritative не нужно зделать non-authoritative восстановление на ВСЕХ оставшихся DC? Что делаете с lingering objects?

  • 26 октября 2016 в 15:09

    0

    ↑

    ↓

    А разве в случае authoritative не нужно зделать non-authoritative восстановление на ВСЕХ оставшихся DC?

    В зависимости от потребностей. Можно и просто пересоздать их. Но вообще вопрос не в том, нужно ли делать восстановление всех DC, а «у нас всё сломалось, нужно чтобы быстро хоть как-то заработало».
    Что делаете с lingering objects?

    Veeam ничего из коробки не делает, это оставлено на откуп админу. Можно repadmin или ликвидатор объектов использовать. Хотя как я понимаю, это всё же проблема старых систем и с Windows Server 2012 не должно беспокоить.

© Habrahabr.ru