Тестовый стенд переноса почты: как проверить imapsync, календари, DNS и двойную доставку до того, как трогать рабочие ящики

Облако не позволит вам отрепетировать уход — у него нет кнопки «тестовая копия». Значит, репетицию вы устраиваете сами, на своём сервере. Облачный провайдер не даст вам отрепетировать переезд: у него нет тестовой копии вашей организации, а ошибки вы увидите сразу на живых ящиках. Тестовый стенд переноса почты на своём сервере решает это — за пару часов в Docker собираются два почтовых сервера, DNS и календари, и каждый шаг переезда проверяется на тестовых данных. Мы прогнали на стенде десять сценариев — от первого переноса до обрыва большого ящика — и делимся результатами и граблями.

Зачем стенд, если есть документация

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

К тому же стенд — единственный способ проверить переезд, когда у источника нет тестовой среды: подключать рабочую облачную организацию к экспериментам никто не станет.

И ещё одно: стенд показывает реальное время. Не «перенос займёт какое-то время», а «755 писем за 11 секунд, гигабайт — за пару минут в локальной сети». С такими цифрами план переезда строится на фактах, а не на догадках.

Ошибаться — только на стенде

Каждая ошибка на живом переезде — это сотрудник без почты, клиент без ответа, руководитель с вопросом «почему». Каждая ошибка на стенде — это строка в журнале, которую никто, кроме инженера, не увидит. Разница огромна, а стоит стенд пару часов работы.

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

Из чего собран стенд

Всё в Docker на одном сервере. Два контейнера Dovecot 2.4 — «старый» и «новый» почтовый сервер. imapsync 2.326 в контейнере. bind9 с тестовой зоной для проверки DNS. Radicale — сервер CalDAV и CardDAV — для календарей и контактов. Postfix с утилитой swaks для проверки двойной доставки. Все сервисы в отдельной сети Docker и не видны снаружи.

docker network create mailstand
docker run -d --name stand-src --network mailstand dovecot/dovecot:latest
docker run -d --name stand-dst --network mailstand dovecot/dovecot:latest
# ящики заполняются тестовыми письмами скриптом: 7 папок, русские имена, флаги, вложения

Тестовые данные генерирует скрипт: ящик anna — 755 писем в 7 папках, в том числе «Отправленные», «Черновики», «Проекты/2025» и папка с амперсандом в имени; ящик info — 600 писем; ящик big — 900 писем, из них 700 по 2 МБ, около 1,4 ГБ. Флаги «прочитано», «отмечено», «отвечено» расставлены случайно.

Результаты: десять сценариев

Каждый сценарий мы прогоняли минимум дважды: первый раз — чтобы увидеть, как работает, второй — чтобы убедиться, что результат повторяется. Результаты в таблице — повторяемые, а не удачный случай.

Подробные команды и разбор каждого сценария imapsync — в статье «Перенос почты через imapsync».

Сценарий 1–3. Оценка, перенос, повтор

Оценка объёма без переноса заняла 4 секунды — так можно заранее понять, сколько займёт перенос всех ящиков. Первый перенос с автоматическим сопоставлением папок перенёс 11 папок и 755 писем без ошибок за 11 секунд; русские «Отправленные» и «Черновики» попали в системные папки Sent и Drafts. Повторный запуск не перенёс ничего и пропустил все 755 писем — повторные проходы безопасны, и на них строится весь переезд без простоя.

Сценарий 4. Грабля с кириллицей

Переименование папки при переносе с кириллицей в аргументе команды не сработало: внутри контейнера кириллица пришла искажённой, и папка создалась под старым именем. Решение — передавать имена в кодировке modified UTF-7, которой пользуется сам IMAP. С ней переименование «Заявки» в «Входящие заявки» прошло. Без стенда эту граблю мы бы нашли на рабочем ящике отдела продаж.

Сценарий 5. Дозаливка перед переключением

Перед сменой MX нужен короткий проход, который заберёт только новые письма. С опцией --maxage 1 imapsync перенёс ровно 5 новых писем за 4 секунды. Это и есть время «окна» при переключении: секунды на ящик, а не часы.

Сценарий 6. Обрыв большого ящика

Перенос ящика на 1,4 ГБ прервали через 90 секунд, на 602 письмах из 900. Повторный запуск дописал оставшиеся 298, пропустил уже перенесённые, итог — 900 из 900 без ошибок и дублей. Вывод: обрыв при переносе больших ящиков не страшен, достаточно запустить ту же команду снова. Подробно о больших объёмах — в статье о переносе сотен ящиков.

Сценарий 7. Сверка

