Міграція електронної пошти: перемістіть пошту на новий сервер з мінімальним простоєм (реальні кроки)

Що насправді означає «мінімальний простій»

Для пошти «простій» — не один перемикач. SMTP-доставка — це store-and-forward: віддалені сервери будуть робити повторні спроби годинами або днями, якщо ваш сервер недоступний. IMAP зберігає стан: клієнти тримають відкриті з’єднання та кешують ідентифікатори поштових скриньок. DNS кешується: ваша «миттєва» зміна MX може зайняти день для деяких відправників.

Тому мета — не «без збоїв». Це контрольований збій:

• Ніякої втраченої пошти. Затримка допускається; втрата — кар’єрно обмежувальна подія.
• Коротке вікно, коли записи пишуться в одне місце. Під час переключення нова пошта має потрапляти на один сервер. Все інше — потенційна пастка.
• Передбачувана поведінка клієнтів. Точки доступу IMAP/Submission і сертифікати мають бути стабільними, щоб клієнти не бунтували.
• Відкат без молитв. Відкат має бути «повернути MX і знову ввімкнути вхід», а не «відбудувати стару машину з диму».

Модель міграції, яка працює в продакшні — це двопрохідна реплікація:

1. Бульк-синхронізація поки старий сервер працює.
2. Коротке замороження (або контрольована подвійна доставка) під час переключення, потім фінальна синхронізація.

Ви не переносите просто «електронну пошту». Ви переносите поштові скриньки, ідентичності, криптографічну репутацію та купу операційних припущень.

Кілька фактів (та історичних деталей), що змінюють рішення

1. SMTP старший за більшість ваших інструментів. SMTP був стандартизований на початку 1980-х і досі припускає переривчасте підключення і повторні спроби. Саме тому ваше переключення може бути терпимим, якщо ви правильно керуєте чергами.
2. MX-записи не змушують доставляти. Деякі відправники ігнорують пріоритет MX або кешують агресивно. Ви знижуєте ризик плануванням TTL, але ідеального контролю не існує.
3. UID в IMAP — не те ж саме, що ID повідомлення. Клієнти покладаються на послідовності UID в кожній поштовій скриньці та на UIDVALIDITY. Якщо ви випадково їх скинете, клієнти можуть дублювати або «втрачати» повідомлення до повної повторної синхронізації.
4. Maildir vs mbox — реальна операційна різниця. Maildir — це багато файлів; mbox — один файл. Міграція mbox за допомогою rsync може виглядати як «завершена», але при конкурентних записах руйнувати стан.
5. DMARC змінив, як працює «просто змінити IP». Сучасна доставляємість — це репутація плюс вирівнювання (SPF і DKIM). Ви можете порушити прийняття на стороні одержувачів навіть якщо ваш сервер здоровий.
6. Greylisting досі живе в деяких місцях. Нові відправники навмисно відкладаються. Під час переключення новий IP з «холодною» репутацією може означати більше відкладань і повільнішу пошту.
7. TLS на SMTP став мейнстрімом через опортуністичне шифрування. Більшість серверів охоче відкотяться до plaintext при неправильній конфігурації — якщо політика цього не вимагає. Ваша міграція може випадково знизити безпеку без видимого повідомлення.
8. Великі провайдери працюють за власними правилами. Деякі одержувачі підтримують внутрішню репутацію для IP і домену; переміщення серверів може виглядати як «новий відправник», навіть якщо ваш домен старий.

Визначте, що саме ви переносите: SMTP, IMAP, авторизація та сховище

Виберіть цільову архітектуру перед тим, як торкатися даних

Поштовий сервер — це не один демон. Це невелика екосистема:

• SMTP вхідний (порт 25): зазвичай Postfix. Приймає пошту для ваших доменів і застосовує політику.
• Submission (587/465): автентифікована відправка для користувачів; має вимагати TLS та аутентифікацію.
• IMAP/POP: зазвичай Dovecot. Саме тут виникає біль для клієнтів.
• Авторизація: локальні користувачі, LDAP, SQL, шлюзи типу OAuth. Неправильна міграція авторизації — це шлях прокинутися о 02:00.
• Сканування вмісту: rspamd/Amavis/ClamAV. Опціонально, але багато організацій покладаються на це, не визнаючи.
• Підписування DKIM: OpenDKIM/rspamd. Ключі мають пережити переміщення.
• Сховище: файлові системи + квоти + бекапи + снапшоти. Саме тут ви або матимете нудний успіх, або історію, яку будуть розповідати.

Перестаньте вважати, що DNS — це тільки MX

Для чистого переключення зазвичай зачіпаєте:

• A/AAAA для mail.example.com (точка доступу IMAP/submission)
• MX для example.com
• SPF TXT: авторизуйте нові IP для відправки
• DKIM TXT: переконайтеся, що новий сервер підписує тим самим селектором/ключем, або опублікуйте новий ключ заздалегідь
• DMARC TXT: вирівнювання та політика; не посилюйте політику під час тижня міграції
• Reverse DNS (PTR) для нового IP: багато одержувачів оцінюють без нього

Одна цитата про надійність, бо це правда

Надія — це не стратегія. — часто приписують в інженерних колах; використайте як перефразовану ідею, якщо хочете. В будь‑якому випадку — побудуйте відкат.

Жарт №1: Пошта — єдиний продукт, де «вона врешті доставилась» вважається критерієм успіху і водночас загрозою моделі загроз.

Підготовка перед міграцією, яка справді має значення

1) Виберіть ідентичність, яка не зміниться

Для мінімального простою зберігайте видимі для клієнтів імена хостів стабільними. Використовуйте mail.example.com для IMAP/submission і змінюйте IP за ним. Не змінюйте імена хостів і сертифікати в одному вікні обслуговування, якщо вам подобаються звернення в службу підтримки.

2) Зменшіть TTL DNS завчасно (і перевірте)

Зміни TTL допомагають лише якщо встигли розповсюдитися перед переключенням. Зменшіть їх щонайменше за 24–48 годин для:

• MX записів для домену
• mail.example.com A/AAAA записів

Використайте тимчасовий TTL, наприклад 300 секунд. Потім відновіть розумні TTL (3600–14400) після стабілізації.

3) Вирішіть: rsync, dsync чи export/import?

Якщо ви використовуєте Dovecot і IMAP, Dovecot dsync зазвичай безпечніший, бо зберігає метадані скриньок і може робити інкрементальні синхронізації чисто. Для чистого Maildir rsync може працювати, але лише якщо ви розумієте, що означають «зміни в польоті».

4) Заплануйте вікно «заморозки» пошти

Найчистіший переключення виглядає так:

• Зупиніть вхідний SMTP на старому сервері (або тимчасово відхиліть з 4xx).
• Злити черги й упевнитися, що вся нова пошта потрапляє на новий сервер.
• Фінальна синхронізація зі старого на новий для останніх змін у скриньках.

Це вікно замороження може тривати 5–30 хвилин, якщо ви зробили бульк-синхронізацію раніше.

5) Не мігруйте безлад; зробіть снапшот

Якщо ваше сховище підтримує снапшоти (ZFS, LVM, файлові снапшоти), зробіть їх. Можливість відкотити стан поштових скриньок — це різниця між «ой» та «інцидент».

Реальні завдання з командами: перевірити, реплікувати, перевірити, вирішити

Це не «іграшкові» команди. Це те, що ви реально виконуєте під час міграції продакшн поштової системи. Кожне завдання включає: команду, що означає вивід, і яке рішення прийняти.

Завдання 1: Інвентаризація слухаючих сервісів (старий і новий)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|465|587|993|143)\b'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1123,fd=14))
LISTEN 0      128          0.0.0.0:993       0.0.0.0:*    users:(("dovecot",pid=1402,fd=40))

Значення: Підтверджує, що Postfix master прив’язаний до SMTP/submission і Dovecot — до IMAPS. Відсутні порти означають, що клієнти не зможуть підключитися або вхід не пройде.

Рішення: Якщо новий сервер не слухає потрібні порти, зупиніться. Виправте фаєрвол/юнити сервісів перед синхронізацією даних або зміну DNS.

Завдання 2: Підтвердіть TTL DNS (що ви встановили vs реальність)

cr0x@server:~$ dig +nocmd +noall +answer MX example.com
example.com.  300 IN MX 10 mail.example.com.

Значення: TTL 300 — низький. Добре для маневреності при переключенні. Якщо ви ще бачите 3600/86400 — ви запізнилися.

Рішення: Якщо TTL високі і переключення скоро, плануйте довший період сумісності і тримайте старий сервер приймаючим довше.

Завдання 3: Перевірте, що ім’я резолвиться послідовно (A/AAAA)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Значення: Показує IP, до якого клієнти звертатимуться для IMAP/submission (якщо ви використовуєте цей хост). Для подвійного стеку перевірте AAAA також.

Рішення: Якщо A/AAAA не відповідає вашому плану — виправте DNS зараз, перед тим як розбиратися з фантастичними «не можу підключитися» зверненнями пізніше.

Завдання 4: Перевірте TLS-сертифікат на IMAP (клієнти дуже це цінують)

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = mail.example.com
Verification: OK

Значення: CN/SAN відповідає імені хоста; перевірка OK. При помилках перевірки клієнти можуть показувати попередження або відмовлятися підключатися.

Рішення: Виправте ланцюжок сертифікатів і ім’я хоста перед переключенням. Не відкладайте «потім»: ви цього не зробите.

