Чеклист миграции почты: как избежать проблем с датами

Почему чеклист миграции так важен

Миграция почты - одна из самых рискованных IT-операций в жизни организации. Вы переносите годы деловой переписки между платформами, и один-единственный просчёт может повредить метаданные всех почтовых ящиков. Самая частая жертва? Даты писем. После миграции каждое письмо рискует показывать дату переноса вместо реальной даты отправки или получения.

Этот чеклист охватывает каждый этап процесса миграции. Следуйте этим шагам, чтобы свести к минимуму риск повреждения дат и других проблем с метаданными. А если миграция уже завершена и проблемы с датами уже появились - продолжайте читать.

Фаза 1: планирование перед миграцией

Инвентаризация почтовых ящиков

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

Выбор подходящего инструмента миграции

Не все инструменты миграции одинаково обращаются с датами. Изучите, как каждый инструмент сохраняет IMAP INTERNALDATE и добавляет ли он заголовки "Received" в процессе вставки сообщений. Среди популярных инструментов - BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и нативный импорт через Exchange Admin Center. Каждый из них может вызывать проблемы с датами, потому что сам протокол IMAP требует, чтобы сервер назначения добавлял заголовок "Received" при вставке. Но одни инструменты лучше сохраняют INTERNALDATE, чем другие. Подробнее о том, как работает INTERNALDATE, читайте в статье IMAP INTERNALDATE: почему даты ломаются.

Полное резервное копирование

Создайте полную резервную копию каждого почтового ящика до начала миграции. Эта копия служит одновременно страховочной сеткой и точкой отсчёта для проверки дат после переноса. Для Google Workspace используйте Google Takeout или сторонний инструмент резервного копирования. Для Microsoft 365 - резервное копирование Exchange Online или экспорт в PST. Для IMAP-серверов используйте imapsync для создания локальной копии.

Храните резервные копии в месте, полностью отдельном от исходного и целевого серверов.

Документирование исходных дат

Отберите 10-20 писем на ящик из разных временных диапазонов (самые старые, самые новые и несколько промежуточных). Зафиксируйте дату получения, дату отправки и сырые заголовки каждого письма. Эти эталонные письма станут базой проверки после миграции. Сделайте скриншот ящика, отсортированного по дате, чтобы визуально задокументировать исходный хронологический порядок.

Фаза 2: тестовая миграция

Сначала мигрируйте тестовый ящик

Никогда не запускайте полную миграцию без предварительного тестирования.

Создайте тестовый ящик с репрезентативной выборкой писем (не менее 100, охватывающих несколько лет). Запустите миграцию только для этого ящика и тщательно изучите результаты, прежде чем продолжать. Такой тест выявляет проблемы с датами, ошибки кодировки, баги при обработке вложений и расхождения в структуре папок - до того, как они затронут рабочие ящики.

Проверка дат на тестовом ящике

Сразу после миграции тестового ящика проверьте даты. Откройте ящик в том почтовом клиенте, которым реально пользуются конечные пользователи (Outlook, Apple Mail, Thunderbird или веб-интерфейс). Сравните отображаемые даты с эталонными письмами, задокументированными в фазе 1. Проверьте как даты получения, так и даты отправки. Откройте сырые заголовки нескольких писем и найдите вновь добавленные заголовки "Received" с временной меткой миграции.

Если даты неверны на тестовом ящике, они будут неверны во всех ящиках. Остановитесь и решите проблему, прежде чем переходить к полной миграции.

Тестирование в нескольких почтовых клиентах

Разные почтовые клиенты по-разному отображают даты. Веб-интерфейс Gmail может показывать правильные даты (он использует заголовок "Date"), тогда как Outlook показывает дату миграции (он отдаёт приоритет заголовку "Received"). Протестируйте в каждом клиенте, которым пользуются сотрудники организации: Outlook для рабочего стола, Outlook в браузере, Apple Mail, Thunderbird и все мобильные почтовые приложения.

Фаза 3: выполнение миграции

