Дельта-синхронизация после смены MX: когда закрывать старую почту

После смены MX я оставляю старую почту доступной для приёма и повторно копирую недостающие сообщения на новую площадку. Отключаю источник после проверки доставки, переноса и архива. Одного таймера недостаточно: ниже разберу, что считать дельтой, как проверить остатки и по каким признакам завершать переход.

Почему после смены MX письма приходят на старую площадку

При переносе корпоративной почты я разделяю смену маршрута и перенос содержимого ящиков. MX сообщает отправляющим почтовым системам, куда доставлять новые сообщения. Старую переписку эта запись никуда не копирует. После переключения письмо ещё может попасть на прежнюю площадку, если отправитель использует сохранённый DNS-ответ. Пока источник принимает почту, сообщение остаётся доступным для добора. Ошибка начинается там, где изменение записи принимают за завершение всей миграции.

DNS не рассылает новый MX всем участникам одновременно. Рекурсивные резолверы сохраняют ответы на срок TTL, а отправляющие системы используют полученные сведения. Если TTL уменьшили перед самым переключением, ранее закэшированный ответ продолжит жить по прежнему сроку. Поэтому я сначала записываю старый TTL, уменьшаю его заранее и выдерживаю прежний срок перед сменой MX. Браузер сотрудника здесь не управляет доставкой входящей почты. Географическая таблица «местные обновятся быстро, зарубежные через двое суток» тоже ничего не объясняет.

Приоритет MX определяет порядок выбора серверов. Меньшее число означает более предпочтительный узел; увеличение числа оставляет старую площадку возможной целью доставки. Это прямо следует из RFC 5321, раздела 5.1. Поэтому я убираю старый MX из опубликованного набора при переключении, если отдельная резервная маршрутизация не предусмотрена проектом. Сама старая площадка при этом продолжает принимать обращения по ранее полученным сведениям. Понизить её предпочтительность — ещё не значит выключить приём. У DNS такой кнопки нет.

Недоступность прежнего сервера не означает, что каждое письмо немедленно исчезло. При временной ошибке SMTP класса 4xx отправляющая система должна повторить попытку; постоянный отказ класса 5xx означает другой исход и обычно приводит к уведомлению о недоставке. Это различие закреплено в RFC 5321, разделах 4.2.1 и 4.5.4.1. Я проверяю конкретный ответ и журнал доставки, а не объявляю любой сбой потерей данных. Но рассчитывать только на чужие повторные попытки при плановом переносе — слабая замена сохранённому приёму.

Что я готовлю до переключения MX

Сначала я составляю таблицу соответствий: исходный ящик, целевой ящик, дополнительные адреса, общие папки, ответственный сотрудник. Целевые ящики создаю до копирования и проверяю вход в каждый. Это важная деталь из экспертной базы: штатная IMAP-миграция, описанная в документации Microsoft, требует уже существующих целевых ящиков. При переносе между другими площадками я также проверяю требования выбранного инструмента. Успешный вход администратора ещё не подтверждает, что конкретному сотруднику есть куда получать письма.

Затем выполняю основное копирование, пока источник обслуживает пользователей. В настройках переноса фиксирую отдельные адреса исходной и целевой IMAP-служб: они должны однозначно вести на нужные площадки и проходить проверку сертификата. После смены MX эти подключения должны сохранить смысл. Иначе задание с красивым именем «добрать старую почту» может подключаться совсем не туда. Пароли и токены в рабочую таблицу не складываю; для доступа использую согласованный способ хранения секретов и проверяю, что он доступен заданию синхронизации.

До общего переключения я провожу проверку до переезда: вход, отправка, приём, вложение и ответ на тестовое письмо. Проверяю также дополнительные адреса и работу общих ящиков. Если новая площадка отклоняет существующего получателя, менять MX рано. Проверка после удаления старого сервиса превращает исправимую настройку в аварию. План отката и доступ к прежней площадке готовлю здесь же, пока ещё можно спокойно проверить оба направления.

Отдельно предупреждаю сотрудников, с какого момента рабочей становится новая система. После перехода они читают, отправляют и раскладывают письма там; прежние ящики остаются источником для добора. Старые профили на телефонах, почтовые программы и приложения с отправкой через прежний сервис тоже входят в этот список. Иначе новые «Отправленные» продолжат появляться на старой стороне, а две версии папок начнут расходиться. Я согласую ограничение изменений в старых ящиках и проверяю его выполнение, а не надеюсь на одно письмо с инструкцией.

Ещё один факт из базы: обычный перенос через IMAP забирает почтовые сообщения, но не переносит календари, контакты и задачи. Для них нужен отдельный способ экспорта или миграции и отдельная проверка результата. В плане я также отмечаю правила сортировки, подписи, делегирование и общие адреса: копия писем сама по себе не доказывает готовность этих настроек. Полный ящик при пустом календаре — вполне возможный результат. Поэтому ответственного за каждый такой объект назначаю до переключения, а не после первой пропущенной встречи.

