Переезд на iRedMail без потери писем: как мы мигрируем компании с Яндекса, Exchange и умирающих серверов

Почему миграция почты — это не «скопировать файлы»

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем компании до 50 рабочих мест в Москве, и переезд почты — та операция, которой клиенты боятся больше всего. Боятся обоснованно: у типичного заказчика 30–50 ящиков по 5–20 ГБ, в них — вся переписка с контрагентами за годы, и нужна она вся и сразу. Простой почты хотя бы на день — это остановленные продажи и бухгалтерия, которая не может отправить акты. При этом сама компания продолжает работать: письма приходят каждую минуту, в том числе прямо во время переезда.

Поэтому миграция — это не «скопировать файлы», а процесс с планом, репетицией и планом отката. В нашей практике три повторяющихся сценария:

• С облака — Яндекс 360 или VK WorkSpace. Обычно мотив экономический: за 40 ящиков набегает ощутимая годовая сумма. Технически это самый предсказуемый сценарий — облачные IMAP-серверы стабильны, ограничения известны.
• С панели хостинга — почта, живущая на том же shared-хостинге, что и сайт (Plesk, cPanel, ISPmanager). Мотив — качество: спам не фильтруется, ящики по 1 ГБ, письма теряются. Здесь сюрпризы — кривые префиксы папок и лимиты на IMAP-подключения.
• Со старого self-hosted — Exchange 2010, который не обновляли со времён установки, или iRedMail пятилетней давности на Debian, снятом с поддержки. Я называю этот жанр некромантией: сервер ещё жив, но каждый день может стать последним, и обновлять его на месте страшнее, чем переехать.

Во всех трёх случаях рабочий инструмент один — imapsync, а различаются подготовка и стратегия переключения. Разберу весь наш регламент по порядку.

Подготовка: инвентаризация и план отката

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

• Инвентаризация. Выгружаем полный список ящиков, алиасов, групп рассылки и пересылок со старой системы. Из Яндекс 360 — админкой, из панелей хостинга — экспортом или руками, из Exchange — PowerShell. Обязательно замеряем объём каждого ящика: суммарный объём определяет длительность синхронизации, а самые тяжёлые ящики гоняем первыми.
• Технические адреса. Отдельной строкой ищем ящики, которыми пользуются не люди: 1С, CRM, сканеры, сайт, обменники. Про них забывают в 100% случаев, а вспоминают, когда «перестали приходить счета из 1С».
• TTL вниз заранее. За сутки до окна снижаем TTL записей MX и A до 300 секунд. Тогда в момент переключения мир узнает о новом сервере за минуты.
• Согласованное окно. Финальное переключение делаем вечером буднего дня или в выходные — когда поток входящих минимален.
• План отката. Если после переключения что-то пошло не так, возврат — это одна смена MX обратно. Отсюда железное правило ITfresh: старый сервер не выключаем и не расторгаем тариф минимум 2 недели после переезда. Он — и план отката, и источник «а вот тут в старой почте было письмо».

imapsync — рабочая лошадка переезда

Установка и базовый синтаксис

imapsync — консольная утилита, которая копирует содержимое ящика с одного IMAP-сервера на другой: все папки, иерархию, флаги «прочитано/отвечено», даты писем. Ключевые свойства: перенос инкрементальный и идемпотентный — запуск можно прервать и повторить, уже скопированные письма не задублируются, докачается только новое. Именно это свойство делает возможной миграцию без остановки работы. Актуальная версия на июль 2026 — 2.314. В репозиториях Debian пакет то появляется, то исчезает из-за особенностей лицензии, поэтому надёжнее ставить по официальной инструкции: клонировать с GitHub и установить perl-зависимости из списка в INSTALL-файле проекта. Запускаем не с нового почтового сервера, а с отдельной машины-«перевалки» (подойдёт любой VPS или рабочая станция с Linux) — так нагрузка на диски нового сервера не конкурирует с его собственными сервисами.

Базовый вызов для одного ящика:

imapsync \
  --host1 imap.yandex.ru --user1 ivanov@company.ru --password1 'app-парольЯндекса' --ssl1 \
  --host2 mail.company.ru --user2 ivanov@company.ru --password2 'парольНаНовом' --ssl2

Первый прогон любого ящика делаем с ключом --dry — imapsync покажет, какие папки увидел и что собирается копировать, не тронув ни одного письма. Пять минут на «репетицию» экономят часы разбора неожиданностей.

Массовая миграция по CSV

Тридцать ящиков по одному никто в здравом уме не гоняет. Готовим файл users.csv — по строке на ящик: адрес и пароль на источнике, адрес и пароль на приёмнике через точку с запятой — и крутим цикл (у проекта imapsync есть официальный пример sync_loop_unix.sh, наш вариант упрощён):

#!/bin/bash
# users.csv: user1;password1;user2;password2
while IFS=';' read u1 p1 u2 p2; do
  imapsync --host1 imap.yandex.ru --user1 "$u1" --password1 "$p1" --ssl1 \
           --host2 mail.company.ru  --user2 "$u2" --password2 "$p2" --ssl2 \
           --useuid --logdir /var/log/imapsync
done < users.csv

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

Особенности источников

• Яндекс 360: обычный пароль для IMAP не работает — нужен «пароль приложения», который выпускается в настройках безопасности аккаунта (и IMAP должен быть включён в настройках почты). У VK WorkSpace и Mail.ru — та же механика.
• Панели хостинга: частая особенность — префикс иерархии папок, когда все папки живут «внутри» INBOX (INBOX.Sent, INBOX.Drafts). imapsync чинит это ключами --sep1 . --prefix1 INBOX., а имена служебных папок приводим опциями --regextrans2 — иначе «Отправленные» приедут в папку с английским именем рядом с русской.
• Старый self-hosted: сертификат почти наверняка самоподписанный и просроченный — добавляем --nosslcheck, а к совсем древним серверам без нормального TLS подключаемся с --notls1. Для Exchange 2010 предварительно проверяем, что служба IMAP4 вообще запущена — по умолчанию она выключена.

Скорость на практике

По нашим замерам на реальных миграциях: с Яндекса ящик качается со скоростью 3–8 ГБ в час, со старых серверов на медленных дисках — 1–3 ГБ в час. Упирается процесс либо в лимиты источника (облака дросселируют IMAP-трафик и число одновременных подключений — больше 3–4 параллельных потоков смысла нет), либо в диск приёмника. Ящик бухгалтера на 15 ГБ — это 2–5 часов. Отсюда главный вывод: основную массу почты переносим заранее, за несколько дней до переключения, а в день X гоняем только дельту — она занимает минуты.

Стратегия переключения: два пути

Путь 1: «большой взрыв» ночью

Классика для компаний, где вся почта в одном месте. Схема по шагам: заранее переносим 95% объёма → вечером дня X объявляем сотрудникам «после 19:00 не отправлять важное» → финальный прогон imapsync догоняет дельту за последние дни (благодаря идемпотентности просто повторяем ту же команду) → меняем MX на новый сервер → ещё один прогон imapsync утром, чтобы забрать письма, долетевшие на старый сервер по кешированному DNS. Пользователи приходят утром — почта на месте, работаем на новом сервере. Для 90% наших клиентов выбираем именно этот путь: он проще, а окно фактического «неопределённого состояния» — одна ночь.

Путь 2: мягкий переезд с двойной доставкой

Когда компания категорически не может позволить себе даже теоретическую потерю письма (юристы, тендерные отделы), делаем двойную доставку: MX переключаем на новый сервер сразу, а на новом сервере на переходный период настраиваем пересылку копий входящих на старые адреса (либо наоборот — на старом сервере форвард на новый, если MX меняем в конце). Обе системы какое-то время получают всю почту, пользователи мигрируют группами, и в любой момент можно откатиться без потерь. Цена — сложность: вдвое больше точек отказа, необходимость следить за петлями пересылки, и обязательная финальная сверка. Выбираем этот путь редко и осознанно.

Перенос того, о чём забывают