Настройка инструмента миграции

Настройте инструмент миграции так, чтобы по возможности сохранять INTERNALDATE. В imapsync используйте соответствующие флаги для установки INTERNALDATE на сервере назначения. В BitTitan MigrationWiz проверьте расширенные параметры управления датами. Эти настройки не устранят полностью проблемы с заголовком "Received", но уменьшат серьёзность проблем с датами в ряде клиентов. Документируйте каждый использованный параметр конфигурации - это позволит воспроизвести миграцию при необходимости.

Миграция по пакетам

Не мигрируйте все ящики одновременно. Переносите по 10-20 ящиков, проверяя даты после каждого пакета. Если в пакете обнаружатся проблемы с датами, вы их заметите до того, как пострадает вся организация. Кстати, пакетная миграция снижает нагрузку на исходный и целевой серверы, уменьшая риск таймаутов и ошибок соединения, которые могут привести к частичным миграциям.

Мониторинг прогресса

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

Фаза 4: проверка после миграции

Немедленная проверка дат

Проверьте даты писем в течение 24 часов после миграции. Для каждого пакета откройте 5-10 ящиков и сравните даты с досмиграционными эталонами. Если даты неверны, задокументируйте масштаб проблемы (сколько ящиков затронуто, сколько писем в каждом) пока информация свежа.

Проверка всех типов папок

Проблемы с датами могут по-разному затрагивать разные папки. Проверьте даты во Входящих, Отправленных, Черновиках и во всех пользовательских папках и метках. Некоторые инструменты миграции обрабатывают папки последовательно, и ошибки в одной папке не обязательно означают ошибки в других.

Проверка поиска и сортировки

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

Типичные ошибки, вызывающие проблемы с датами

Пропуск тестовой миграции

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

Игнорирование добавленных заголовков "Received"

Администраторы часто сосредотачиваются на сохранении INTERNALDATE и упускают из виду проблему заголовка "Received". Даже когда INTERNALDATE установлен правильно, заголовок "Received" от миграции заставляет Outlook и другие клиенты показывать неверную дату. Это самый частый источник жалоб после миграции. Прочитайте почему письма показывают неправильную дату после миграции - там есть полное техническое объяснение.

Слишком ранняя остановка исходного сервера

Если проблемы с датами обнаруживаются после отключения исходного сервера, возможность повторной миграции исчезает. Оставьте исходный сервер доступным (хотя бы в режиме чтения) как минимум на 30 дней после миграции. Это обеспечивает запасной вариант, если позже всплывут серьёзные проблемы.

Что делать, если даты уже нарушены

Если миграция уже выполнена и даты неверны, ситуация поправима. Исходный заголовок "Date" сохранён в каждом письме, а значит, правильная информация о дате никуда не делась. Даты писем можно исправить после миграции - даже спустя месяцы или годы.

Проприетарный движок коррекции Redate.io подключается к ящику и ищет письма с повреждёнными метаданными дат. Многоступенчатый конвейер анализа идентифицирует сигнатуры инструментов миграции, применяет точечные исправления метаданных с полным сохранением структуры сообщений (включая подписи S/MIME, структуры multipart и заголовки с нелатинскими символами), и выполняет проверку целостности каждого исправленного письма. Анализ бесплатен и показывает точное количество затронутых писем. Оригиналы хранятся в видимой резервной папке на протяжении 30 дней.

Попытка выполнить такую коррекцию вручную или с помощью самописного скрипта выглядит заманчиво, но это серьёзный риск. Особые случаи - зашифрованные PGP-сообщения, повреждённые границы MIME, вложенные структуры multipart, проблемы с Content-Transfer-Encoding - могут незаметно испортить письма, и Вы это обнаружите только тогда, когда будет уже поздно. И как вообще проверить, что 10 000 исправленных писем все до одного в порядке?

Готовы проверить, есть ли в Вашем ящике проблемы с датами? Запустите бесплатный анализ с Redate.io - оплата не требуется, чтобы узнать, сколько писем затронуто.