Нужна ли кувалда, чтоб вынуть один кривой гвоздь?
Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.
Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.
И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.
Полный откат – не всегда ответ
С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.
Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.
Не «всё умерло», а:
– удалили одну важную группу;
– изменили атрибут у тысяч пользователей;
– сломали членства;
– неверно применили политику;
– после миграции обнаружили хвосты в объектах;
– интеграция записала в каталог не то, что должна была.
Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.
А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.
Почему полное восстановление неудобно
Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».
Для аварии это нормально.
Для точечной ошибки – не всегда.
Если откатить каталог целиком, можно вернуть не только испорченные данные, но и потерять корректные изменения, которые появились после бэкапа. Новые пользователи, изменения групп, обновлённые атрибуты, свежие правки политик – всё это тоже часть реальной жизни каталога.
Получается выбор без хорошего варианта:
1️⃣ откатить больше, чем нужно;
2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;
3️⃣ вручную разбирать, что именно поменялось.
Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.
Что хочется иметь на практике
В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».
А что именно изменилось между текущим состоянием каталога и снимком:
– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.
И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.
Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.
Кувалда нужна, когда стена рухнула. Но если надо достать один криво забитый гвоздь, кувалда внезапно становится странным выбором.
Где здесь РЕД АДМ 2.1 и Granulex Recovery
В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.
Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.
Для крупных инфраструктур это особенно важно. Чем больше пользователей, групп, политик, интеграций и зависимых сервисов, тем опаснее становится подход «ну сейчас быстро откатим всё назад».
Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.
Финальный вывод простой: резервная копия спасает от тяжёлого сбоя. Но логические ошибки в каталоге часто нужно не откатывать целиком, а аккуратно вынимать пинцетом.