imapsync переносит письма — и только письма. Всё остальное переезжает отдельно, и именно «остальное» генерирует 80% обращений после миграции. Наш чек-лист из девяти пунктов:

1. Алиасы и группы рассылки. В iRedMail с бэкендом MariaDB заливаются SQL-запросами в таблицу forwardings базы vmail — по инвентаризационной таблице это 10 минут скриптом.
2. Пересылки на внешние адреса. Туда же, но сначала спросите заказчика — половина этих пересылок настроена уволившимися сотрудниками и давно не нужна.
3. Автоответы («я в отпуске») — пересоздаются в Roundcube/SOGo, автоматически не переносятся.
4. Sieve-фильтры пользователей. Правила сортировки из старого Dovecot копируются файлами (~/sieve), из облаков — увы, пересоздаются руками. Предупредите пользователей заранее: «пропавшие письма» после переезда — почти всегда сработавший или, наоборот, не переехавший фильтр.
5. Контакты. Экспорт vCard/CSV из старой веб-почты → импорт в Roundcube или SOGo (CardDAV).
6. Календари. Экспорт ICS из Яндекса/Exchange → импорт в SOGo (CalDAV). Повторяющиеся события с приглашениями иногда приезжают криво — проверяем ключевые.
7. Подписи. Хранятся в настройках веб-клиента, переносятся копипастом. Заодно повод привести их к единому корпоративному шаблону.
8. Технические ящики — 1С, CRM, сканеры, сайт: про них следующий раздел целиком.
9. DNS-хвосты: SPF старого провайдера (запись вида include:_spf.yandex.net) убираем из зоны только после полного отключения старой системы, DKIM-селекторы старого сервера — аналогично.

Интеграция с окружением клиента

1С и CRM отправляют почту через сервер

Счета из 1С, уведомления из CRM, документы из ЭДО — всё это должно продолжить отправляться после переезда. Наш стандарт: для каждой системы — отдельный технический ящик (1c@company.ru, crm@company.ru) с длинным паролем, отправка через SMTP 587 с STARTTLS и обязательной аутентификацией. Отдельные ящики дают две вещи: в логах сразу видно, кто именно шлёт, а при компрометации одной системы меняется один пароль. Чего мы не делаем никогда — не открываем анонимный relay «для своих IP»: рано или поздно за таким relay оказывается заражённая машина, и ваш новенький сервер с чистой репутацией улетает в блэклисты за одну ночь.

МФУ и «scan-to-email»

Сканеры — отдельная боль: прошивки офисных МФУ 2015 года не умеют TLS 1.2 и падают на рукопожатии с современным Postfix. Наша типовая схема для таких случаев: заводим ящик scanner@company.ru и проверяем отправку с самого МФУ; если аппарат не осиливает шифрование — не ослабляем TLS-политику всего сервера ради одного принтера, а ставим в локальной сети клиента крошечный relay (Postfix на любой линукс-машине или роутере), который принимает от МФУ по локалке без шифрования и передаёт на сервер по-взрослому, с TLS и аутентификацией. Периметр остаётся строгим, бухгалтерия сканирует как раньше.

Сайт компании

Формы обратной связи и интернет-магазин обычно шлют почту прямо с хостинга сайта. После переезда про них забывают, и заявки начинают падать в спам — ведь строгий SPF нового домена хостинг сайта не упоминает. Лечится двумя строками: IP хостинга добавляется в SPF (v=spf1 mx ip4:IP_сайта -all), а лучше — переводим сайт на отправку через SMTP-аутентификацию с техническим ящиком site@company.ru, тогда и DKIM-подпись у транзакционных писем появится автоматически.

Каталог пользователей: подключаем LDAP/AD

Если у клиента есть Active Directory, возникает соблазн единой учётки: один пароль для входа в Windows и в почту. iRedMail это умеет — при установке можно выбрать бэкендом OpenLDAP или указать существующий AD как источник пользователей. Звучит красиво, и для компаний, где AD — центр вселенной, мы так делаем.

