- Сообщения
- 202
- Реакции
- 0
Часть 1: стратегия и архитектура
Сразу скажу: это не теоретическая инструкция, собранная из документации. Я именно так переносил рабочую почту с Modoboa на Synology MailPlus и по ходу миграции поймал несколько нюансов, о которых в обычных гайдах почти не пишут.
Главная задача у меня была простая только на словах: перенести почту так, чтобы сотрудники продолжали работать, ничего не потерялось, а в момент переключения не пришлось судорожно возвращать старый сервер обратно.
Поэтому я изначально отказался от варианта «выключить старый сервер, перенести всё и потом разбираться». Делал всё параллельно: сначала подготовил новую площадку, затем перенёс основную массу почты, отдельно проверил DNS/NAT/TLS, и только потом переключал production.
Задача
Нужно перенести рабочий почтовый сервер с Modoboa на Synology MailPlus Server так, чтобы пользователи продолжали работать, а новые письма не потерялись во время переноса.
Дополнительно переносим общие календари и контакты.
Для примеров:
1. Исходная схема
Старый сервер находится в production. Пользователи читают и отправляют почту, новые сообщения приходят постоянно.
Поэтому плохой вариант:
2. Итоговая схема
3. Основной принцип миграции
Смысл здесь такой: основную массу почты переносим заранее. Сообщения, появившиеся после первой синхронизации, забираем финальной delta-синхронизацией.
4. Почему MX часто можно не менять
Если уже используется:
а меняется только сервер за
Пользовательские настройки остаются прежними:
Но после смены A-записи Migration по имени
5. Что подготовить заранее
6. Правила безопасности
7. Критерии успеха
Сразу скажу: это не теоретическая инструкция, собранная из документации. Я именно так переносил рабочую почту с Modoboa на Synology MailPlus и по ходу миграции поймал несколько нюансов, о которых в обычных гайдах почти не пишут.
Главная задача у меня была простая только на словах: перенести почту так, чтобы сотрудники продолжали работать, ничего не потерялось, а в момент переключения не пришлось судорожно возвращать старый сервер обратно.
Поэтому я изначально отказался от варианта «выключить старый сервер, перенести всё и потом разбираться». Делал всё параллельно: сначала подготовил новую площадку, затем перенёс основную массу почты, отдельно проверил DNS/NAT/TLS, и только потом переключал production.
Задача
Нужно перенести рабочий почтовый сервер с Modoboa на Synology MailPlus Server так, чтобы пользователи продолжали работать, а новые письма не потерялись во время переноса.
Дополнительно переносим общие календари и контакты.
Для примеров:
Код:
example.org — почтовый домен
mail.example.org — FQDN почтового сервера
calendar.example.org — CalDAV/CardDAV
203.0.113.10 — старый Modoboa
203.0.113.20 — новый публичный IP MailPlus
10.20.30.0/24 — MAIL VLAN
10.20.30.1 — шлюз
10.20.30.10 — Synology MailPlus
VLAN ID — 301. Исходная схема
Код:
INTERNET
|
203.0.113.10
|
Modoboa
+-------+-------+
| |
Postfix Dovecot
| |
SMTP IMAP
Дополнительно:
Radicale
├─ CalDAV
└─ CardDAVСтарый сервер находится в production. Пользователи читают и отправляют почту, новые сообщения приходят постоянно.
Поэтому плохой вариант:
Код:
Выключить старый сервер
→ начать перенос
→ включить новый
→ разбираться с ошибками2. Итоговая схема
Код:
INTERNET
|
203.0.113.20
|
Router/Firewall
|
dst-nat/src-nat
|
VLAN MAIL
10.20.30.0/24
|
10.20.30.10
|
Synology MailPlus
+------+------+
| | |
SMTP IMAP HTTPS3. Основной принцип миграции
Код:
Подготовка Synology
↓
Аудит старого сервера
↓
Тест одного mailbox
↓
Initial IMAP Sync
↓
Старый сервер продолжает работать
↓
Подготовка DNS/NAT/TLS
↓
Проверка нового сервера ДО DNS cutover
↓
DNS Cutover
↓
Final Delta
↓
Реальные входящие/исходящие тесты
↓
Остановка старых Postfix/Dovecot
↓
Повторный внешний тест
↓
Poweroff старого сервера
↓
DNS CleanupСмысл здесь такой: основную массу почты переносим заранее. Сообщения, появившиеся после первой синхронизации, забираем финальной delta-синхронизацией.
4. Почему MX часто можно не менять
Если уже используется:
Код:
example.org MX 10 mail.example.orgа меняется только сервер за
mail.example.org, то во время cutover достаточно изменить:
Код:
mail.example.org
203.0.113.10 → 203.0.113.20Пользовательские настройки остаются прежними:
Код:
IMAP: mail.example.org
SMTP: mail.example.orgНо после смены A-записи Migration по имени
mail.example.org уже будет попадать на новый сервер. Поэтому Final Delta выполняется по прямому IP старого сервера.5. Что подготовить заранее
- sudo/root на старом сервере;
- административный доступ DSM;
- доступ к DNS;
- возможность настроить PTR у провайдера;
- новый публичный IP;
- доступ к маршрутизатору и коммутаторам;
- резервные копии конфигурации;
- список mailbox;
- контрольные размеры/число писем;
- экспорт Calendar/Contacts, если они используются.
6. Правила безопасности
- Не мигрировать сразу всех — сначала один mailbox.
- Не переключать DNS, пока новый SMTP/IMAP не проверен напрямую по IP.
- Не удалять старый IP из SPF до окончания перехода.
- Не выключать старый сервер сразу после смены DNS.
- Не публиковать DSM 5001 напрямую.
- Не считать проект завершённым только по статусу “Migration completed”.
7. Критерии успеха
Код:
A mail.example.org → новый IP
MX example.org → mail.example.org
PTR новый IP → mail.example.org
SPF PASS
DKIM PASS
DMARC PASS
25/tcp SMTP
465/tcp SMTPS
587/tcp Submission
993/tcp IMAPS
443/tcp HTTPS
Open Relay: отсутствует
Unknown recipient: отклоняется
Existing recipient: принимается
Incoming mail: работает
Outgoing mail: работает
Final Delta: завершена
Последнее редактирование: