Самые неприятные истории с Exchange обычно начинаются одинаково — «всё работало, а потом…» и дальше набор драматических деталей: упавший узел, переполненные логи, RAID в ребут-петле, «кто-то» отключил резервные копии, а ведь «вчера ещё письма ходили». Хорошая новость в том, что сценарии катастроф в среде Exchange Server давно изучены и поддаются планированию. Если заранее определить цели по времени и объёму восстановления, выбрать устойчивую архитектуру, наладить бэкапы и мониторинг, то даже «плохой день» превращается в рутинную процедуру по инструкции — без паники, с минимальными потерями и предсказуемым результатом.
Зачем начинать с целей и карты системы
До железа, лицензий и даже до выбора редакции стоит честно ответить на два прагматичных вопроса: какое допустимое время простоя (RTO) и какой объём теряемых данных приемлем (RPO). Эти два числа дисциплинируют будущую архитектуру. Если почта критична, RTO стремится к минутам, значит потребуется высокая доступность, избыточность на уровне серверов и хранилищ, а заодно — процессы, которые реально работают ночью и в праздники. Если RPO равен нулю, нужно продумать лагированные копии, надёжные бэкапы и механизмы быстрой «достройки» данных после аварийного запуска.
Дальше — инвентаризация. Какие отделы пользуются почтой и как? Где узкие места по объёму трафика, какие требования к архивации и легальному удержанию? Насколько критичны публичные папки, какие интеграции завязаны на SMTP, и что будет, если они замолчат на пару часов? Карта сервисов позволит заранее выделить приоритетные компоненты — их потом будем запускать первыми.
Архитектура высокой доступности
Опорный механизм Exchange для отказоустойчивости — Database Availability Group (DAG). Базы почтовых ящиков реплицируются между несколькими узлами, а активная копия может автоматически перемигрировать при сбое. Важно не только включить DAG, но и грамотно его спроектировать: продумать распределение ролей, сеть репликации отдельно от клиентского трафика, хранение файлов свидетеля и стратегию автоматического переключения.
В одно-датацентровых развертываниях полезно разнести файлы свидетеля за пределы кластера — так меньше шансов потерять кворум из-за локальной беды. В двух площадках стоит рассчитать динамику кворума при частичных отказах, закрепить предпочтения активации баз и протестировать поведение кластера при «разводе мозгов» между сайтами. Не забудьте про lagged copies — отложенные на несколько часов/дней реплики помогают пережить логическую порчу данных, когда «сломанные» транзакции ещё не успели попасть во все копии.
Балансировка копий и Best Copy Selection
При переключении Exchange использует алгоритм выбора «лучшей» копии с учётом показателей отставания по журналам, очередям репликации и здоровья носителя. Это не магия: правильные метрики и читаемые алерты позволят заранее увидеть, что одна из пассивных копий хронически отстаёт, и принять меры ещё до инцидента. Регулярный аудит предпочтений активации и автоматических блокировок на узлах спасает от сюрпризов в час «икс».
Практика показывает, что разумный максимум баз на сервер — это не «сколько встанет», а столько, сколько реально успеете оперативно перевести, пересоздать и отресторить без пролонгированного простоя. Для стандартной редакции, где лимит по числу баз ниже, планирование становится ещё важнее: сегментируйте отделы, VIP-почтовые ящики, архивы и службы так, чтобы падение одной базы не валило весь офис.
Проектирование баз данных
Сложно спорить, что «одна большая база» выглядит заманчиво. Но как только в ней накопится критическая масса, одно повреждение превращается в «всё пропало». Разделите нагрузку на несколько баз: отделите активные ящики продаж от тяжёлых архивов, вынесите сервисные почтовые ящики и интеграционные коннекторы отдельно. Такой подход работает как предохранитель: одна база сломалась — остальные живут своей жизнью.
Следите за соотношением размера базы, скоростью дисков и окном обслуживания. Большая база дольше проверяется, дольше чинится и дольше пересоздаётся. Несколько средних — быстрее восстанавливаются параллельно. И не забывайте про хранение журналов транзакций на отдельном томе с мониторингом свободного места — переполненные логи обрывают репликацию в самый неподходящий момент.
Резервные копии
Exchange живёт журналами транзакций. Когда вы делаете корректный, application-aware бэкап, логи «вписываются» в базу и безопасно обрезаются. Если «бэкап» на самом деле не понимает Exchange и просто копирует файлы, журналы будут накапливаться бесконечно — диск закончится, сервисы остановятся, а вы узнаете об этом от пользователей. Поэтому требование №1: используйте совместимые решения, поддерживающие VSS и специфику Exchange, а не «любой удобный копировщик».
Классика выбора выглядит так. Полный бэкап — снимок всего сервера с данными и системой. Это долго и тяжело, зато простая точка возврата. Инкрементальный — быстро берёт только изменения, но восстановление потребует цепочки от последнего полного и всех последующих инкрементов. Дифференциальный — компромисс: каждая «диффа» ссылается только на последний полный, зато растёт по времени вместе с давностью этого полного. Есть ещё «copy backup», который не трогает логи, — им удобно делать «горячие» копии перед обновлениями без вмешательства в расписание.
Немного паранойи
Надёжная схема — минимум три копии данных на двух типах носителей, одна — вне площадки. Локальные ежедневные бэкапы на отдельном хранилище сокращают RTO: быстро подняли — быстро вернулись к жизни. Внеплощадочные — страхуют от пожаров, криптошифровальщиков и человеческих ошибок. Дополнительно подумайте об иммутабельности: объектное хранилище с блокировкой удаления, ленточные библиотеки с «возвратом в прошлое», периодические «островные» выгрузки без постоянного сетевого доступа.
И последнее о логах: включать «circular logging» ради экономии места — соблазн, но платой станет невозможность точного восстановления к моменту времени. Если RPO не равен «мне всё равно», лучше решать вопрос ёмкостью и регулярной усечкой журналов через корректные бэкапы.
Выбор и согласование стратегии бэкапа
Техника ради техники не нужна — обсуждайте расписание, точки восстановления и сроки хранения с бизнесом и комплаенсом. Для кого-то критично хранить годовые срезы, кому-то — иметь частые дневные точки и недельный ретеншен. Согласуйте эти параметры, задокументируйте их и проверьте, что выбранное ПО действительно поддерживает вашу версию Exchange и Windows, а также понимает DAG и логическую топологию.
Медиа-политика — отдельная песня. Ежедневные быстрые копии рядом, еженедельные и ежемесячные — на иной площадке, годовые — на долговременном носителе. При этом регулярно подтверждайте, что ключи, пароли к шифрованным копиям и инструкции на случай «админа нет на связи» существуют и доступны тем, кто будет восстанавливать систему ночью.
Мониторинг: видеть беду до того, как пользователи заметят
Пассивный админ — несчастный админ. Обязательно включите мониторинг производительности (CPU, RAM, диски, очереди RPC, задержки доставки), журналов событий и здоровья баз. Простые алерты по росту очередей, «залипанию» логов и отставанию репликации часто экономят часы простоя. Автоматические «синтетические транзакции» (пробные входы, отправка письма, доступ к OWA) дают уверенность, что сервис не только «запущен», но и реально обслуживает пользователей.
Не бойтесь писать маленькие PowerShell-скрипты, которые не устанут выполнять однотипные проверки, собирать статистику и рассылать отчёты. А ещё держите под рукой официальные «health checker»-скрипты и регулярные обновления — проще предупредить проблему, чем потом объяснять, почему патч «лежал в почте».
Документация и репетиции восстановления
Фраза «всё в голове у Васи» — худшая часть любого DR-плана. Сделайте живой, обновляемый runbook: где стоят сервера, как зовут сервисные учётные записи, где лежат сертификаты, какие команды запускают RecoverServer, где хранятся пароли к бэкапам и кто принимает решение о Failover`е (аварийное переключение). Раз в год устройте полноценную репетицию: поднимите чистую виртуалку, разверните голую ОС, восстановите роли, подключите базы и проверьте доступ.
Ежемесячные мини-практики — тоже чудо как полезны: взяли случайный PST, проверили экспорт/импорт, восстановили несколько писем из точки, подняли тестовую базу из бэкапа и сделали пробный маунт в изоляции. Такие тренировки оттачивают хореографию команды и находят пробелы там, где в реальной аварии времени на раздумья уже не будет.
Катастрофа не всегда «железная» — часто всё начинается с компрометированного аккаунта, уязвимого OWA или зловреда, который шифрует тома с базами. Минимальные правила просты: своевременные патчи, минимальные права для сервисных учёток, сегментация сети, многофакторная аутентификация, EDR на узлах, контроль доступа к бэкапам и их изоляция от домена. Чем сложнее злоумышленнику добраться до ваших копий, тем выше шанс, что восстановление вообще возможно.
Не забывайте про аппаратную сторону: прошивки контроллеров, состояние массивов, мониторинг температуры и питания. Казалось бы, мелочи, но именно они очень любят ломаться в пятницу ближе к вечеру.
Типовые сценарии восстановления и как их проходить
Не все аварии одинаково разрушительны. Полезно иметь готовые «карточки» с пошаговыми инструкциями — от лёгких случаев до «падает сайт».
- Порча одной базы. Останавливаем маунт, проверяем состояние, пытаемся «мягкое» восстановление (soft recovery) проигрыванием недостающих логов. Если не помогло — монтируем актуальную пассивную копию, переводим ящики, запускаем пересоздание повреждённой копии из здоровой, репликация потом догонит. Если копий нет — восстанавливаем из бэкапа в изолированную среду и реализуем dial-tone recovery, чтобы пользователи продолжили работу.
- Отказ сервера в DAG. Переносим активные базы на соседние узлы, проверяем клиентские доступа, убеждаемся, что автодискавер и SMTP живы. Дальше — RecoverServer: чистая ОС, те же имена, те же IP, запуск
Setup.exe /Mode:RecoverServerи пост-настройка. После возврата — пересев баз и выравнивание ролей. - Потеря сайта. В многосайтовой схеме переключаемся на вторую площадку по заранее отработанному плану: активируем копии, переключаем внешние записи, поднимаем свидетеля, меняем приоритеты активации, уведомляем службы и пользователей. Здесь особенно решает подготовленная автоматизация и актуальный DNS-плейбук.
Dial-tone recovery: чтобы почта не стояла
Это приём, когда пользователям быстро выдают «чистые» базы, чтобы они продолжали отправлять и получать письма, пока оригинальные данные восстанавливаются из бэкапа. Порядок действий прост: создаём пустую базу, подключаем ящики, возвращаем работоспособность бизнеса. Параллельно в песочнице из бэкапа поднимаем старые базы, извлекаем «исторические» данные и аккуратно «сшиваем» их с активной почтой. Пользователь видит текущую переписку, а старые письма появляются по мере дозаливки — без тотального простоя.
С точки зрения впечатлений это как запасное колесо: машина едет, а нормальная шина уже где-то на шиномонтаже. Главное — не перепутать направления экспорта/импорта и не забыть про дубликаты при финальной «склейке».
Восстановление без бэкапа: что можно, а что лучше не надо
В Exchange есть инструменты низкого уровня, но они требуют аккуратности. «Soft recovery» проигрывает утерянные логи и часто спасает ситуацию. «Hard recovery» с принудительной правкой базы (ESEUTIL /P) действительно умеет делать чудеса, но ценой потерь и непредсказуемых последствий — этот путь стоит оставлять на крайний случай, после копии побитой базы и осознанного согласия «да, часть данных можем потерять».
Часто помогает логическая реставрация без танцев с файлами: Dumpster/Recoverable Items, Single Item Recovery, Litigation Hold и журналы аудита — всё это позволяет вернуть случайно удалённые письма без вмешательства в базу. Если включены лагированные копии, «проигрывание» логов до момента перед поломкой даёт шанс аккуратно отмотать время и не терять свежие сообщения благодаря Safety Net.
Автоматизация, пайплайны и контроль версий конфигурации
Хрупкость ручных действий хорошо видна именно в авариях. Шаблоны PowerShell для развёртывания ролей, параметров транспорта, политик удержания и коннекторов экономят часы «клика по GUI» и снижают риск ошибки. Инфраструктурный код (скрипты, плейбуки, файл настроек DAG) лучше хранить в системе контроля версий — это страховка от «а что мы там меняли в прошлом месяце?». Интеграция с CM-системами позволит быстро накатить одинаковые настройки на новый узел после RecoverServer.
Ещё одна полезная привычка — «чек-листы для людей». Отметили пункт — идём дальше. В спешке это банально спасает от забытых DNS-записей, непривязанных сертификатов и неоткрытых портов на межсетевом экране.
Инструменты восстановления: как выбирать и что ожидать
Когда задача — вытащить данные из повреждённой или «осиротевшей» базы, а сервер недоступен, помогают специализированные инструменты, которые умеют открывать EDB, анализировать структуру, извлекать ящики, архивы, публичные папки и экспортировать их в PST или напрямую в живую среду. Требования к таким решениям простые: совместимость с вашей версией Exchange и форматом баз, корректная работа с кодировками, возможность выборочного экспорта, журналирование операций и оценка результата на тестовом стенде перед «боевой» миграцией.
Каким бы ни был выбранный софт, относитесь к нему как к хирургическому инструменту: сначала — копия исходной базы, потом — работа в изоляции, и только после проверки результатов — перенос данных пользователям. Чудесные «исправлю всё одним кликом» обещания обычно разбиваются о реальность структуры EDB, поэтому трезвая предварительная оценка и пилот на тестовой базе сэкономят нервы и время.
Частые ошибки, о которых потом жалеют
- Единая большая база «потому что так проще» — при порче теряется сразу целый отдел.
- Непонимающие Exchange «бэкапы», после которых логи не усечены, а диски переполнены.
- Отсутствие репетиции DR — инструкции есть, но ими никто не пользовался и половина команд устарела.
- Хранение ключей шифрования бэкапов на том же сервере, который шифрует вымогатель.
- Недокументированные зависимости: внешние коннекторы, ретрансляторы, DNS-записи, сертификаты.
- Разовый «героизм» вместо автоматизации — один человек помнит, как это делается, но в отпуске именно он.
Краткий пошаговый план на «плохой день»
- Оценка: что сломалось, какие базы/узлы/сервисы затронуты, каков масштаб.
- Стабилизация: остановить деградацию — освободить место, разорвать порочную репликацию, выключить проблемный узел.
- Коммуникация: уведомить заинтересованных, обозначить прогноз по RTO и приоритеты восстановления.
- Выбор сценария: фейловер в DAG, dial-tone или реставрация из бэкапа в изоляции.
- Техническая работа: переключение, RecoverServer, пересев баз, проверка клиентских доступов.
- Верификация: тест входа, отправка/получение, доступ к OWA/ActiveSync, доставка внешней почты.
- Ретроспектива: что пошло не так, какие алерты не сработали, что улучшить в архитектуре/процессах.
Итоги: устойчивость — это не галочка, а привычка
Продуманная архитектура с DAG и лагированными копиями, аккуратная сегментация баз, корректные и проверенные бэкапы, наблюдательный мониторинг, регулярные учения и здравый набор инструментов для точечного извлечения данных превращают «катастрофу» в рабочую процедуру. Никакой магии — только дисциплина, документация и немного упреждающего скепсиса к собственным настройкам. Чем раньше сформулируете цели по RTO/RPO, тем меньше будет импровизации в критический момент. А чем чаще репетируете, тем спокойнее спит команда — и ваши пользователи вместе с ней.
