Перенос почтового сервера - это последовательность из аудита, резервного копирования, синхронизации и переключения DNS. Главная задача - сохранить все ящики, настройки и пароли пользователей, избежав простоя и потери писем. План ниже построен на реальных кейсах миграции Postfix+Dovecot, Exchange и готовых сборок вроде Mailcow или iRedMail.
Ключевой принцип: новый сервер должен быть полностью готов и проверен до изменения MX-записей. Параллельная синхронизация и заранее сниженный TTL дают время на откат без последствий для пользователей. Разберем каждый этап с командами и контрольными точками.
Если вы уже переносили другие компоненты инфраструктуры, общая логика вам знакома. Для почты есть свои особенности: DNS-записи SPF, DKIM и DMARC, очереди исходящих писем, IMAP-флаги и пароли. Ошибка на любом из этих уровней приводит к потере писем или попаданию в спам.
Подготовка к миграции: аудит текущей инфраструктуры
Первый шаг - зафиксировать текущее состояние. Без этого невозможно спланировать перенос и подготовить план отката. Аудит включает четыре блока: версии ПО, объем данных, зависимости и DNS-записи.
Соберите информацию о почтовом сервере: операционная система, версия MTA, MDA, веб-интерфейса, способ хранения писем. Для Postfix и Dovecot выполните:
postconf -d | grep mail_version
dovecot --version
Для Microsoft Exchange проверьте версию через Exchange Management Shell:
Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
Зафиксируйте пути к хранилищам писем, конфигурационным файлам и базам данных. Эти данные понадобятся при резервном копировании и переносе.
Инвентаризация почтовых ящиков и данных
Получите полный список ящиков. Для Postfix+Dovecot с виртуальными пользователями в MySQL или PostgreSQL выполните запрос к базе:
SELECT username, domain FROM mailbox;
Для Dovecot с passwd-файлом используйте:
doveadm user '*'
Оцените объем хранилища:
du -sh /var/vmail
Выявите алиасы, общие папки и автоответчики. В Postfix алиасы хранятся в /etc/aliases и в базе данных виртуальных доменов. Проверьте sieve-скрипты в /var/vmail/sieve или в базе. Общие папки в Dovecot настраиваются через namespace, проверьте /etc/dovecot/conf.d/15-mailboxes.conf.
Составьте таблицу: ящик, размер, алиасы, фильтры, автоответчик. Это рабочий документ для сверки после миграции.
Анализ зависимостей и интеграций
Почтовый сервер редко работает изолированно. CRM отправляет письма через SMTP, веб-формы на сайте используют тот же релей, мониторинг шлет уведомления. Каждая интеграция - это конфигурация с IP-адресом или hostname старого сервера.
Проверьте логи Postfix, чтобы найти все источники подключений:
grep "connect from" /var/log/mail.log | awk '{print $7}' | sort | uniq -c | sort -rn
Составьте список приложений и сервисов, которые используют почтовый сервер. После переключения обновите в них адрес SMTP-релея, если он изменился. Для веб-приложений проверьте конфигурационные файлы: .env, config.php, settings.py.
Отдельно проверьте, кто забирает почту по POP3 или IMAP. Если пользователи настроили клиенты на старый IP-адрес, после миграции им придется менять настройки. Планируйте коммуникацию с пользователями заранее.
Фиксация текущих DNS-записей и TTL
Экспортируйте текущую DNS-зону домена. Для BIND выполните:
dig @ns1.example.com example.com AXFR
Или сохраните зону из панели управления DNS-провайдера. Критичные записи для почты: MX, A для почтового сервера, SPF (TXT), DKIM (TXT), DMARC (TXT), PTR для обратной зоны.
Снизьте TTL для MX и A-записей до 300 секунд за 24-48 часов до миграции. Это ускорит переключение и откат. Проверьте текущие значения:
dig MX example.com +short
dig A mail.example.com +short
dig TXT example.com | grep -E "spf|dkim|dmarc"
Сохраните старые значения всех записей в отдельный файл. При откате вы просто вернете их обратно.
Выбор стратегии миграции: параллельная работа или cutover
Выбор стратегии зависит от размера системы и допустимого простоя. Для крупных инсталляций с сотнями ящиков подходит параллельная миграция. Для небольших серверов с возможностью ночного простоя - cutover.
Параллельная миграция держит оба сервера активными. Письма продолжают приходить на старый сервер, пока новый синхронизируется. Cutover предполагает полное переключение после подготовки. Обе стратегии требуют резервной копии и плана отката.
Параллельная миграция с синхронизацией
При параллельной миграции вы настраиваете новый сервер, синхронизируете все ящики, тестируете, и только потом переключаете DNS. Старый сервер продолжает принимать почту до последнего момента.
Для синхронизации используйте imapsync. Он переносит письма с сохранением флагов, папок и вложений. Пример команды для одного ящика:
imapsync --host1 old.example.com --user1 user@example.com --password1 secret \
--host2 new.example.com --user2 user@example.com --password2 secret \
--automap --syncinternaldates --useheader 'Message-Id'
Для массовой синхронизации напишите скрипт, который читает список ящиков из файла и запускает imapsync для каждого. Первый проход выполните за несколько дней до переключения, финальный - непосредственно перед сменой DNS.
Настройте временную маршрутизацию: если письмо пришло на старый сервер после финальной синхронизации, оно должно попасть на новый. Вариант - релей с нового сервера на старый по SMTP для непринятых адресов.
Миграция методом cutover
Cutover подходит для небольших систем: до 50-100 ящиков, объем данных до 100 ГБ, допустимый простой 2-4 часа. Вы полностью готовите новый сервер, копируете данные, переключаете DNS и останавливаете старый.
Риск cutover - письма, отправленные в момент переключения. Они могут попасть на старый сервер и потеряться. Чтобы этого избежать, выполните финальную синхронизацию, затем быстро переключите DNS и проверьте очереди на старом сервере.
Для cutover критично полное резервное копирование. Если новый сервер не заработает, вы должны вернуть старый за 15-30 минут. Держите старый сервер включенным минимум 48 часов после переключения.
Резервное копирование: страховка от потери данных
Резервная копия - обязательный этап перед любыми действиями. Копируйте почтовые ящики, конфигурации, базы данных и SSL-сертификаты. Бэкап должен быть полным и проверенным.
Для Postfix+Dovecot архивируйте /var/vmail, /etc/postfix, /etc/dovecot, базу данных виртуальных пользователей. Для Exchange используйте Windows Server Backup или экспорт в PST.
Создание полной резервной копии почтовых данных
Для Postfix+Dovecot с файловым хранилищем:
tar -czf mail-backup-$(date +%Y%m%d).tar.gz /var/vmail /etc/postfix /etc/dovecot
Для MySQL или PostgreSQL добавьте дамп базы:
mysqldump -u root -p postfix > postfix-db-backup.sql
Для Microsoft Exchange запустите Windows Server Backup с выбором роли Exchange или выполните экспорт ящиков в PST через New-MailboxExportRequest.
Скопируйте SSL-сертификаты: /etc/letsencrypt для Let's Encrypt, или пути из конфигурации. Для DKIM сохраните приватный ключ, обычно /etc/opendkim/keys.
Проверка целостности резервной копии
Бэкап, который не восстанавливается, бесполезен. Проверьте архив:
tar -tzf mail-backup-20260827.tar.gz | head -20
Выполните тестовое восстановление на отдельной машине или в изолированной директории. Убедитесь, что файлы читаются, база данных импортируется, конфигурации валидны.
Задокументируйте процедуру восстановления: какие команды выполнять, в каком порядке, сколько времени занимает каждый шаг. Этот документ - часть плана отката.
Настройка нового почтового сервера
Новый сервер должен быть настроен до начала синхронизации. Установите выбранный почтовый сервер, настройте домены, SSL, аутентификацию. Версии ПО должны совпадать или быть совместимыми со старым сервером.
Выбор платформы: Postfix+Dovecot для максимального контроля, iRedMail или Mailcow для быстрого развертывания, Zimbra для корпоративных функций. Принцип один: новый сервер должен принимать и отправлять почту для тестового домена до переключения.
Установка и базовая конфигурация
Для Postfix+Dovecot установите пакеты:
apt install postfix dovecot-core dovecot-imapd dovecot-pop3d opendkim opendmarc
Настройте SSL-сертификаты через Let's Encrypt:
certbot certonly --nginx -d mail.example.com
Проверьте конфигурацию Postfix:
postfix check
Для Dovecot:
dovecot -n | head -30
Настройте SPF, DKIM и DMARC на новом сервере. Сгенерируйте новые ключи DKIM, если старые недоступны, и подготовьте DNS-записи для публикации после переключения.
Перенос учетных записей и паролей
Сохранение паролей - критичный момент. Пользователи не должны сбрасывать пароли после миграции. Варианты зависят от способа хранения учетных данных.
Если оба сервера используют один формат хэшей, экспортируйте и импортируйте их напрямую. Для Dovecot с SHA512-CRYPT:
doveadm pw -s SHA512-CRYPT -p 'userpassword'
Скопируйте хэши из базы данных старого сервера в базу нового. Если форматы не совместимы, настройте синхронизацию с LDAP или Active Directory - тогда пароли хранятся в одном месте и перенос не требуется.
Для Exchange в доменной среде пароли хранятся в Active Directory. При миграции на новый Exchange в том же лесу пароли сохраняются автоматически. При переносе в другой лес используйте ADMT или настройте федерацию.
Синхронизация данных и тестирование
После настройки нового сервера перенесите все письма и проверьте работоспособность. Синхронизация выполняется поэтапно: первый проход за несколько дней до переключения, финальный - непосредственно перед сменой DNS.
Тестирование нового сервера выявляет проблемы до того, как они затронут пользователей. Создайте тестовые ящики, отправьте письма, проверьте спам-фильтры и веб-интерфейс.
Синхронизация почтовых ящиков
imapsync - стандартный инструмент для переноса писем между IMAP-серверами. Он сохраняет флаги (прочитано, отвечено), папки и вложенные структуры. Для больших объемов запускайте синхронизацию в несколько потоков.
Для Dovecot на обоих серверах используйте doveadm sync:
doveadm sync -u user@example.com -d ssh root@old.example.com doveadm dsync-server -u user@example.com
Этот метод быстрее imapsync, так как работает на уровне Dovecot. Для Exchange используйте New-MoveRequest или экспорт в PST с последующим импортом.
После первого прохода сверьте количество писем и папок. Ведите лог синхронизации для каждого ящика: сколько писем перенесено, сколько ошибок, время выполнения.
Тестирование нового сервера перед переключением
Создайте тестовый ящик на новом сервере. Отправьте письмо с внешнего адреса, проверьте получение. Отправьте письмо с тестового ящика на внешний адрес, проверьте, что оно не попало в спам.
Проверьте SPF, DKIM и DMARC:
dig TXT example.com | grep spf
dig TXT default._domainkey.example.com | grep dkim
Отправьте тестовое письмо на mail-tester.com и проверьте рейтинг. Он должен быть 9-10 из 10. Проверьте веб-интерфейс, работу с Outlook и Thunderbird, автоответчики и фильтры.
Проверьте очереди Postfix:
postqueue -p
Очередь должна быть пустой или содержать только тестовые письма. Настройте мониторинг доступности нового сервера до переключения.
Переключение DNS и финальная синхронизация
Переключение DNS - самый ответственный этап. Измените MX-записи, A-записи, SPF, DKIM и DMARC. Заранее сниженный TTL ускорит распространение изменений.
Выполните финальную синхронизацию непосредственно перед переключением. Она займет от нескольких минут до нескольких часов в зависимости от объема данных и скорости сети.
Обновление DNS-записей
Порядок обновления записей:
- Обновите A-запись для почтового сервера на новый IP-адрес.
- Обновите MX-запись, указав новый hostname почтового сервера.
- Обновите SPF-запись, добавив новый IP-адрес.
- Обновите DKIM-запись, заменив публичный ключ.
- Проверьте DMARC-запись, при необходимости обновите.
Сохраните старые значения всех записей. Проверьте распространение изменений:
dig MX example.com +short
dig A mail.example.com +short
Распространение DNS занимает от нескольких минут до 24 часов. При TTL 300 секунд большинство серверов увидят изменения в течение 15-30 минут.
Финальная синхронизация и мониторинг
После обновления DNS выполните финальную синхронизацию. Она перенесет письма, полученные на старый сервер за время между первым проходом и переключением.
Проверьте очереди на обоих серверах. На старом сервере очередь должна быть пустой или содержать только письма, которые не удалось доставить. На новом - обрабатываться без ошибок.
Настройте мониторинг: доступность SMTP и IMAP, размер очереди, время доставки. Следите за логами в течение первых 48 часов после переключения.
План отката: возврат к старому серверу
План отката - обязательная часть миграции. Он должен быть задокументирован и проверен. Время отката - не более 30 минут.
Держите старый сервер включенным минимум 48 часов после переключения. Не удаляйте данные и конфигурации до полной уверенности в стабильной работе нового сервера.
Процедура отката DNS и данных
Алгоритм отката:
- Верните старые значения DNS-записей: MX, A, SPF, DKIM.
- Проверьте, что письма снова поступают на старый сервер.
- Синхронизируйте письма, полученные на новый сервер за время работы, обратно на старый через imapsync или doveadm sync.
- Проверьте очереди на старом сервере.
- Уведомите пользователей о возврате к старому серверу.
Если старый сервер недоступен, восстановите его из резервной копии. Процедура восстановления должна быть задокументирована и проверена заранее.
План отката - это страховка. Его наличие снижает риски и позволяет действовать быстро в случае сбоя. Подробнее о планировании отката и типичных рисках миграции читайте в руководстве по рискам миграции IT-инфраструктуры.
Типичные ошибки и как их избежать
Ошибки при переносе почтового сервера приводят к потере писем, попаданию в спам и недовольству пользователей. Разберем частые проблемы и способы их предотвращения.
Недостаточное тестирование. Новый сервер проверяют после переключения DNS, когда проблемы уже затронули пользователей. Решение: тестируйте отправку и получение, спам-фильтры и веб-интерфейс до изменения MX-записей.
Игнорирование TTL. Высокий TTL замедляет переключение и откат. Решение: снижайте TTL до 300 секунд за 24-48 часов до миграции.
Отсутствие бэкапа конфигураций. Копируют только письма, забывая про конфигурационные файлы. Решение: архивируйте /etc/postfix, /etc/dovecot, базы данных и SSL-сертификаты.
Неучтенные интеграции. CRM и веб-формы продолжают отправлять письма на старый сервер. Решение: проведите аудит зависимостей и обновите конфигурации всех приложений.
Потеря писем при cutover. Письма, отправленные в момент переключения, теряются. Решение: выполните финальную синхронизацию и проверьте очереди на старом сервере.
Общий подход к переносу серверов, включая аудит зависимостей и чек-листы, разобран в пошаговом руководстве по миграции серверов.
Заключение: чек-лист успешной миграции
Следуйте этому чек-листу, чтобы перенести почтовый сервер без потерь данных и простоев:
- Проведите аудит: версии ПО, список ящиков, объем данных, зависимости.
- Зафиксируйте текущие DNS-записи и снизьте TTL до 300 секунд.
- Выберите стратегию: параллельная миграция или cutover.
- Создайте полную резервную копию и проверьте ее восстановление.
- Настройте новый сервер: домены, SSL, аутентификация, DKIM.
- Перенесите учетные записи и пароли без сброса.
- Выполните первый проход синхронизации ящиков.
- Протестируйте отправку, получение, спам-фильтры, веб-интерфейс.
- Выполните финальную синхронизацию.
- Обновите MX, A, SPF, DKIM и DMARC записи.
- Проверьте очереди и настройте мониторинг.
- Держите старый сервер включенным 48 часов.
- Задокументируйте процедуру отката.
Перенос почтового сервера - управляемый процесс. План, резервная копия и тестирование снижают риски до минимума. Если вы переносите и другие компоненты инфраструктуры, используйте практическое руководство по миграции серверов для общего планирования.