Бэкап Active Directory и системного состояния серверов

Почему бэкап Active Directory — это не просто «бэкап ещё одного сервера»

Контроллер домена — это не файловый сервер и не веб-приложение. Внутри него живёт база данных NTDS.dit с учётными записями, паролями (точнее, их хэшами), группами, GPO и доверительными отношениями всего домена. Если это всё потерять или, что чаще случается на практике, получить зашифрованным вымогателем, — восстанавливать придётся не один сервис, а буквально всю аутентификацию компании: без домена не зайдут ни в почту, ни в 1С, ни в файловые шары, ни в CRM.

Особенность бэкапа контроллера домена в том, что тут нельзя просто скопировать файлы NTDS.dit «на живую» — база активно используется службой каталогов, и файл всегда будет в противоречивом состоянии при прямом копировании. Windows решает эту проблему через встроенный механизм системного состояния (system state), который умеет консистентно снимать NTDS.dit, реестр, загрузочные файлы и метаданные AD, используя ту же технологию теневого копирования тома (VSS), что мы уже разбирали для MS SQL.

В домене itpages.lab.local (192.168.10.0/24) контроллер домена — srv-dc01, бэкапы стекаются на srv-backup01, а окончательно оседают в неизменяемом виде на srv-repo01. Разберём, как это настроить и, что важнее, как потом реально восстановить домен, а не просто «иметь файл на всякий случай».

Отдельная сложность в том, что AD — распределённая система: изменения на srv-dc01 реплицируются на другие контроллеры домена, если они есть, и это влияет на то, как вообще нужно думать про «точку восстановления». Восстановить один контроллер домена из бэкапа недельной давности в живом лесу с несколькими DC — рутинная операция. А вот восстановить единственный DC компании — уже совсем другая история, с другими рисками, о которых ниже.

Бэкап системного состояния через wbadmin

Встроенный в Windows Server инструмент wbadmin умеет снимать системное состояние отдельно от полного бэкапа диска — это быстрее и компактнее, если тебе нужен именно AD, а не весь сервер целиком. Перед первым запуском нужно указать целевой диск для хранения бэкапов через wbadmin:

wbadmin get status

wbadmin start systemstatebackup ^
  -backupTarget:\\srv-backup01\wbadmin\srv-dc01 ^
  -quiet

Команда создаёт консистентный снимок через VSS, включающий NTDS.dit, реестр, загрузочные файлы, реестр классов COM+ и (если роль установлена) сертификационные службы. Обрати внимание: wbadmin с сетевым путём как -backupTarget не сохраняет историю версий бэкапов на udp-ресурсе так же, как на локальном диске — каждый следующий запуск затирает предыдущий набор файлов на общем ресурсе, если явно не организовать ротацию папок по дате на стороне srv-backup01.

wbadmin start systemstatebackup ^
  -backupTarget:\\srv-backup01\wbadmin\srv-dc01_%date:~-4,4%%date:~-10,2%%date:~-7,2% ^
  -quiet

Ntdsutil: проверка и обслуживание базы AD

ntdsutil — это не инструмент бэкапа как такового, а утилита диагностики и обслуживания базы NTDS.dit, но она критически важна до и после операций с системным состоянием. Перед плановыми работами стоит проверить целостность базы и её текущий размер:

ntdsutil
activate instance ntds
files
info
integrity
quit
quit

Команда integrity запускает низкоуровневую проверку структуры базы данных ESE, на которой построен NTDS.dit. Это стоит делать после каждого нештатного завершения работы контроллера домена (внезапное выключение, сбой питания) перед тем, как доверять этому DC системное состояние для бэкапа — повреждённую базу бэкап только законсервирует.

Отдельная и куда более практичная функция ntdsutil — создание снимка AD «на лету» для offline-анализа без остановки самого контроллера домена:

ntdsutil
activate instance ntds
snapshot
create
quit
quit

Такой снимок можно смонтировать в отдельную папку и открыть в качестве read-only базы через dsamain — это удобно, когда нужно восстановить один-два удалённых объекта (пользователя, группу), не поднимая полное восстановление системного состояния из бэкапа.

Восстановление: authoritative и non-authoritative

Тут кроется ловушка, в которую попадает большинство администраторов, впервые восстанавливающих AD. Есть два принципиально разных сценария:

• Non-authoritative restore — восстанавливаешь системное состояние из бэкапа, контроллер загружается в Directory Services Restore Mode (DSRM), после чего при следующей репликации подтягивает все более свежие изменения от других контроллеров домена. Это стандартный сценарий, когда srv-dc01 — не единственный DC в лесу.
• Authoritative restore — используется, когда нужно откатить объект (например, случайно удалённое подразделение с сотнями пользователей) и заставить это откаченное состояние реплицироваться на все остальные контроллеры домена как самое актуальное, перезаписывая их более свежие версии.

Восстановление системного состояния запускается так же через wbadmin, но обязательно из среды восстановления (загрузка в DSRM или через установочный носитель Windows Server):

wbadmin start systemstaterecovery ^
  -version:09/05/2026-02:00 ^
  -backupTarget:\\srv-backup01\wbadmin\srv-dc01_20260905 ^
  -quiet

Для authoritative restore после non-authoritative восстановления нужно зайти в тот же ntdsutil и явно пометить нужный объект или всё поддерево как авторитетное:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Sales,DC=itpages,DC=lab,DC=local"
quit
quit

