AD на Server 2025 и страницы 32 КБ: какие бэкапы станут бесполезными и как проверить это заранее

Обновление контроллеров до Server 2025 не переводит базу AD на страницы 32 КБ: обновлённый контроллер остаётся на 8 КБ, а включение функции в лесу необратимо и делает 8-килобайтные копии непригодными для обычного восстановления. Ниже — что именно сломается, как это проверить командами и как не потерять восстановление леса.

Почему AD на Server 2025 не готова к страницам 32 КБ после обновления

Начну с самого частого заблуждения. Админ ставит обновление ОС на контроллеры домена, видит заветные «Windows Server 2025» в свойствах и считает, что вместе с версией ОС поменялся и формат базы NTDS. Нет. Если вы делали аудит Active Directory хотя бы раз, вы знаете: самое интересное в домене лежит не в оснастках, а в файле базы, и в нём ничего не изменилось. По документации Microsoft, контроллеры, прошедшие обновление компонентов (in-place upgrade), продолжают работать с прежним форматом базы и страниц 8 КБ.

Откуда вообще взялись 32 КБ. База AD DS и AD LDS построена на движке ESE, и со времён Windows 2000 страница в ней была 8 КБ, что ограничивало масштаб леса и доменов. Формат со страницей 32 КБ даёт 64-битные идентификаторы длинных значений (LID), и многозначные атрибуты могут хранить примерно 3200 значений. Начиная с Windows Server 2025 новые установки AD DS и LDS получают именно 32-килобайтный формат. Но есть тонкость, на которой спотыкаются почти все: новый лес по умолчанию работает в режиме эмуляции 8 КБ ради совместимости со старыми контроллерами. База способна на 32 КБ, а ведёт себя как 8 КБ.

Получается три состояния, и путать их нельзя. Первое: контроллер обновлён «на месте», база 8 КБ, к 32 КБ не готова вообще. Второе: контроллер поставлен заново в лес на Server 2025, повышен по сети как новая реплика или восстановлен из копии в 32-килобайтном формате — база способна на 32 КБ, но работает в режиме эмуляции 8 КБ. Третье: функция «Database 32k pages» включена на весь лес — назад дороги нет. Мне нравится, как это называют в отчётах: «мы на Server 2025, значит, всё современно». Версия ОС тут вообще ни о чём не говорит, говорит атрибут на объекте NTDS Settings.

Переход на 32 КБ — операция уровня леса. Для неё нужно, чтобы все контроллеры в лесу работали на Windows Server 2025 или новее и имели базу, способную на 32 КБ, а уровни работы доменов и леса были подняты до Windows Server 2025 или выше. Один забытый контроллер с обновлённой базой — и вся история откладывается. Подробнее про инвентаризацию контроллеров и сам механизм я писал отдельно, это разбор страниц 32 КБ в AD на Server 2025; здесь я иду от другой стороны — от резервных копий, потому что именно они определяют, можно ли вообще трогать этот переключатель.

Какие бэкапы AD станут несовместимыми после включения 32 КБ

Главная правка к картине мира: размер страницы базы сохраняется внутри резервной копии. До Windows Server 2025 все копии были 8-килобайтными, других просто не существовало. Теперь на Server 2025 бывают оба формата, и копия «помнит», с какой базой её сняли. Копия с обновлённого на месте контроллера — это 8 КБ. Копия с нового контроллера в лесу 2025 — формат 32 КБ, даже если лес пока работает в режиме эмуляции. И копия, и восстановленный из неё контроллер сохраняют этот формат.

Теперь правило, ради которого я пишу эту статью. Пока функция не включена, контроллер Server 2025 можно восстанавливать из копии любого формата — и 8 КБ, и 32 КБ. После включения функции — только из копии в формате 32 КБ. Microsoft предупреждает прямо: вернуться к режиму эмуляции 8 КБ нельзя, поэтому любые копии 8 КБ, снятые до включения, перестают быть пригодными, если только вы не делаете полное авторитативное восстановление леса. Для маленького домена это звучит как шутка про мышеловку: вход бесплатный, выход через пересборку всего.