Завдання 5: Підтвердіть ідентичність Postfix та домени (щоб не приймати для неправильних доменів)

cr0x@server:~$ sudo postconf myhostname mydestination virtual_mailbox_domains
myhostname = mail.example.com
mydestination = $myhostname, localhost.localdomain, localhost
virtual_mailbox_domains = example.com, example.org

Значення: Ви приймаєте пошту для потрібних доменів як віртуальні скриньки (поширений варіант). Якщо mydestination випадково містить example.com, ви можете локально доставляти у системні акаунти.

Рішення: Виправте маршрутизацію доменів зараз. Неправильна класифікація спричиняє тиху неправильну доставку.

Завдання 6: Перевірте формат і розташування скриньок (Maildir vs mbox)

cr0x@server:~$ sudo doveconf -n | egrep '^(mail_location|mail_privileged_group|first_valid_uid)'
mail_location = maildir:/var/vmail/%d/%n/Maildir
first_valid_uid = 5000

Значення: Шлях Maildir і базовий UID. Якщо новий сервер використовує інший mail_location або відображення UID, клієнти можуть бачити порожні скриньки або помилки прав доступу.

Рішення: Зберігайте шляхи скриньок і стратегію UID узгодженими між серверами, якщо ви не плануєте навмисно змінювати формати (це інший проєкт).

Завдання 7: Виміряйте розмір даних скриньок (щоб оцінити час синхронізації)

cr0x@server:~$ sudo du -sh /var/vmail
842G    /var/vmail

Значення: Оціночний розмір сховища пошти. Якщо це близько до ємності диска на новому сервері — ви не мігруєте, ви переїжджаєте в пожежу.

Рішення: Забезпечте принаймні 30–50% вільного простору. Поштові системи ростуть і відбуваються сплески (журналювання, індексація, тимчасові файли).

Завдання 8: Перевірте навантаження на файлову систему та inode (Maildir «їсть» inode)

cr0x@server:~$ df -h /var/vmail && df -ih /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  680G  62% /var/vmail
Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sdb1        120M   79M   41M   66% /var/vmail

Значення: Maildir може швидко витратити inode. Відсутність inode виглядає як «диск заповнений», хоча df -h показує вільне місце.

Рішення: Якщо використання inode високее, оберіть файлову систему/співвідношення inode, придатне для мільйонів дрібних файлів, або заплануйте архівацію.

Завдання 9: Бульк-синхронізація Maildir за допомогою rsync (перший прохід)

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2,progress2 /var/vmail/ root@mail-new:/var/vmail/
sending incremental file list
...
Number of files: 18,492,310 (reg: 18,491,900, dir: 310)
Total file size: 901,223,554,120 bytes
Total transferred file size: 901,223,554,120 bytes
Literal data: 210,331,112,455 bytes
Speedup is 4.28

Значення: Перший прохід копіює майже все. «Literal data» і speedup показують стиснення і дельту; у Maildir дельти зазвичай погані, бо повідомлення незмінні, але їх багато.

Рішення: Якщо продуктивність жахлива, не «тонуються» сліпо. Перевірте IOPS диска і мережу. Можливо, треба обмежити швидкість, планувати в неробочий час або використовувати ZFS send/receive, якщо доступно.

Завдання 10: Інкрементальна синхронізація (другий прохід) з rsync

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2 /var/vmail/ root@mail-new:/var/vmail/
Number of files: 18,492,400 (reg: 18,492,090, dir: 310)
Number of created files: 120
Number of deleted files: 6
Total transferred file size: 87,991,230 bytes

Значення: Дельта тепер мала. Саме цього ви хочете перед переключенням: коротке фінальне вікно.

Рішення: Якщо дельти все ще великі, користувачі активно змінюють пошту (переміщають папки, видаляють). Заплануйте коротке замороження або використайте dsync для безпечнішого погодження.

Завдання 11: Реплікація Dovecot dsync (переважно коли доступно)

cr0x@server:~$ sudo doveadm -v dsync -u alice@example.com remote:vmail@mail-new
dsync(alice@example.com): Debug: Added connection to remote:vmail@mail-new
dsync(alice@example.com): Debug: Mailbox INBOX: GUIDs match
dsync(alice@example.com): Debug: Finished successfully

Значення: Dsync порівнює GUID скриньок і синхронізує зміни безпечно. «GUIDs match» заспокоює; невідповідності можна виправити, але вони потребують уваги.

Рішення: Якщо dsync повідомляє про проблеми з UIDVALIDITY або GUID, призупиніть і діагностуйте метадані скриньки перед переключенням. Тут народжуються «дублікати» у клієнтів.

Завдання 12: Переконайтеся, що Dovecot бачить скриньки на новому сервері

cr0x@server:~$ sudo doveadm mailbox list -u alice@example.com
INBOX
Sent
Trash
Archive/2024

