Перенос почты сорвался: возвращаю Яндекс и собираю письма

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

Когда я останавливаю перенос и выбираю откат

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

В SMTP я смотрю полный ответ и этап отказа. По RFC 5321 коды 4xx обозначают временную ошибку: отправляющая система должна повторять попытки по своей политике очереди. Коды 5xx обозначают постоянный отказ для этой попытки; рассчитывать, что такое же письмо само отправится после исправления, нельзя. Недоступное соединение тоже не доказывает утрату: письмо может оставаться у отправителя. Поэтому я сохраняю отчёт о недоставке целиком, адрес получателя и время, а не только фразу «почта сломалась». Письмо, которое новая система уже приняла, ищу в её журналах, очередях и ящиках. Письмо, которое отклонили окончательно, после устранения причины прошу отправить повторно.

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

• Проверить доставку, отправку и доступ отдельно.
• Сохранить полные SMTP-ответы и время проверок.
• Сопоставить отказ с заранее согласованными критериями.
• Проверить пригодность старой площадки для возврата.

Что я фиксирую до возврата MX

Я назначаю одного руководителя отката и отдельно записываю исполнителей: кто управляет DNS, кто проверяет ящики, кто сообщает сотрудникам рабочий адрес веб-почты. В небольшом офисе роли может совмещать один специалист, но доступы должны быть проверены заранее. План действий держу доступным независимо от переносимой почты. Общий план Б для почты описывает и другие отказы; здесь задача уже: остановить конкретный перенос и вернуть рабочий маршрут. Решение, причину и время записываю в журнал инцидента. Устное «кажется, мы уже откатились» потом невозможно сопоставить с журналами доставки.

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

Резервную копию готовлю перед переносом и проверяю восстановление на пробном ящике. У Яндекс ID есть заказ архива данных выбранного сервиса; его подготовка и получение — отдельная процедура. Такой архив нельзя заранее считать готовой резервной копией всей почты организации и настроек. Если копии нет, в аварии я сохраняю то, что доступно, и прямо отмечаю непроверенные данные. Обещание «сейчас мгновенно снимем всё на сервере» для внешнего почтового сервиса ничем не обеспечено. Рабочее место с открытым почтовым клиентом тоже не равно проверенному архиву. До окончания сверки я сохраняю старые учётные записи, доступ к новой площадке и возможность выгрузить данные. Бэкап, который никто не пробовал открыть, пока остаётся заявлением о намерениях.

• Записать решение, время и ответственных.
• Остановить задания миграции и удаления данных.
• Сохранить настройки, журналы и состояние очередей.
• Подтвердить доступ к старому сервису и копиям.

Как я сохраняю письма аварийного периода

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

Для уже сохранённой почты я выбираю контролируемое копирование с новой площадки обратно в старую и сначала проверяю его на пробном ящике. В справке Яндекса сборщик описан как получение писем из другого ящика; скорость зависит от исходного сервера. Это не резервный SMTP-приёмник и не гарантия непрерывной доставки. Вариант с отдельной папкой сверки допустим, если выбранный инструмент его поддерживает. У сборщика Яндекса при работе по IMAP нельзя назначить одну общую папку назначения: он копирует структуру исходных папок. Поэтому я не обещаю универсальную кнопку, которая сложит всю аварийную переписку в нужное место. Возможности импорта проверяю на конкретной площадке до массового запуска.

Для повторного копирования между доступными IMAP-ящиками подходит imapsync: он поддерживает перенос недостающих сообщений при следующих запусках. Я заранее проверяю направление, сопоставление папок и отсутствие удаления на обеих сторонах. Автоматически разворачивать прежнее задание «наоборот» опасно: старые правила обработки могут оказаться неуместны. Постоянную двустороннюю синхронизацию двух рабочих ящиков я этим инструментом не строю; автор отдельно предупреждает об ограничении. Временная пересылка в переходный период требует самостоятельной проверки маршрута: встречные правила могут образовать петлю. Я оставляю одно понятное направление, сохраняю оригиналы и проверяю результат на тестовом письме. Две стрелки навстречу друг другу ещё не означают отказоустойчивость.

• Составить перечень реальных ящиков и общих адресов.
• Различать принятое письмо, очередь и окончательный отказ.
• Проверить копирование на пробном ящике.
• Сохранить оригиналы и исключить встречные пересылки.