Сведу всё в таблицу, потому что в голове это держится плохо. | Откуда копия | Формат в копии | До включения функции | После включения функции | |---|---|---|---| | Контроллер, обновлённый на месте | 8 КБ | можно восстановить контроллер | только в рамках полного авторитативного восстановления леса | | Новый контроллер в лесу 2025 (режим эмуляции 8 КБ) | 32 КБ | можно восстановить контроллер | можно восстановить контроллер | | Контроллер, повышенный по сети как реплика | 32 КБ | можно восстановить контроллер | можно восстановить контроллер | | Контроллер до Server 2025 (2022 и старше) | 8 КБ | неприменимо к контроллеру 2025 без отдельной проверки | только в рамках полного авторитативного восстановления леса | Последняя строка таблицы — мой вывод из логики документа, а не отдельная цитата, поэтому проверяйте её на своей версии тестовым восстановлением. Дополнительно имейте в виду: если копию снимают сторонним продуктом, то формат внутри определяется базой, а не логотипом на коробке, и поддержку 32 КБ у вендора нужно подтверждать отдельно.

Что здесь самое неприятное. Бэкап не сломается в момент включения. Он будет лежать, красиво отчитываться «успешно», занимать место на NAS, и ровно до дня аварии вы ничего не заметите. Фраза «бэкап есть» без слов «и восстановление проверено» не значит ничего, а бэкапы делают все, проверяет их почти никто. Если сейчас у вас один контроллер с обновлённой базой и ночная копия на сетевой диск, то включение 32 КБ превращает этот диск в сувенир.

Если вам тяжело разобраться, в каком формате у вас копии и сколько контроллеров надо пересобрать, можно не тратить на это вечер: мы в АйТи-Фреш снимаем состояние леса, сверяем формат копий и показываем, что из этого жить будет, а что нет. Достаточно написать, и сначала мы просто посмотрим, не залезая в ваш прод.

Как проверить формат базы на каждом контроллере и включена ли функция

Проверка занимает минуту и выполняется с любой машины, на которой стоят средства администрирования AD (RSAT). Размер страницы, на который способна база каждого контроллера, хранится в атрибуте msDS-JetDBPageSize объекта NTDS Settings. Значение 32768 означает контроллер, способный работать на 32 КБ. Значение 8192 — база 8 КБ. Если значения нет, контроллер работает на Windows Server 2022 или старше. Команда из документации Microsoft, в моём варианте для условного домена example.com:

Get-ADObject -LDAPFilter "(ObjectClass=nTDSDSA)" -SearchBase "CN=Configuration,DC=example,DC=com" -Properties msDS-JetDBPageSize | Format-List distinguishedName,msDS-JetDBPageSize

В выводе будет по одной записи на каждый контроллер: отличительное имя объекта NTDS Settings и значение атрибута. Сверьте количество записей с реальным числом живых контроллеров. Я регулярно нахожу в конфигурации «призраков» — объекты давно выведенных серверов, которые никто не удалил, и они же потом ломают любые массовые операции.

Вторая проверка — включена ли функция в лесу. Для этого есть командлет Get-ADOptionalFeature, который умеет искать как по имени, так и фильтром по всем функциям:

Get-ADOptionalFeature -Filter * -Properties EnabledScopes | Format-List Name,EnabledScopes

У включённой функции в EnabledScopes будет непустой список областей, у выключенной — пусто. Не путайте это с атрибутом msDS-JetDBPageSize: первый говорит, что умеет база, второй — что вы реально включили. Видеть 32768 на всех контроллерах и считать, что лес уже на 32 КБ, — классическая ошибка чтения. Лес в этот момент всё ещё в режиме эмуляции.

Теперь про то, чего делать не надо. Я встречал совет «просто возьмите esentutl и посмотрите заголовок базы на живом контроллере». Не делайте этого на работающем NTDS.dit: файл открыт службой каталогов, а рискованные эксперименты с боевой базой ради любопытства — дурной тон. Если нужно посмотреть файл, берите его из копии или с изолированной тестовой машины. Атрибут из AD отвечает на тот же вопрос без риска.

Отдельно соберите короткую табличку и положите её рядом с документацией: имя контроллера, версия ОС, значение msDS-JetDBPageSize, где и чем снимается копия, дата последнего тестового восстановления. Пять столбцов, по строке на контроллер. Когда спросят «а у нас вообще готовность к 32 КБ какая», вы ответите за две минуты, а не за два дня. Если вам неудобно держать это руками, такую таблицу мы вносим в паспорт инфраструктуры.