• Создать и проверить целевые ящики и адреса получателей.
• Завершить основной перенос и тест новой площадки.
• Зафиксировать исходный TTL и дождаться его истечения после снижения.
• Назначить рабочую систему и проверить доступ для добора.

Как запускать дельту и не затереть работу сотрудников

Дельтой я называю сообщения из согласованного объёма переноса, которых ещё нет на новой стороне. Среди них могут быть и свежие входящие, и старое письмо, пропущенное из-за ошибки предыдущего прохода. Это не обязательно выборка по дате после смены MX. Я продолжаю одностороннее копирование из старой системы в новую и разбираю ошибки по каждому ящику. Обратный перенос одновременно не запускаю: для него нужны другие правила разрешения изменений. Обычный добор не должен незаметно превратиться в попытку объединить две независимо меняющиеся почты.

Для такого переноса подходит imapsync. В экспертной базе и README проекта указано: по умолчанию он распознаёт уже перенесённые сообщения по заголовкам Message-Id и Received. Это помогает повторять проходы без полного повторного копирования. Но пересылка или обработка сообщения может изменить заголовки, поэтому я проверяю поведение на тестовом ящике и сохраняю согласованные правила сопоставления. Заявление «повторный запуск никогда не создаёт дублей» слишком смелое. Автоматика работает по признакам сообщения, а не узнаёт его в лицо.

У imapsync есть ещё одна существенная особенность: по умолчанию повторный проход обновляет флаги уже перенесённых сообщений. Когда сотрудник работает в новом ящике, старый статус может оказаться нежелательным. Ключ --noresyncflags отключает повторное обновление флагов для уже перенесённых сообщений; его назначение я сверил с README и FAQ проекта. Решение о его применении принимаю после теста: нужно заранее определить, чьи изменения сохраняем. Этот ключ не превращает перенос в двусторонний обмен и не решает конфликты перемещения между папками.

Расписание добора выбираю по длительности прохода, потоку писем и допустимой задержке их появления у сотрудников. Универсальной нормы «каждые 2–4 часа» нет. Если предыдущий проход ещё работает, второе задание для того же ящика не стартует. В отчёте сохраняю время начала и окончания, объём добавленного, ошибки и исключённые папки. Сбой доступа или превышение квоты вызывает разбор, а не молчаливый перенос проблемы на следующий запуск. Перед окончательным закрытием выполняю контрольный проход по всему согласованному набору папок.

Старые ящики при этом не обязаны пустеть. Копирование оставляет исходные сообщения на месте, и это нормально. Очередь SMTP содержит сообщения, ожидающие дальнейшей доставки; содержимое ящика — уже доставленные сообщения. Пустая очередь не подтверждает, что из ящиков всё забрано, а большой старый ящик не означает незавершённый перенос. Если вместо копирования выбран маршрут пересылки, его нужно проектировать отдельно. Я не включаю слепую пересылку на тот же адрес: она сама по себе не задаёт новую площадку и может создать петлю или дубли. Схема двойной доставки почты требует собственного контроля маршрута.

Учебный разбор: «Чистый дубль», 18 рабочих мест

Разберу порядок действий на условной московской студии звука «Чистый дубль» с 18 рабочими местами. Это учебный сценарий: время и количество сообщений ниже заданы для расчёта, а не взяты из журнала реального клиента. В примере сотрудникам нужны 18 личных ящиков; дополнительные адреса учитываем отдельно. Я заранее создаю назначения, копирую историю и проверяю новую почту на тестовых сообщениях. Длительность полного копирования определяем пробным проходом, а не числом сотрудников: одинаковые 18 ящиков могут содержать совершенно разный архив.

Пусть прежний TTL записи MX равен 3600 секундам, а выбранный переходный — 300 секундам. Снижаю TTL заранее и выдерживаю как минимум прежние 3600 секунд после публикации изменения на авторитетных DNS-серверах. Это арифметика данного примера, а не обязательные настройки для любой компании. К моменту смены маршрута основные данные перенесены, ошибки разобраны, доступ к источнику проверен. В пятницу в 20:00 публикуем новый MX без старой площадки в наборе. Старый сервис сохраняет приём, сотрудники переходят в новые профили.

В учебном журнале проход в 20:30 добавил 45 сообщений, следующий в 22:00 — ещё 12. Всего добрали 57 сообщений. Для каждого прохода сохраняем перечень добавленного и проверяем наличие этих сообщений в целевых папках. Из самих чисел нельзя сделать вывод, что все письма задержал DNS: среди них могли быть ранее пропущенные сообщения. Причину определяем по времени приёма и журналам. Зарубежный отправитель тоже не доказательство «медленного иностранного кэша». Географию в отчёт о причине сбоя не подставляют вместо проверки.

В новой системе к этому моменту уже есть собственные входящие. Поэтому требование получить одинаковый общий счётчик на обеих площадках здесь ошибочно. Я сопоставляю согласованный набор сообщений источника с результатом копирования, а входящие, принятые сразу новой системой, учитываю отдельно. Проверяю рабочие папки и сообщения с вложениями. Если появился дубль, выясняю его происхождение до массовой очистки. Кнопка удаления дублей без разбора правил сопоставления способна заметно сократить переписку. Особенно ту, которую как раз хотели сохранить.