В каком порядке я возвращаю старую доставку

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

У MX есть TTL — срок кэширования DNS-записи. Снижение TTL надо делать заранее, дав кэшам прежнего значения время обновиться. Уменьшение числа в панели в момент аварии не сокращает срок уже полученной записи у чужого резолвера. Этот механизм описан в RFC 9199: удалить чужие DNS-кэши удалённо нельзя. Поэтому я сохраняю доступность обеих принимающих площадок, насколько это возможно, и наблюдаю фактические поступления на новую сторону. Ни «скрипт поменял MX за пять минут», ни «прошли сутки» не являются доказательством завершённого отката. Быстро отредактировать запись и быстро вернуть всю переписку — разные работы. Очередь у отправителя тоже живёт по собственному расписанию повторов.

Возврат входящих я проверяю отдельно от исходящих. Сотрудникам сообщаю, в какой системе теперь работать; при необходимости возвращаю проверенные настройки почтовых клиентов и служебных отправителей. MX не перенастраивает SMTP в приложениях и не меняет выбранный сотрудником ящик. Для SPF у одного имени домена допускается одна соответствующая запись; несколько отдельных записей SPF дают результат permerror по RFC 7208. Если в переходный период отправляют обе площадки, их разрешения согласую внутри одной записи. Не добавляю вторую «на всякий случай» и не ослабляю почтовую политику наугад. Ключи подписи, которые ещё нужны работающему отправителю, тоже не удаляю в спешке. После изменений проверяю внешнюю доставку и заголовки контрольного письма.

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

Как я проверяю, что письма собраны

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

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

В учебном бюро итог оформляю по проверяемым признакам: сотрудники работают в старой системе, контрольная переписка проходит, доступные сообщения новой площадки скопированы, очереди разобраны, исключения перечислены. Отдельно проверяю общие ящики, группы получателей и автоматические отправки из рабочих приложений. Перенос писем по IMAP сам по себе не возвращает контакты, календари и настройки сервиса; для них нужны отдельные проверки. Сотрудники подтверждают доступ к рабочей переписке, руководитель получает перечень оставшихся вопросов и порядок их решения. Обновлённые настройки DNS без этого перечня — слишком скромный результат для слова «восстановлено». Обещание «ни одного письма не потеряно» я оставляю только для случая, когда это подтверждают данные.

• Сверить папки, сообщения и найденные дубли.
• Проверить судьбу писем из очередей и отчётов об отказе.
• Проверить общие адреса и служебную отправку.
• Отдельно проверить контакты, календари и настройки.
• Зафиксировать результат и все непроверенные сообщения.

Что я меняю перед повторной миграцией

Повторный перенос я назначаю после разбора причины. Если новый сервер отклонял существующих получателей, исправляю перечень адресов и проверяю их приём. Если ошибалась отправка из приложения, тестирую его учётную запись и внешний маршрут. Если копирование пропустило папки, проверяю сопоставление и отчёт инструмента на выбранном ящике. Между попытками не совмещаю перенос с обновлением всей почтовой системы и заменой остальных настроек: иначе будет трудно понять, какое изменение помогло. Результат разбора — конкретная причина, исправление и воспроизводимая проверка. «DNS долго расходилась» без сохранённых ответов и сведений о TTL объясняет примерно столько же, сколько «вчера всё работало».

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

В обновлённом плане оставляю критерии остановки, исходные DNS-записи, ответственных, способ сохранения новых писем и условия закрытия старой площадки. Перед переключением заранее снижаю TTL, завершаю основной перенос и делаю повторное копирование доступных новых сообщений. Доступ к прежней системе сохраняю до сверки и согласованного завершения перехода. Бюро получает инструкцию, где работать во время отката, а администратор — порядок действий и проверок. Я не ставлю срок «к утру» без измерения объёма данных и проверки доступов. Сначала возвращаю людям возможность принимать и отправлять письма; затем закрываю расхождения в архиве. Это отдельные результаты, и в отчёте у каждого должно быть своё подтверждение.

• Устранить причину отказа и подтвердить исправление.
• Повторить сценарий на пробных адресах.
• Заранее проверить копии, доступы и TTL.
• Уточнить срок по пробному переносу и объёму данных.
• Согласовать условия завершения перехода.

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