После переноса число писем и байт по каждой папке сравнили на обеих сторонах — совпало. Дополнительно отдельный скрипт через IMAP SEARCH сравнил флаги по каждой папке: всего писем, прочитанных, отмеченных, отвеченных. Совпало всё. Сверка по флагам важна: сотрудник заметит, если все письма вдруг станут непрочитанными, раньше, чем пропажу пары писем.

Сценарий 8. Календари и контакты

На Radicale завели «старый» календарь с тремя событиями и адресную книгу с тремя контактами, выгрузили их стандартными запросами CalDAV и CardDAV и загрузили в «новую» учётную запись. Перенесено 3 из 3 событий и 3 из 3 контактов, названия на русском сохранились. Порядок для реального переезда — в статье о переносе контактов и календарей.

Сценарий 9. DNS

На bind9 прошли весь путь записей: исходный MX с TTL 3600, снижение TTL до 300 за сутки, переключение MX, SPF с новым сервером и старым провайдером на переходный период, DKIM и DMARC с p=none. После каждого шага — проверка зоны и рост серийного номера. Забытый серийный номер — частая причина, почему вторичные DNS-серверы не видят изменений.

company.test.  3600 IN MX 10 mx.old-provider.test.      # до переезда
company.test.   300 IN MX 10 mx.old-provider.test.      # TTL снижен за сутки
company.test.   300 IN MX 10 mail.company.test.         # переключение
company.test.   300 IN TXT "v=spf1 mx include:_spf.old-provider.test ~all"
_dmarc.company.test. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@company.test"

Сценарий 10. Двойная доставка

Postfix настроили доставлять каждое входящее письмо сразу в два почтовых сервера по LMTP — «старый» и «новый». Отправили тестовые письма — каждое появилось в обоих ящиках. Затем проверили поэтапное переключение: часть ящиков доставляется только в новый сервер, часть — в оба. Так можно переводить отделы по очереди, не теряя ни одного письма. Подробно — в статье о переносе без простоя.

Грабли стенда

Кроме кириллицы, стенд показал ещё несколько вещей, о которых стоит знать заранее.

• образ imapsync работает от непривилегированного пользователя — каталог журналов и файлы паролей должны быть ему доступны
• пароли передаются только файлами, иначе они видны в списке процессов
• Dovecot 2.4 отличается конфигурацией от 2.3 — примеры из старых инструкций не подходят
• LMTP без TLS допустим только внутри изолированной сети стенда
• первая загрузка образов занимает больше времени, чем все тесты вместе

Почему облако не даёт отрепетировать

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

Стенд на своём сервере возвращает вам право на репетицию. Всё, что можно сломать, ломается на тестовых данных. На рабочую почту выходят только проверенные команды.

Сколько времени это экономит

На стенде каждый сценарий занимает минуты. Найти ту же проблему на рабочем переезде — часы: сотрудник жалуется, администратор разбирается, ищет причину, переносит заново. Кириллица в именах папок, права на каталоги, поведение при обрыве — каждая такая находка на стенде экономит час-два живого переезда и одно неприятное утро понедельника. Для переезда на сотни ящиков счёт идёт на дни.

Стенд как инструмент на будущее

Стенд не выбрасывается после переезда. На нём проверяются обновления почтового сервера до установки на рабочий, новые правила Sieve, изменения DNS, восстановление из резервной копии. Это тестовая среда, которой у облачной почты нет и не будет: там обновления приходят к вам без спроса, и вы узнаёте о проблемах вместе с пользователями.

Для компаний на обслуживании мы держим такой стенд постоянно и прогоняем на нём каждое обновление перед выкаткой.

Тестовые данные: как сделать похожими на настоящие

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

Настоящие письма сотрудников на стенд не берём: тестовые данные генерируются, а реальные ящики переносятся только в рабочем переезде. Так стенд не становится ещё одним местом, где лежит переписка компании.

Порядок работ на стенде

Мы проходим сценарии всегда в одном порядке — от простого к сложному.

• поднять два сервера и заполнить источник тестовыми данными
• оценить объём и время без переноса
• перенести один ящик, повторить, сверить флаги
• проверить переименование папок и кодировки
• оборвать перенос большого ящика и докачать
• отрепетировать DNS: TTL, MX, SPF, DKIM, DMARC
• проверить календари и контакты
• проверить двойную доставку и поэтапное переключение
• записать время каждого шага для плана переезда

Что стенд не заменяет

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

Как собрать свой стенд

Повторить можно за пару часов: сервер с Docker, образы Dovecot, imapsync, bind9, Radicale и Postfix, скрипт заполнения тестовыми данными, похожими на ваши, — с вашими русскими папками и объёмами. Прогоните все десять сценариев, запишите время и результаты. На реальном переезде у вас будут проверенные команды и понимание, сколько займёт каждый шаг. Общий порядок переезда — в руководстве по переносу почты с Яндекс 360.

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