К понедельнику в этом сценарии можно подготовить отчёт о переносе, но само наступление понедельника не разрешает удаление ящиков. Если старый сервис продолжает принимать сообщения, сохраняем добор и выясняем маршрут. Если новых поступлений нет, заканчиваем сверку и проверяем архив по критериям следующего раздела. Итог учебного примера — 18 подготовленных ящиков и 57 дополнительно скопированных сообщений с проверяемым списком. Здесь нет обещания перенести любой архив за выходные и нет утверждения о спасённых контрактах: таких данных у нас нет.

Как доказать, что остатки перенесены

Я начинаю сверку после переноса с перечня ящиков и папок, которые вошли в задание. Для каждого нужны результат последнего прохода, список ошибок и объяснение исключений. Успешное завершение процесса полезно, но не отвечает на вопрос о папке, которую забыли включить. Поэтому отдельно проверяю архивные папки, «Отправленные», черновики и вложенные каталоги. Согласованное исключение фиксирую явно: нельзя тихо пропустить старую папку, а затем назвать результат полным переносом.

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

Параллельно сверяю поступления на старую площадку после смены MX. Для собственного сервера использую журналы приёма и доставки; для размещённого сервиса — доступные отчёты администратора и данные заданий переноса. Если сервис не показывает подробный журнал, прямо отмечаю это ограничение и усиливаю проверку содержимого. Отсутствие записи в недоступном журнале ничего не доказывает. Для каждого найденного сообщения ищу подтверждение доставки в исходный ящик и затем его копию в целевой папке. Отдельно разбираю отказы и сообщения, задержанные до попадания в ящик.

Проверяю также, что пользователь может открыть выбранные сообщения, прочитать тело и скачать вложения. В выборку включаю разные папки, письма с нестандартными именами файлов и сообщения из последних проходов. Контроль отображения дополняет сверку, но не заменяет её. Если сотрудник уже переместил письмо на новой стороне, сначала ищу его там и проверяю историю действий, насколько она доступна. Повторное копирование вслепую может вернуть его в прежнюю папку и создать видимость ещё одного входящего.

В итоговом отчёте я разделяю перенесённое, согласованно исключённое и требующее исправления. У каждой ошибки есть причина и действие: восстановить доступ, освободить место, уточнить назначение папки, повторить перенос сообщения. После исправления проверяю результат повторно, а не закрываю замечание по факту запуска задания. Отдельной строкой идут контакты и календари с результатом их собственного переноса. Именно такой отчёт позволяет директору принять работу, а администратору — объяснить, на каком основании старую площадку можно закрывать.

• Все согласованные ящики и папки присутствуют в отчёте.
• Необъяснённых пропусков и ошибок копирования нет.
• Поступления на старую площадку сопоставлены с добором.
• Выборочные письма и вложения открываются на новой стороне.

Когда отключать старую почту и как сохранить откат

Срок наблюдения я определяю до переключения с учётом прежнего TTL, способа доставки и требований площадок. Затем проверяю фактические поступления и ошибки. Отсутствие новых писем в выбранном окне полезно только вместе с успешной сверкой, исправной новой доставкой и завершённым добором. Универсальное правило «прошли сутки — удаляем» не годится. Если письма продолжают поступать, продлеваю работу источника и разбираю причину. Уменьшить объём проверки календарём нельзя. Календарь умеет показывать понедельник, но не содержимое чужой очереди.

Перед закрытием проверяю опубликованный набор MX: старого сервиса в нём уже не должно быть, если его сохранение не предусмотрено отдельной схемой. Приём и отправка на новой площадке проходят контрольную проверку. Старые пользовательские подключения и приложения больше не создают там рабочую переписку. Если я управляю старым почтовым сервером, отдельно разбираю его очередь: ожидающие сообщения должны получить понятный исход. В размещённом сервисе использую доступные отчёты провайдера. Источник при этом может оставаться заполненным архивом — специально опустошать его перед приёмкой не требуется.

До удаления учётных записей сохраняю независимый архив согласованного объёма почты и проверяю, что из него можно восстановить выбранные сообщения с вложениями. Копия на отключаемой подписке независимым архивом не считается. Записываю место хранения, состав, ответственного и согласованный срок сохранения. Доступность экспорта не равна проверенному восстановлению: я открываю результат и проверяю содержимое. После этого можно согласовать завершение синхронизации и закрытие старой услуги. Регистрация домена и действующая DNS-зона должны продолжать работать; их судьбу не привязываю к произвольной дополнительной неделе.

План отката тоже не сводится к возврату старого MX. Новая запись опять будет кэшироваться, а сообщения, принятые новой площадкой за время её работы, автоматически назад не переедут. До возврата маршрута я определяю, где сотрудники продолжат работу и как забрать уже принятые данные. Обе площадки сохраняю доступными до разбора. Два встречных задания синхронизации без правил конфликтов сюда не добавляю. Иначе вместо восстановления доставки получим обмен копиями и спор о том, какая папка была правильной.

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

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