Как проверить перенос почты перед отключением старого сервера

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

Почему одного счётчика писем мало

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

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

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

Как проверить папки и старые письма

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

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

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

Условный пример: папка есть, архив не подтверждён

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

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

В учебном сценарии не приписываю сбой ни кодировке, ни инструменту, пока этого не подтвердили данные. Среди возможных причин есть исключённая папка, ограничение выбранного способа переноса, задержка синхронизации или поиск не по тому месту. Это разные задачи и разные исправления. Если причина связана с именем папки, сначала проверяю, что поддерживают обе стороны и клиент, после чего согласую отображение имени. Если проблема в настройке исключений, сверяю её со списком папок. Слово «кириллица» само по себе диагнозом не является.

Проверьте доставку и доступ с устройств

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

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

Проверку доставки веду отдельно от проверки архива, чтобы не смешать отказ SMTP с пропуском старых сообщений. Записываю время теста, адреса отправителя и получателя, результат доставки и расположение письма в ящике. Если письмо пришло не туда, проверяю маршрутизацию и правила конкретной системы; если не уходит, смотрю журнал отправки и ответ сервера. Настройки SPF, DKIM и DMARC относятся к доменной аутентификации и обработке исходящей почты, а не к подсчёту архивных сообщений. Не ставлю эти записи в чек-лист как доказательство, что история переписки скопирована.

Что делать при расхождении

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

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

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

Когда можно отключить старый сервер

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

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

Старую систему оставляю доступной столько, сколько требует согласованный план переключения и условия провайдера. Это не обещание бесконечного хранения и не универсальный срок: за продолжение услуги может взиматься плата, а правила доступа после переключения различаются. До отключения также подтверждаю, кто владеет актуальной копией и кто вправе дать команду на прекращение услуги. Если компания полагается на резервную копию, согласовываю способ восстановления и проверяю, что копия охватывает нужные ящики. Без этого «у нас есть бэкап» — просто запись в расписании.

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