Как проверить бэкап AD восстановлением: пошаговая тестовая проверка

Microsoft в требованиях к включению функции написала то, что я говорю клиентам годами, только спокойнее: убедитесь, что ваше программное обеспечение резервного копирования совместимо с форматом 32 КБ, сделав в тестовой среде копию и восстановление базы, способной на 32 КБ. Подчеркну, что проверяется не отчёт «успешно», а именно восстановление и запуск службы каталогов. Для малого офиса это один вечер, для большого офиса — тоже один вечер, просто с большим количеством кофе.

Если вы снимаете состояние системы штатным Windows Server Backup, команда выглядит так. Работать надо от члена группы «Операторы архива» или «Администраторы» из командной строки с повышенными правами, а путь назначения может быть буквой тома или сетевой шарой:

wbadmin start systemstatebackup -backupTarget:\\nas01\dcbackup -quiet

Обратите внимание на ограничение из документации: Windows Server Backup не сохраняет и не восстанавливает кусты реестра пользователей HKEY_CURRENT_USER в составе копии состояния системы. Для контроллера домена это не проблема, но для остальных серверов запомните. И второе, о чём забывают почти все: копия на сетевую папку у Windows Server Backup не накапливается, следующая копия того же сервера в ту же папку перезаписывает предыдущую, а если новая копия упала на середине, вы можете остаться вообще без копии. Поэтому для истории версий я пишу каждую ночь в отдельную подпапку (или держу снимки на стороне NAS), а не надеюсь, что «там же лежит за две недели». Список доступных копий смотрит команда wbadmin get versions, и именно оттуда берётся идентификатор версии в формате ММ/ДД/ГГГГ-ЧЧ:ММ.

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

wbadmin start systemstaterecovery -version:10/19/2026-23:30 -backupTarget:\\nas01\dcbackup -machine:DC02

Дата в примере условная, подставьте свою из вывода wbadmin get versions. Параметр -authsysvol выполняет авторитативное восстановление SYSVOL, а -recoveryTarget нужен, когда копию разворачивают в другой каталог. Восстановление базы каталога делается в режиме восстановления служб каталогов, после перезагрузки сверьте итог параметром -showsummary.

После успешного восстановления проверьте три вещи: служба каталогов стартует, база открывается, контроллер отвечает на запросы в изолированной сети. Затем запишите в журнал дату проверки, формат копии (по атрибуту msDS-JetDBPageSize контроллера-источника), версию продукта и время восстановления. Для виртуальных контроллеров отдельная тема — снимки гипервизора. Я не рекомендую считать снимок ВМ резервной копией AD: откат контроллера к старому состоянию без поддержки идентификатора поколения ВМ приводит к рассогласованию репликации. Если вы копируете контроллеры целиком на уровне виртуалок, ознакомьтесь с тем, как это делается на Proxmox Backup Server, и обязательно проверьте поддержку VM-GenerationID у вашего гипервизора.

Разбор: психологическое консультирование «Внутренний компас», 11 рабочих мест

Условный пример из практики — центр психологического консультирования «Внутренний компас», 11 рабочих мест. Два контроллера на одном физическом хосте, оба обновлены с Server 2019 до Server 2025 «на месте» ещё весной: так проще, чем переустанавливать. Ночная копия состояния системы по расписанию уходит на NAS в подсобке, а 14 версий там живут только благодаря суточным снимкам папки на самом NAS: wbadmin в общую папку каждый раз пишет поверх прошлой копии. Админ на полставки гордо сказал, что у них «современный стек», и просил включить 32 КБ «раз уж всё равно на 2025». Цифры тут иллюстративные, но ситуация для офиса такого размера типовая.

Что показала проверка. msDS-JetDBPageSize на обоих контроллерах — 8192. Функция выключена. Все 14 копий на NAS — формат 8 КБ. Это значит, что при попытке включить функцию Enable-ADOptionalFeature не прошла бы проверку контроллеров (в документации сказано, что команда сама проверяет, что все контроллеры имеют базу, способную на 32 КБ), а если бы админ как-то обошёл условия, то все 14 копий превратились бы в бумагу. Хорошая новость: по сути включать нечего. В домене около 70 учётных записей пользователей и компьютеров, групп немного, многозначные атрибуты никуда не упираются.

Решение мы приняли такое. Функцию не включаем, это не нужно ни одному приложению. Контроллеры при этом переводим в состояние «способны на 32 КБ»: ставим новый контроллер DC03 на Server 2025 и повышаем его по сети, переносим роли FSMO, выводим из эксплуатации DC01, затем так же заменяем DC02. Параллельно переписываем задание копирования, чтобы копии снимались с DC03, и делаем первое тестовое восстановление в изолированной сети. Трудозатраты — примерно 9 часов инженера за два вечерних окна и 3 часа на проверку копий, календарно — три недели с запасом на наблюдение репликации.

Итог для клиента: два контроллера на Server 2025 с базой, способной на 32 КБ, режим эмуляции 8 КБ оставлен намеренно, свежие копии в формате 32 КБ и протокол тестового восстановления с датой и временем. Если когда-нибудь появится причина включать функцию, он будет готов за один рабочий вечер, а не за квартал. Старые 14 копий формата 8 КБ мы не выбросили сразу, а оставили на отдельном диске на время перехода, потому что пока функция выключена, они ещё полезны. Меня до сих пор веселит, что вся аварийная готовность держалась на надписи «бэкап настроен» в чьём-то блокноте.

Включать ли 32 КБ в малом офисе и в каком порядке действовать

Моя позиция простая: для домена до 50 рабочих мест включать функцию Database 32k pages, как правило, незачем. Выигрыш — в масштабе: больше значений в многозначных атрибутах, меньше упора в старые пределы. В небольшом домене вы с этими пределами не встретитесь. А цена известна: необратимость на уровне леса, зависимость от совместимости продукта резервного копирования и, по документации, возможный рост потребления памяти из-за больших страниц. Моё правило: включать только по реальной причине — конкретный атрибут упёрся в ограничение или приложение требует.

Если причина всё-таки есть, порядок действий такой. Сначала убедитесь, что домен здоров и репликация без ошибок. Затем проверьте, что все контроллеры работают на Windows Server 2025 или новее и показывают 32768 в msDS-JetDBPageSize. Поднимите уровни работы доменов и леса до Windows Server 2025. Определите контроллеры, которые держат глобальный каталог и роли FSMO, снимите с них копии и проверьте восстановление. Убедитесь, что ваш продукт копирования умеет снимать и восстанавливать базу в формате 32 КБ. Только после этого переходите к самой операции — в оснастке и в командной строке с учётной записью из группы «Администраторы предприятия».

Сама команда включения из документации, с подставленными именами. Не копируйте её в консоль «посмотреть, что будет»: она запросит подтверждение, но откатить результат потом нельзя:

$params = @{
    Identity = 'Database 32k pages feature'
    Scope    = 'ForestOrConfigurationSet'
    Server   = 'DC03.example.com'
    Target   = 'example.com'
}
Enable-ADOptionalFeature @params

После включения следите за репликацией, как рекомендует Microsoft, и сразу снимите свежие копии, уже в новом формате. Старые копии 8 КБ перенесите в архив с пометкой «только для полного восстановления леса». Если вам кажется, что это перебор для 11 компьютеров, вспомните, что восстановление леса — всё равно процедура, к которой нужно быть готовым. Резервное копирование в облако или на NAS в этом смысле не отменяет проверку: место хранения не имеет значения, если копию нельзя развернуть.

Про полное восстановление леса отдельно, потому что его часто путают с обычным восстановлением контроллера. Это крайняя мера на случай, когда все контроллеры леса вышли из строя; в руководстве Microsoft, которое сейчас описывает Windows Server 2022 и более ранние версии, прямо сказано, что во многих случаях это должен быть последний вариант. Подготовьте задокументированный план, проверенный в лаборатории на копиях из боя, и пересматривайте его при смене ОС. Если у вас уже есть полис, страхование киберрисков для малого бизнеса обычно спрашивает именно про проверку восстановления, а не про наличие бэкапа. Для Server 2025 сверяйте детали процедуры в актуальной документации.

Частые вопросы