1. Відновлення контролера домену в режимі «non-authoritative»
2. Відновлення контролера домену в режимі «authoritative»
3. Також вас можуть зацікавити:

Всі публікації серії:

Це друга стаття в серії, присвяченій захисту Active Directory (AD) за допомогою Veeam. В попередній статті розповідалося про процедуру бекапе фізичних і віртуальних контролерів домену (DC). Сьогодні поговоримо про їх поновлення.

Досконале знання своєї інфраструктури дуже допомагає при плануванні відновлення AD. Скільки контролерів домену в вашому середовищі - один або кілька? Це контролери домену, доступні для читання і запису (RWDC) або тільки для читання (RODC)? Вийшов з ладу тільки один контролер, або пошкоджена вся інфраструктура AD? Якщо у вас кілька контролерів, чи використовуєте ви для синхронізації змін між різними контролерами домену службу реплікації файлів (FRS) або перейшли на розподілену DFSR для синхронізації змін між різними контролерами домену? Ось лише частина питань, відповіді на які вам необхідно знати, щоб успішно відновлювати дані.

Примітка: FRS - служба ОС Windows Server 2000 і Windows Server 2003, призначена для розподілу загальних файлів і об'єктів групових політик (GPO). У більш пізніх версіях ОС Windows Server вона була замінена службою реплікації DFSR.Начіная з Windows Server 2008, реплікація DFSR стала варіантом налаштуванням за замовчуванням для реплікації каталогу SYSVOL. Якщо на першому контролері домену функціональний режим роботи був встановлений на Windows Server 2008 або вище, ви використовуєте реплікацію DFSR. Щоб зрозуміти, чи використовується в вашому домені служба FRSR або реплікація DFSR, прочитайте цю статтю . А тут розповідається про переваги реплікації DFS перед FRS .

Відновлення контролера домену в режимі «non-authoritative»

Збираючись відновлювати контролер домену, необхідно спочатку визначити, чи буде достатній режим «non-authoritative» або буде потрібно скористатися режимом «authoritative». Різниця між цими двома режимами полягає в тому, що при режимі відновлення «non-authoritative» контролер домену розуміє, що він був протягом деякого часу відключений. Тому він дозволяє іншим контролерам домену оновити його базу даних, внісши в неї останні зміни, що відбулися під час його відсутності. При «authoritative» відновленні контролер вважає, що тільки на ньому є істинно вірна база даних, тому саме він отримує повноваження на оновлення баз даних інших контролерів домену на основі своїх даних.

У більшості сценаріїв відновлення вам буде потрібно режим «non-authoritative», оскільки в середовищі є декілька контролерів домену. Крім того, «authoritative» відновлення контролера домену може призвести до нових проблем. Саме на цьому заснована логіка Veeam Backup & Replication: за замовчуванням виконується «non-authoritative» відновлення DC, оскільки вважається, що інфраструктура побудована з надмірністю і включає в себе кілька контролерів домену. Щоб виконати «authoritative» відновлення за допомогою Veeam, необхідно здійснити деякі додаткові дії, які описані нижче.

ПРИМІТКА. Ще один поширений варіант дій при відмові контролера домену - розподілити його ролі між іншими контролерами і очистити метадані, якщо відновлення малоймовірне. В цьому випадку ви доручаєте іншим DC виконувати функції відмовив, і вам не потрібно його відновлювати.

Давайте повернемося до файлів резервних копій, які були описані в попередній статті. Відновити контролер домену з резервної копії Veeam Backup & Replication дуже легко. Для цього потрібно:

• Вибрати майстер відновлення в інтерфейсі
• Знайти потрібний контролер домену
• Вибрати в меню відновлення варіант відновлення ВМ цілком (Restore Entire VM)
• Потім вказати точку відновлення
• Вибрати вихідне або нове місце відновлення
• завершити процедуру

Саме чудове тут, що завдяки обробці даних з урахуванням стану додатків при створенні резервної копії, вам більше нічого не потрібно робити. Veeam розпізнає контролер домену в зазначеній ВМ і акуратно відновить його, використовуючи особливий алгоритм:

• Відновлення файлів і жорстких дисків ВМ
• Завантаження ОС в спеціальному режимі відновлення доменних сервісів (DSRM mode)
• застосування налаштувань
• Перезапуск в звичайному режимі

Контролер домену буде знати про відновлення з резервної копії і зробить відповідні дії: існуюча база даних буде оголошена недійсною, і партнери реплікації зможуть оновити її, внісши найбільш свіжу інформацію.

Мал. 1. Veeam Backup & Replication: відновлення ВМ цілком

Тут можна прочитати про відновленні «на голе залізо» резервної копії за допомогою Veeam Endpoint Backup . Вам буде потрібно заздалегідь підготовлений аварійний завантажувальний диск Veeam і доступ до самої резервної копії (на USB-носії або мережевому диску). Пам'ятайте, що в даному випадку особлива логіка Veeam Backup & Replication використовуватися не буде. Після відновлення за допомогою Veeam Endpoint Backup ваш контролер домену завантажиться в режимі відновлення. Вам потрібно буде вирішити, чи хочете ви міняти ключі реєстру або відразу перезапустите ВМ в звичайному режимі. Можливо, ця стаття бази знань буде корисна.

Мал. 2. Veeam Endpoint Backup: відновлення «на голе залізо»

Відновлення контролера домену в режимі «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.

Мал. 3. Відновлення SYSVOL в режимі «authoritative» (служба DFSR)

Процедура «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.

У цій статті я розглянув відновлення окремого контролера домену. Однак найчастіше при роботі з AD вам потрібно відновити випадково видалений об'єкт, і в цьому випадку відновлювати контролер цілком - не найкращий варіант. У наступній статті я розповім про відновлення окремих об'єктів каталогу AD за допомогою власних інструментів Microsoft і утиліти Veeam Explorer для Active Directory.

Також вас можуть зацікавити:

GD Star Rating
a WordPress rating system