Но буду честен про трудоёмкость: интеграция с AD — это решение на этапе установки, а не после (сменить бэкенд на живом сервере — фактически переустановка); отладка фильтров LDAP и атрибутов занимает больше времени, чем вся остальная настройка почты; каждая нестандартная операция усложняется, потому что большинство рецептов вокруг iRedMail написано под MySQL-бэкенд. Поэтому для типового клиента до 50 ящиков наш выбор — MariaDB-бэкенд и разные пароли: с менеджером паролей это не проблема, а сервер остаётся простым и предсказуемым. AD-интеграцию оставляем случаям, где она реально оправдана — жёсткие политики паролей, регулярная ротация, много текучки персонала.

День X: регламент переключения ITfresh по часам

Реальный таймлайн недавней миграции 38 ящиков (около 210 ГБ) с почты хостинга на iRedMail — привожу как есть:

Первые 48 часов после переключения мониторим три вещи: очередь Postfix на новом сервере (postqueue -p — растущая очередь означает проблему с доставкой), maillog на старом сервере (продолжают ли туда приходить письма), и канал обращений пользователей. К середине понедельника поток вопросов обычно иссякает.

Разбор типовых проблем после переезда

Четыре обращения, которые мы получаем после каждой миграции, и что за ними стоит на самом деле:

• «Пропали письма!» В 9 случаях из 10 письма на месте — сработал sieve-фильтр или письмо уехало в другую папку из-за изменившейся структуры. Ищем через веб-почту по отправителю во всех папках. Настоящая потеря при идемпотентном imapsync — экзотика, и её всегда видно в логах переноса.
• «Письма задвоились». Классика повторного прогона без ключа --useuid: если между прогонами письма перемещали между папками, imapsync без этого ключа опознаёт их как новые. Поэтому в нашем шаблоне команды --useuid стоит всегда. Дубли лечатся штатным ключом --delete2duplicates.
• «Mail.ru не принимает нашу почту». Новый IP без истории первые дни может попадать под грейлистинг и лимиты — это временно и лечится репутацией. Регистрируем домен в постмастере Mail.ru, следим за отчётами, не шлём массовых рассылок в первую неделю. Через 3–5 дней доставляемость выравнивается.
• «Outlook завис и что-то качает». После смены сервера Outlook пересоздаёт локальный кеш (OST) и выкачивает ящик заново. На 15 ГБ по офисному интернету — несколько часов. Предупреждаем заранее и советуем не выключать компьютер; в это время почта уже полноценно работает в веб-клиенте.

Итог: трудозатраты и чек-лист самопроверки

Сколько это стоит по времени? Наши нормативы для компании на 30–50 ящиков: инвентаризация и план — 2–3 часа; развёртывание нового сервера — вечер (по регламенту установки); фоновый перенос почты — 1–3 дня машинного времени при часе-двух присмотра; день X — 2–3 часа работы вечером; поддержка после переезда — 3–4 часа в первые два дня. Итого 10–15 человеко-часов на всю миграцию средней компании — при условии, что она идёт по регламенту, а не изобретается на ходу.

Чек-лист самопроверки перед тем, как объявить миграцию завершённой:

1. Все ящики из инвентаризации перенесены, логи imapsync без ошибок, объёмы сходятся.
2. MX указывает на новый сервер, старый сервер новых писем не получает.
3. Алиасы и группы работают — проверено письмом на каждую группу.
4. 1С, CRM, МФУ и сайт отправляют через новый сервер.
5. SPF/DKIM/DMARC актуальны, старые include-записи убраны из зоны.
6. Контрольный прогон imapsync через сутки после смены MX выполнен.
7. Старый сервер живёт ещё 2 недели в режиме «только чтение».
8. Пользователи подключены, поток обращений иссяк.

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

А если хочется переехать без самостоятельного погружения в imapsync — мы в ITfresh проводим такие миграции регулярно: с Яндекса, с хостингов, со старых Exchange, без потери писем и с дежурством после переключения. Напишите мне в Telegram @ITfresh_Boss или позвоните: +7 903 729-62-41.