Значення: Ієрархія скриньок присутня для репрезентативного користувача. Якщо порожньо — неправильні mail_location, права або відповідність авторизації.

Рішення: Виправте структуру зараз; не змінюйте DNS і не відкривайте питання «всі бачать тільки INBOX» потім.

Завдання 13: Перевірте права/власність у міграційних Maildir

cr0x@server:~$ sudo namei -l /var/vmail/example.com/alice/Maildir
f: /var/vmail/example.com/alice/Maildir
drwxr-x--- root  vmail /var
drwxr-x--- root  vmail vmail
drwxr-x--- vmail vmail example.com
drwxr-x--- vmail vmail alice
drwx------ vmail vmail Maildir

Значення: Директорії належать користувачу/групі пошти. Якщо ви бачите root:root у директоріях скриньок, Dovecot може викидати «Permission denied», і клієнти бачитимуть порожні папки.

Рішення: Виправте за допомогою chown -R vmail:vmail /var/vmail (обережно) і перевірте, що first_valid_uid/last_valid_uid узгоджуються.

Завдання 14: Перевірте стан черги Postfix перед переключенням

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
2A1B2C3D4E*     912 Thu Jan  4 10:15:11  sender@example.net
                                         user@example.com

-- 12 Kbytes in 1 Request.

Значення: Старий сервер ще має чергу. Невелика черга — нормально; зростаюча черга вказує на проблеми із зовнішньою доставкою.

Рішення: Якщо черга велика або застоюється — розберіться до переключення. Інакше ви мігруєте накопичення й називаєте це «простоєм».

Завдання 15: Слідкуйте за логами помилок доставки (під час тестування)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  4 10:21:07 mail postfix/smtpd[2201]: connect from unknown[198.51.100.77]
Jan  4 10:21:08 mail postfix/smtpd[2201]: NOQUEUE: reject: RCPT from unknown[198.51.100.77]: 450 4.7.1 Client host rejected: cannot find your hostname; from= to= proto=ESMTP helo=

Значення: Ви відхиляєте відправника через політику reverse DNS. Це може бути навмисно, але вдарить по вас, якщо ваша політика суворіша за бізнес‑толерантність.

Рішення: Вирішіть, чи хочете ви бути «технічно чистими», чи «отримувати пошту». Налаштуйте smtpd_client_restrictions відповідно, особливо під час тижня переключення.

Завдання 16: Підтвердіть SPF і DKIM перед перемиканням трафіку для відправки

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

Значення: SPF авторизує обидва IP тимчасово. Це безпечний підхід для переключення і відкату.

Рішення: Тримайте старий IP авторизованим поки не переконаєтесь, що ніякі системи більше не відправляють з нього (додатки, принтери, легасі-реле). Потім видаліть.

Завдання 17: Переконайтеся, що DKIM підписування відбувається на новому сервері

cr0x@server:~$ sudo rspamc stat | egrep 'dkim|dmarc|spf'
Actions: reject: 0, add header: 120, greylist: 4, no action: 980
DKIM sign: 110
DMARC policy: 12
SPF: 940

Значення: Показник «DKIM sign» зростає — вихідні підписуються. Якщо 0 — у вас будуть проблеми з доставкою, які виглядають як «випадкові відмови».

Рішення: Виправте підписування DKIM перед перемиканням вихідного трафіку. Відновлення доставляємості повільне, а знищити її — швидко.

Завдання 18: Smoke‑тест сквозного потоку пошти (SMTP in, IMAP read)

cr0x@server:~$ swaks --to user@example.com --server mail.example.com --port 25
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
<  220 mail.example.com ESMTP Postfix
>  EHLO client.local
<  250-mail.example.com
...
>  DATA
<  354 End data with <CR><LF>.<CR><LF>
>  Subject: migration test
>
>  hello
>  .
<  250 2.0.0 Ok: queued as 9F8E7D6C5B

Значення: SMTP приймає й ставить у чергу. Вам ще потрібно підтвердити доставку в скриньку і видимість у клієнті.

Рішення: Якщо SMTP приймає, але пошта не з’являється в IMAP, дивіться на доставку/LMTP, права скриньок або фільтри. Не чіпайте DNS, поки не зрозумієте причину.

Чеклісти / покроковий план (двопрохідна міграція)

Фаза 0: Обмеження та відкат (запишіть)

• Визначте вікно обслуговування і хто на виклику для DNS, пошти та сховища.
• Визначте тригер для відкату: наприклад, «рівень помилок вхідної доставки > X протягом Y хвилин» або «масові відмови автентифікації IMAP».
• Тримайте старий сервер цілим і доступним, поки не завершите. Не перепризначуйте IP в день один.
• Тимчасово авторизуйте обидва IP для відправки у SPF.

Фаза 1: Побудуйте новий сервер як слід