Если этот шаг пропустить, восстановленный объект просто исчезнет через несколько минут — его «перетрёт» репликация от других контроллеров домена, которые ничего не знают о том, что объект вообще был восстановлен, и считают его состояние устаревшим.

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

Худший сценарий — если srv-dc01 является единственным DC в лесу (что часто бывает в компаниях среднего размера) и его полностью зашифровал вымогатель. Тут non-authoritative restore не поможет — реплицировать изменения не от кого. Восстановление системного состояния на новое или переустановленное железо в такой ситуации автоматически становится authoritative — данные из бэкапа станут единственной версией правды для всего домена. Именно поэтому для сценариев с одним DC особенно важна регулярность бэкапа системного состояния — минимум раз в сутки, а лучше держать хотя бы второй, пусть виртуальный, DC именно ради живой копии для non-authoritative сценария. Второй контроллер домена стоит копейки в виде виртуальной машины на существующем гипервизоре, зато полностью меняет сценарий аварии: вместо восстановления из бэкапа «с нуля» на новое железо получаешь обычную репликацию с живого соседа, что в разы быстрее и надёжнее.

Отдельно про SYSVOL и групповые политики

Системное состояние включает SYSVOL целиком, но на практике GPO и логон-скрипты меняются гораздо чаще, чем есть смысл гонять полный бэкап системного состояния. Для оперативного отката отдельной групповой политики удобнее держать более частый снапшот именно каталога SYSVOL средствами обычного файлового бэкапа или через встроенную в Windows Server резервную копию GPO из консоли управления групповыми политиками (GPMC), которая сохраняет версии политик в компактном виде без разворачивания всей AD:

Backup-GPO -All -Path \\srv-backup01\gpo_backups\$(Get-Date -Format yyyy-MM-dd)

Восстановление одной политики из такого архива занимает секунды через Restore-GPO и не требует ни DSRM, ни authoritative restore — это тот самый быстрый путь для ситуации «кто-то случайно поломал политику блокировки экрана на весь домен», когда поднимать полное восстановление системного состояния явно избыточно.

DSRM-пароль и регулярная проверка восстанавливаемости

Directory Services Restore Mode требует отдельного локального пароля администратора — того самого, что задаётся при установке роли AD DS через dcpromo или Install-ADDSDomainController. Этот пароль живёт отдельно от паролей доменных админов и его почти никогда не помнят в момент реальной аварии, потому что вводили его один раз, много лет назад. Проверить и при необходимости сбросить его можно заранее, не дожидаясь инцидента:

ntdsutil
set dsrm password
reset password on server srv-dc01
quit
quit

Храни этот пароль там же, где хранятся другие критичные для восстановления секреты — в физически или логически изолированном месте, не в общей базе паролей, к которой имеет доступ вся ИТ-команда, и уж точно не на самом srv-dc01 или srv-backup01, до которых доберётся тот же вымогатель.

Сам по себе рабочий бэкап без проверки восстановлением — это как огнетушитель, который никогда не проверяли: выглядит надёжно, пока не понадобится. Раз в квартал стоит поднимать тестовый контроллер домена (например, изолированную виртуальную машину без связи с продакшн-сетью 192.168.10.0/24) и разворачивать на него системное состояние из последнего бэкапа srv-dc01, проверяя, что DSRM-пароль подходит, integrity-проверка ntdsutil проходит чисто, а после non-authoritative restore контроллер нормально стартует и виден в консоли Active Directory Users and Computers.

Куда уезжает бэкап системного состояния

С srv-backup01 архив системного состояния srv-dc01 забирается job’ом Veeam на hardened-репозиторий srv-repo01, где хранится с неизменяемостью на уровне файловой системы (immutability flag через XFS). Это критично именно для AD: шифровальщик, получивший привилегии администратора домена (а вымогатели целенаправленно охотятся именно за такими правами), первым делом попробует уничтожить теневые копии и любые доступные бэкапы на серверах, до которых дотянется. Немодифицируемый бэкап на srv-repo01 — единственная гарантия, что после такой атаки будет с чего восстанавливаться.

Частые ошибки и как их избежать

• Бэкап только одного контроллера домена без проверки, какой именно является держателем FSMO-ролей. Если srv-dc01 держит роль эмулятора PDC или Schema Master, восстановление на новое железо требует дополнительных шагов передачи или захвата этих ролей (seize), и об этом нужно знать заранее, а не выяснять в момент аварии командой netdom query fsmo.
• Хранение единственной копии бэкапа системного состояния без ретеншна. Если бэкап перезаписывается каждый день без сохранения предыдущих точек, а повреждение базы NTDS.dit произошло, скажем, неделю назад и осталось незамеченным, ты просто забэкапишь уже испорченную базу поверх последней рабочей копии. Держи минимум 14 суточных точек системного состояния.
• Забытая проверка tombstone lifetime при долгом восстановлении. Если с момента снятия бэкапа прошло больше срока жизни tombstone (по умолчанию 180 дней в современных версиях AD), восстановленный контроллер домена может реплицировать некорректные метаданные удаления объектов. Для старых бэкапов системного состояния всегда сверяйся с этим сроком перед восстановлением.
• Неизвестный или утерянный DSRM-пароль. Без него загрузка srv-dc01 в Directory Services Restore Mode для восстановления системного состояния попросту невозможна. Проверяй и при необходимости сбрасывай этот пароль планово, а не в момент, когда домен уже недоступен и счёт идёт на часы простоя.

Автор — Команда IT-Pages