• Встановіть і налаштуйте Postfix + Dovecot + стек фільтрації, щоб відповідати існуючій поведінці.
• Скопіюйте DKIM ключі і переконайтесь, що селектори підходять до DNS (або опублікуйте нові ключі перед цим).
• Встановіть TLS‑сертифікати для стабільних імен хостів (особливо IMAP і submission).
• Зіставте базу користувачів/мапи автентифікації (LDAP/SQL/локально). Протестуйте на реальному користувачі.
• Підготуйте сховище з запасом і правильною щільністю inode; увімкніть снапшоти/бекапи.

Фаза 2: Бульк‑синхронізація даних пошти (перший прохід)

• Запустіть rsync або dsync поки старий сервер живий.
• Не зупиняйте сервіси; дайте користувачам працювати.
• Виміряйте тривалість і пропускну здатність. Якщо це займе дні, плануйте відповідно замість того, щоб робити вигляд, що все швидко.

Фаза 3: Валідaція перед будь‑якою зміною DNS

• Виберіть 5–10 репрезентативних скриньок: великі, малі, спільні, з інтенсивним використанням папок IMAP.
• Перевірте вхід, список папок і кількість повідомлень на новому сервері.
• Надішліть тестову пошту всередину і назовні; перевірте заголовки на підписи DKIM і ланцюжок Received.
• Підтвердіть квоти, правила sieve (якщо використовуються) і поведінку серверних фільтрів.

Фаза 4: Пре‑cutover дельта‑синхронізація (другий прохід)

• Запустіть інкрементальну синхронізацію, щоб зменшити фінальне вікно.
• Моніторьте активність записів на старому сервері (активні з’єднання IMAP і доставки).
• Повідомте користувачів: коротке вікно, коли пошта може затримуватися, краще за довгий таємний простій.

Фаза 5: Переключення (коротке замороження + DNS)

1. Припиніть або відкладіть вхідний SMTP на старому сервері (поверніть тимчасову помилку). Хочете, щоб відправники повторювали спроби, а не отримували відмову.
2. Переконайтесь, що submission (587/465) для користувачів вказує на новий сервер, бажано через те саме ім’я хоста.
3. Виконайте фінальну синхронізацію (rsync або dsync).
4. Переключіть MX (і A/AAAA якщо застосовується) на новий сервер.
5. Увімкніть вхідний SMTP на новому сервері і слідкуйте за логами, як за трилером.

Фаза 6: Пост‑переключувальний моніторинг і прибирання

• Слідкуйте за чергою Postfix, відмовами автентифікації Dovecot і затримками доставки.
• Тримайте старий сервер доступним лише для аварійного вилучення ще деякий час.
• Після періоду стабільності: відновіть більші TTL, видаліть старий IP з SPF і архівуйте старий сервер безпечно.

Жарт №2: Найнадійніший інструмент міграції пошти — це подія в календарі з назвою «Фінальна синхронізація», на якій дійсно присутні всі.

День переключення: DNS, черги та вплив на клієнтів

Як «заморозити» вхід без втрати листів

Ваш старий сервер має відповідати тимчасовою помилкою, щоб MTAs‑відправники повторювали спроби. Контрольований відтермінування безпечніший, ніж повне закриття порту, яке змусить деяких відправників вважати його ворожим. Якщо ви не можете чисто зробити політичну маршрутизацію, зупинка Postfix теж прийнятна — SMTP‑семантика повторних спроб існує з причини.

Практичний підхід: тримайте старий сервер працюючим, але змусьте його відмовляти нові вхідні з 4xx. Так він усе ще доступний для черги та адміністративного доступу.

Стратегія зливу черг

Перед переключенням ви хочете, щоб вихідна черга старого сервера була стабільною або зменшувалась. Якщо вона росте, ви переключитесь, а вихідний трафік залишиться заблокованим — користувачі трактуватимуть це як «пошта не працює», навіть якщо вхід працює.

Після переключення частина вхідної пошти може ще надходити на старий сервер через кешований MX. Майте план:

• Опція A (чисто): старий сервер відтерміновує весь вхід з 4xx на деякий час, змушуючи повтори слідувати новому MX коли кеші оновляться.
• Опція B (неохайно, але працює): старий сервер приймає і ретранслює вхід на новий сервер тимчасово.

Опція B може бути корисною, але саме так ви випадково створюєте петлі доставки і дублювання, якщо неправильно налаштуєте транспортні карти. Обирайте обережно.

Вплив на клієнтів і як зробити його нудним

Якщо користувачі підключаються до mail.example.com для IMAP і submission, і сертифікат дійсний на обох серверах, ви можете змінити A/AAAA без потреби переналаштовувати клієнтів. Основна помітна поведінка для клієнтів — коротке роз’єднання/перепідключення.

Якщо ви змінюєте імена хостів, отримаєте:

• Попередження сертифікатів
• Несумісність збережених паролів
• Мобільні клієнти застрягнуть на «перевірці облікового запису»
• Заявки «моєї скриньки немає» коли насправді відбувається переіндексація

Отже: тримайте імена хостів стабільними, якщо тільки це абсолютно необхідно.

План швидкої діагностики (знайти вузьке місце за хвилини)

Це порядок триажу, коли щось виглядає повільним або зламаним одразу після переключення. Не вигадуйте; дійте системно.

Перш за все: це DNS чи маршрутизація?

• Перевірте, який MX світ бачить для домену.
• Перевірте, який A/AAAA резолвить mail.example.com для клієнтів.
• Підтвердіть, що новий сервер фактично приймає з’єднання.

cr0x@server:~$ dig +short MX example.com
10 mail.example.com.

cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan  4 10:31:22 mail postfix/smtpd[3122]: connect from mx.remote[198.51.100.77]
Jan  4 10:31:23 mail postfix/smtpd[3122]: NOQUEUE: reject: RCPT from mx.remote[198.51.100.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; ...

Інтерпретація: Якщо логи показують з’єднання, DNS, ймовірно, в порядку. Помилка вказує на невідповідність пошуку одержувача/бази даних.

Друге: SMTP приймає, але не доставляє?

• Шукайте повідомлення в черзі, але без доставки.
• Перевірте LMTP/локальну доставку та логи Dovecot LDA/LMTP.
• Перевірте права файлової системи на vmail.

cr0x@server:~$ sudo postqueue -p | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9F8E7D6C5B      1043 Thu Jan  4 10:29:10  sender@example.net
                                         user@example.com

Інтерпретація: Якщо черга росте з локальними одержувачами — ланцюжок доставки зламаний. Це Dovecot LMTP/socket, права або карти одержувачів.

Третє: це проблема IMAP/автентифікації?

• Сплеск помилок автентифікації? LDAP/SQL креденшіали, відсутня SASL конфігурація або фаєрвол блокує бекенд автентифікації.
• IMAP повільний? IOPS диска або перевстановлення індексів Dovecot.

cr0x@server:~$ sudo doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Інтерпретація: Успішний тест автентифікації відводить підозру від LDAP/паролів. Якщо клієнти все ще падають — перевіряйте невідповідність імені хоста TLS або клієнтів, які пробують інший порт.

Четверте: сховище — прихований злодій?

• Високий iowait, повільні fsync, насичений пул — Maildir це показує швидко.
• Перевірте на виснаження inode.

cr0x@server:~$ iostat -xm 2 3
Device            r/s     w/s   rMB/s   wMB/s  %util  await
nvme0n1          12.1   210.3    0.3     8.7   98.9   45.2

Інтерпретація: %util близько 100 і високий await означає, що сховище насичене. IMAP почуватиметься «вимкненим», хоча сервіси технічно живі.

Рішення: Зменште навантаження (обмежте паралелізм), перемістіть індекси на швидше сховище або масштабируйте IOPS. Не звинувачуйте Postfix — він просто стоїть.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: Деякі відправники доставляють на старий сервер годинами

Корінна причина: Кешовані MX‑записи або відправник ігнорує низький TTL; ви змінили TTL пізно або деякі резолвери його ігнорують.

Виправлення: Тримайте старий сервер доступним. Або відтерміновуйте вхід 4xx, щоб відправники повторили спроби і слідували за новим MX пізніше, або тимчасово ретранслюйте на новий сервер для критичних IP з захистом від петель.

2) Симптом: Користувачі бачать дублікати повідомлень після міграції

Корінна причина: UID/UIDVALIDITY IMAP змінилися через скидання метаданих скриньки або конвертацію формату без збереження стану.

Виправлення: Віддавайте перевагу dsync. Зберігайте метадані Dovecot (індекси, GUID) коли це можливо. Якщо вже зламалося — ізолюйте уражені скриньки і перезавантажте синхронізацію з інструкціями для клієнтів щодо скидки кешу.

3) Симптом: «Аутентифікація не вдалася» повсюди відразу після переключення

Корінна причина: Новий сервер вказує на неправильну базу LDAP, відсутня SASL конфігурація або фаєрвол блокує бекенд автентифікації.

Виправлення: Використайте doveadm auth test і перегляньте логи SASL. Перевірте мережеве з’єднання до LDAP/SQL з нового хоста.

4) Симптом: SMTP приймає пошту, але вона ніколи не потрапляє до скриньок

Корінна причина: Транспорт доставки Postfix неправильно налаштований (шлях до сокета LMTP не той) або права/UID vmail не співпадають.

Виправлення: Перевірте virtual_transport/mailbox_transport в Postfix і Dovecot LMTP сокет. Підтвердіть власність і first_valid_uid відповідає реальному UID vmail.

5) Симптом: Вихідна пошта потрапляє в спам або відхиляється після міграції

Корінна причина: SPF не включає новий IP, DKIM не підписує, відсутній PTR або холодна репутація IP.

Виправлення: Попередньо опублікуйте SPF для обох IP; забезпечте DKIM підписування; налаштуйте PTR і HELO, щоб збігатися; якщо можливо, нарощуйте вихідні обсяги поступово.

6) Симптом: IMAP «вгору», але дуже повільний

Корінна причина: Вузьке місце IOPS сховища, перевстановлення індексів Dovecot або антивірус/фільтрація вмісту завантажує CPU/диск.

Виправлення: Перевірте iostat, навантаження і кількість процесів Dovecot. Перенесіть індекси на швидше сховище, підлаштуйте ліміти процесів і уникайте повної індексації під час вікна переключення.

7) Симптом: Випадкове 550 «User unknown» для валідних користувачів

Корінна причина: Карти одержувачів не завантажені, застарілі SQL креденшіали, або відмінності у регістрі; інколи відсутній домен у virtual_mailbox_domains.

Виправлення: Порівняйте старі/нові мапи Postfix і перезавантажте. Тестуйте запити напряму (SQL/LDAP) і перевірте списки доменів.

Три корпоративні міні‑історії (як йде неправильно і правильно)

Міні‑історія 1: Інцидент через неправильне припущення

Вони припустили, що зменшення TTL у MX означає «всі переключаться за п’ять хвилин». Це було охайне припущення, таке, яке робиш, коли переважно маєш справу з внутрішнім DNS і Kubernetes service discovery.

Переключення сталося о 19:00. Вони кинули MX, бачили, як вхідна пошта потрапляє на новий сервер, і оголосили перемогу. О 21:30 старший керівник переслав скаргу клієнта: «Ми надіслали терміновий контракт дві години тому. Ви його отримали?» Логи нового сервера нічого не показували. Логи старого — показували.

Виявилось, що кілька партнерських організацій використовували резолвери, що ігнорували новий TTL (або просто кешували стару відповідь). Ці відправники продовжували доставляти на старий MX. Тим часом команда вже налаштувала старий Postfix на «відхиляти все» з жорстким 5xx, бо хотіли примусити трафік на новий сервер. SMTP зробив свою роботу: відправники отримали негайні відмови. Деякі з цих відмов ніколи не повернулись людям, бо… так, їхня пошта під час цього також була в русі.

Виправлення не було екзотичним. Вони змінили старий сервер на тимчасові 4xx‑відтермінування, щоб відправники поставили у чергу й повторили спроби. Також додали контрольований релей зі старого на новий для кількох критичних IP партнерів. За день усе стабілізувалось.

Урок: не плутайте «TTL зменшено» з «інтернет виконув наказ». Для безпеки при переключенні тримайте старий сервер як шар сумісності принаймні на один повний цикл TTL плюс «люди, яким байдуже на TTL».

Міні‑історія 2: Оптимізація, що обернулась проти

Інша компанія вирішила прискорити міграцію, запустивши паралельні rsync‑заходи по доменах. Десять доменів — десять rsync одночасно. На дошці це виглядало ефективно, а в iostat — страшно.

Новий сервер мав швидкі CPU і «гідні» SSD, тому вони очікували, що він проковтне навантаження. Але міграції Maildir — це не великі послідовні записи; це мільйони створень дрібних файлів, оновлень метаданих і fsync‑бур. SSD почали показувати високу латентність, індекси Dovecot почали тайм‑аутитись, і доставки Postfix застопорилися, бо запис на диск був повільний.

Команда відповіла збільшенням паралелізму. Це класична помилка: трактувати проблеми зі сховищем як задачі, обмежені CPU. Латентність погіршилась. Сервер не впав; він просто так повільний, що клієнти повторювали підключення і підсилювали навантаження. Самостійно створений thundering herd.

Вони відновились, зробивши протилежне інстинкту: зменшили паралелізм rsync до одного процесу, увімкнули обмеження швидкості і запланували бульк‑синхронізацію поза робочим часом. Перенесли індекси Dovecot на швидкий NVMe, а основне сховище залишили на великому масиві. Нудна архітектура — раптом відмінно працює.

Урок: коли ви створюєте мільйони файлів, «швидше» часто означає «менш паралельно». Ваш вузький канал — I/O метаданих, не пропускна здатність мережі.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Одна організація мала політику: кожна міграція має включати письмовий план відкату і живу репетицію відкату для однієї скриньки. Людям це здавалося бюрократією. Це також стало причиною того, що вони спали спокійно.

Під час їхнього переміщення пошти вони помітили, що вихідна пошта з нового сервера періодично відтерміновується великим одержувачем. Вхід був у порядку. Користувачі читали пошту. Але вихід був повільним і створював квитки «чому не отримали мою пошту?»

Оскільки у них був план відкату, вони не панікували. Вони просто повернули submission‑трафік назад на старий сервер для виходу, залишивши вхід на новому. SPF вже авторизував обидва IP, DKIM ключі були узгоджені, а ім’я хоста для клієнтів не змінилося. Користувачі майже не помітили, крім того, що пошта знову пішла.

Протягом дня вони виправили проблему з доставкою: невідповідність зворотного DNS і надто суворе ім’я HELO. Потім обережно перевели вихід на новий сервер. Без героїзму. Без нічних «просто перезапустимо це» ритуалів.

Урок: найцінніша інженерна робота часто найбільш немодна. План відкату — це не песимізм; це компетентність.

FAQ

1) Чи справді можна виконати міграцію пошти з «нульовим простоєм»?

Ви можете наблизитися: мінімальні видимі переривання і відсутність втраченої пошти. Але ви не зупините кешування DNS і не гарантуєте поведінку кожного відправника. Плануйте коротке замороження і період співіснування.

2) Що перемикати першим: MX чи хост для IMAP/submission?

У більшості організацій: спочатку стабілізуйте IMAP/submission (те саме ім’я хоста, дійсний TLS), потім міняйте MX. Користувачі одразу помітять розрив IMAP; затримки вхідної SMTP часто терпіться, бо SMTP повторює спроби.

3) Чи безпечно використовувати rsync для Maildir?

В більшості випадків — так, якщо робити в два проходи і приймати, що конкурентні зміни можуть призвести до гонок. Для фінальної синхронізації чистіше зробити коротке замороження. Якщо у вас Dovecot з обох боків — dsync зазвичай безпечніший для узгодженості метаданих.

4) А як щодо mbox‑сховища?

Mbox під час конкурентних записів ризиковано копіювати rsync, бо можна зловити часткові записи або дивні стани блокувань. Віддавайте перевагу міграції на рівні застосунку або конвертуйте в Maildir за контрольованої процедури з простоєм.

5) Чи потрібно переносити індекси Dovecot?

Не обов’язково, але їх відтворення може спричинити високе I/O і повільний IMAP після переключення. Якщо можете безпечно перенести індекси і вони сумісні — це зменшить біль після переключення. Спочатку протестуйте.

6) Як обробляти пошту, що надходить на старий сервер після переключення?

Або відтерміновуйте її з 4xx, щоб відправники повторили спроби на новий MX, або тимчасово ретранслюйте вхід на новий сервер. Якщо ретранслюєте — впровадьте запобігання петель і обмежте час.

7) Варто зберегти той самий DKIM‑ключ чи його змінити?

Зберігайте той самий ключ/селектор під час міграції, якщо можете. Міняйте пізніше. Тиждень міграції — не час для одночасного «покращення гігієни безпеки», якщо вам не подобається комбінований ризик.

8) Як довго тримати старий сервер?

Щонайменше стільки, щоб покрити кеші DNS і будь‑які системи, що надсилають на старий хост. Зазвичай один‑два тижні для обережних організацій; коротше — якщо у вас повна видимість і контроль.

9) Яка найпоширеніша причина скарг «скринька порожня»?

Неправильні права/власність, неправильний mail_location або відображення авторизації, що спрямовує користувачів в інший шлях, ніж очікували. Менш часто: зміни UIDVALIDITY, що плутають клієнтів.

10) Як зрозуміти, що безпечно відновити великі TTL?

Коли логи показують мінімальну активність вхідної на старому сервері, вихід стабільний з нового IP і немає «відсталих» з’єднань клієнтів до старих кінцевих точок.

Наступні кроки (практично, а не мотиваційно)

1. Зменшіть TTL для MX та поштових хостів за 24–48 годин і перевірте через dig.
2. Побудуйте новий сервер, щоб відповідати старій поведінці: порти, TLS, авторизація, домени, фільтри, квоти.
3. Запустіть бульк‑синхронізацію, потім інкрементальну, і виміряйте дельти, щоб передбачити фінальне вікно.
4. Перевірте на реальних скриньках і проведіть сквозні SMTP/IMAP тести перед зміною DNS.
5. Переключайтесь з коротким замороженням, віддавайте перевагу 4xx‑відтермінуванням замість постійних відмов на старому сервері.
6. Моніторте як професіонал: черги, відмови автентифікації, латентність сховища та поведінку DKIM/SPF.
7. Зробіть відкат простим: старий сервер цілий, SPF тимчасово включає обидва IP, і нічого не видаляйте до тих пір, поки не пройде тиждень тиші.

Якщо ви виконаєте ці кроки, міграція стане приємно нудною. А нудність — найвища похвала, яку можна зробити поштовій системі.