Dovecot: Maildir проти mdbox — оберіть сховище, яке не підведе вас пізніше

Рішення, яке справді має значення

«Maildir vs mdbox» звучить як дебат про формат. Це не так. Це дебат про філософію експлуатації:

• Maildir ставить на карту семантику файлової системи: кожне повідомлення — окремий файл; атомарні перейменування — ваші друзі; корупція зазвичай локалізована; і ви отримуєте велику кількість інодів.
• mdbox ставить на карту агрегацію під управлінням Dovecot: повідомлення живуть у більших контейнерних файлах з метаданими Dovecot; ви зменшуєте тиск на іноди; операції можуть бути швидшими при певних IO-шаблонах; але помилка може зачепити значно більше.

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

Цитата, яку варто тримати на стікері, бо вона прямо застосовується до форматів поштових скриньок: «Надія — не стратегія.» — Gene Kranz.

Maildir і mdbox в одному огляді

Maildir: що це таке

Maildir зберігає кожне повідомлення як окремий файл у структурі директорій — зазвичай cur/, new/ та tmp/ для кожної скриньки. Прапорці часто кодуються у імені файлу. Доставка та переміщення покладаються на атомарність операцій перейменування.

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

mdbox: що це таке

mdbox зберігає повідомлення всередині «box» файлів, якими керує Dovecot (поряд з індексними та map-метаданими). Думайте про це як про те, що Dovecot бере на себе більшу частину шару зберігання: менше файлів, більше структури і більша залежність від гарантій консистентності Dovecot.

Операційний відчуттєвий ефект: Коли це швидко — приємно. Коли потрібно ремонтувати — хочете мати інструменти під рукою і перевірені резервні копії.

Що вам слід обрати (думка)

• Оберіть Maildir, якщо: ви невелика або середня організація, цінуєте простоту відновлення, маєте пристойні SSD, використовуєте снапшоти/резервні копії і хочете передбачувані домени відмов.
• Оберіть mdbox, якщо: у вас багато користувачів, багато повідомлень, реальний тиск на іноди, сканування директорій шкодить, або вам потрібні функції сховища, як-от ефективне зменшення кількості файлів — і ви готові експлуатувати обслуговування Dovecot і практику відновлення.
• Уникайте «не має значення» як рішення. Воно має значення в той день, коли вам потрібно відновити одну скриньку о 3:00 ранку, а ваш процес відновлення — «відновити все і молитися».

Жарт #1: Рішення про зберігання пошти як татуювання: здаються веселими, поки не спробуєте їх видалити під час квартального огляду відмов.

Факти та історія, що пояснюють сучасні компроміси

Трохи контексту робить компроміси менш довільними. Ось конкретні пункти, що пояснюють, чому ці формати існують і чому вони ведуть себе так, як ведуться:

1. Maildir створили, щоб уникнути проблем блокувань mbox. Традиційний mbox зберігав цілу скриньку в одному файлі; паралельний доступ історично викликав проблеми з блокуванням і ризиком корупції.
2. «Атомарний трюк перейменування» Maildir залежить від гарантій файлової системи. Шаблон tmp→new/cur опирається на атомарність в межах однієї файлової системи.
3. IMAP вибухнув у потребі метаданих для скриньок. Індексування, прапорці і відстеження UID стали критичними для продуктивності; індексні файли Dovecot — відповідь на цю реальність.
4. Накладні витрати дрібних файлів стали більшою проблемою зі зростанням зберігання пошти. Мільйони дрібних файлів виснажують іноди, пошуки в каталогах і інструменти резервного копіювання; цей тиск — одна з причин появи агрегованих форматів.
5. Dovecot ввів «box» формати, щоб зменшити навантаження на файлову систему. mdbox та подібні дизайни переносять частину роботи з файлової системи у структури під управлінням Dovecot.
6. Еволюція файлових систем має значення. Ext4, XFS, ZFS і btrfs по-різному працюють з каталогами та метаданими; один і той же формат може бути «ок» на одній файловій системі і болісним на іншій.
7. Снапшоти copy-on-write змінили очікування щодо резервного копіювання. З ZFS/btrfs зробити «консистентну точку в часі» легше — але тільки якщо ваші індекси та модель блокувань поводяться добре під снапшотом.
8. Клієнти пошти стали агресивнішими. Мобільні клієнти роблять часті синхронізації; очікують серверний пошук/FTS; формати поштових скриньок, що посилюють IO метаданих, можуть виглядати гіршими сьогодні, ніж у 2008 році.

Як кожен формат відмовляє в продакшні

Режими відмов Maildir

1) «Забагато файлів» стає справжнім інцидентом. Ви досягаєте виснаження інодів, резервні копії повільніють або сканування каталогів стає вашим підлогою затримок. Maildir не попереджає ввічливо; він просто стає повільним, а потім раптово неможливим.

2) Часткова корупція виживає — але не без витрат. Декілька файлів повідомлень можуть бути пошкоджені через проблеми диска або збої передач. Зазвичай решту можна врятувати. Але якщо індексні файли збиваються, клієнти бачать відсутні або дубльовані повідомлення, поки ви не перебудуєте індекси.

3) Резервні копії брешуть, якщо ви не використовуєте снапшоти. Резервне копіювання по файлах під час доставки може зафіксувати несумісний стан (повідомлення в tmp/, часткові перейменування). Це може працювати, але ви маєте розуміти, що «консистентно» означає для maildir.

Режими відмов mdbox

1) Консистентність метаданих стає вашим життям. mdbox покладається на метадані Dovecot (індекси, map-файли). Якщо вони несинхронні або пошкоджені, скринька може виглядати порожньою або переплутаною, навіть якщо базові box-файли існують.

2) Більша зона ураження на файл. Пошкоджений контейнерний файл може зачепити більше повідомлень. Інструменти Dovecot можуть ремонтувати в багатьох випадках, але ізоляція «один файл — одне повідомлення» у Maildir тут не працює за замовчуванням.

3) Складність відновлення зростає. Відновлення однієї скриньки може бути простим, якщо у вас є директорії на користувача та хороші інструменти. Але може стати хаосом, якщо у вас «один гігантський том і надія». Дизайн має значення.

Жарт #2: Найкращий формат поштової скриньки — той, який ви можете відновити, поки ваша кава ще придатна для пиття.

Модель продуктивності: за що ви насправді платите

Прихований податок у Maildir: метадані та операції з каталогами

Продуктивність Maildir визначається метаданими файлової системи: створення, перейменування, stat, перелік каталогів та оновлення часових міток. Якщо у вас SSD і файлова система, яка добре працює з каталогами, maildir може бути дуже швидким. Якщо у вас обертові диски або перевантажені шляхи метаданих, maildir може відчуватися так, ніби він робить усе, окрім доставки пошти.

Коли в користувачів сотні тисяч повідомлень в одній папці, maildir може різко деградувати, бо сервер робить багато операцій з каталогами, просто щоб відповісти «що нового?». Індекси Dovecot допомагають, але фактична кількість файлів все одно переслідує вас у резервних копіях, часі fsck і використанні інодів.

Прихований податок у mdbox: структури під управлінням Dovecot і процес ремонту

mdbox зменшує тиск на кількість файлів, що може зменшити накладні витрати на каталоги та іноди. Але ви платите іншим ресурсом: довірою і підтримкою метаданих Dovecot. Це означає, що ви піклуєтеся про цілісність індексів, здоров’я map-файлів і про те, як ваші резервні копії/відновлення взаємодіють з цими файлами.

На завантажених системах mdbox може бути дружнішим до файлової системи, але також може посилити наслідки «хитрого» тюнінгу чи небезпечних практик резервного копіювання.

Затримка проти пропускної здатності: обирайте те, що відчувають користувачі

Більшість поштових відмов — це не «сервер не витримує пропускну здатність». Це «вхід повільний», «відкриття INBOX повільне», «пошук повільний», «оновлення прапорців повільні». Це затримка. Затримка походить від кругових запитів до сховища і конкуренції за метадані.

Правило великого пальця: Якщо ваша біль — важка на метадані (кількість файлів, сканування каталогів, повзучі резервні копії), mdbox починає виглядати краще. Якщо ваша біль — простота ремонту та відновлення, Maildir важко перевершити.

Резервні копії, відновлення і чому «це просто файли» — пастка

Резервні копії Maildir: оманливо просто

Maildir виглядає як «просто файли», що змушує людей розслабитися. Не робіть цього. Жива maildir має транзитні стани (tmp/), перейменування і оновлення індексів. Якщо ви робите резервні копії без снапшотів, ви можете зафіксувати скриньку в середині операції.

Що працює добре:

• Снапшоти файлової системи (ZFS, btrfs, LVM thin snapshots) з читанням резервних копій зі снапшоту.
• Резервні копії, які зберігають права доступу, власника і часові мітки (доставка пошти і Dovecot чутливі до цього).
• Регулярні практики перебудови індексів під час тестів відновлення.

Резервні копії mdbox: вам потрібна консистентність, не просто копії

mdbox вимагає захоплення як box-файлів, так і метаданих/індексів в одній консистентній точці. Снапшот-орієнтовані резервні копії — розумна відправна база. Якщо ви покладаєтеся на копіювання файлу за файлом без снапшотів, ризикуєте зафіксувати невідповідні стани — box-файл каже одне, індекс — інше, map — третє.

Відновлення: плануйте «один користувач, одна папка, одне повідомлення»

Відновлення, яке має значення, — не «відновити весь сервер». Це «відновити одну папку скриньки для одного керівника, бо клієнт синхронізував і видалив усе». Це відновлення має бути рунбуком, а не героїчним імпровізаційним процесом.

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

Реальність реплікації/високої доступності

Формат скриньки не замінює стратегію реплікації. Він лише змінює режими відмов і зручність експлуатації.

Реплікація Dovecot і вибір формату

Dovecot може реплікувати поштові скриньки на рівні застосунку. Це може згладити деякі відмінності файлової системи. Але реплікація не виправить:

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

Снапшоти — не реплікація, реплікація — не резервне копіювання

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

Практичні завдання: команди, виводи і що ви вирішуєте

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

1) Підтвердити поточний формат скриньки

cr0x@server:~$ doveconf -n | egrep '^(mail_location|mail_attachment_dir|mail_plugins|namespace|mail_fsync)'
mail_location = maildir:~/Maildir
mail_plugins = $mail_plugins quota
mail_fsync = optimized

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

Рішення: Підлаштуйте налагодження під формат: тиск інодів і операції з каталогами важливіші для maildir; цілісність метаданих і map/index важливіші для mdbox.

2) Перевірити версію Dovecot (функції та баги мають значення)

cr0x@server:~$ dovecot --version
2.3.19.1 (9b53102964)

Значення: У вас сучасна 2.3.x. Поведінка відрізняється між мажорними/мінорними релізами, особливо щодо обробки індексів і налаштувань fsync за замовчуванням.

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

3) Виміряти використання інодів (мовчазний вбивця Maildir)

cr0x@server:~$ df -ih /var/vmail
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sdb1         50M   41M     9M   83% /var/vmail

Значення: 83% використання інодів. Це не «гарно». Це «один неправильний імпорт від простою».

Рішення: Якщо використання інодів зростає швидко, або (a) перейти на файлову систему з більшою кількістю інодів / іншою стратегією розподілу, (b) впровадити політики зберігання, (c) перемістити об’ємних користувачів в mdbox, або (d) переразробити структуру папок/архівування.

4) Порахувати файли повідомлень у «гарячій» папці

cr0x@server:~$ find /var/vmail/acme.example/jane/Maildir/cur -type f | wc -l
287641

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

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

5) Визначити, чи Dovecot проводить час у IO wait

cr0x@server:~$ iostat -x 1 3
Linux 6.1.0-18-amd64 (server) 	01/03/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.21    0.00    1.10   24.50    0.00   71.19

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         85.00  220.00  7400.0 14800.0     95.0     3.20   10.50     5.10    12.60   0.35  10.70

Значення: CPU iowait високий (24.5%). Сховище не завантажене (%util ~10%), але затримка (await) не надто добра. Часто це вказує на шаблони із синхронними записами або конкуренцію метаданих, а не на лінійний дефіцит пропускної здатності.

Рішення: Перевірте налаштування fsync, процеси Dovecot, що викликають «шторм» синхронізацій, і опції монтування файлової системи. Для maildir шаблони записів метаданих можуть створювати це навіть на SSD.

6) Подивитися, які процеси створюють IO-тиск

cr0x@server:~$ pidstat -d 1 5
Linux 6.1.0-18-amd64 (server) 	01/03/2026 	_x86_64_	(8 CPU)

# Time        UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
12:10:01     1001     23142      0.00   9200.00      0.00  dovecot
12:10:01     1001     23188      0.00   5100.00      0.00  dovecot
12:10:01        0     11422      0.00   1400.00      0.00  rsync

Значення: Dovecot багато пише (ймовірно, оновлення індексів, зміни прапорців, доставки). Є також rsync — класичний «резервне копіювання конкурує з живим IO».

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

7) Перевірити стан сервісів Dovecot і конкуренцію

cr0x@server:~$ doveadm service status
auth: client connections: 12, server connections: 12
imap: client connections: 380, server connections: 380
lmtp: client connections: 0, server connections: 0
indexer-worker: client connections: 8, server connections: 8

Значення: IMAP має 380 активних підключень. Працюють indexer worker-и. Якщо у вас недостатньо ресурсів для індексації, пошук і відкриття скриньок можуть тягнутися.

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

8) Виміряти затримку відкриття скриньки та статус (з перспективи Dovecot)

cr0x@server:~$ doveadm -v mailbox status -u jane@example.com messages recent uidnext unseen INBOX
INBOX messages=142003 recent=0 uidnext=412887 unseen=12

Значення: Ця команда має повертати швидко. Якщо вона затримується, у вас є IO-затримка, проблеми з індексом або конкуренція блокувань.

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

9) Виявити і безпечно перебудувати пошкоджені індекси

cr0x@server:~$ doveadm -Dv index -u jane@example.com INBOX
doveadm(jane@example.com): Debug: Loading modules from directory: /usr/lib/dovecot/modules
doveadm(jane@example.com): Debug: Added plugin: quota
doveadm(jane@example.com): Debug: Finished indexing INBOX

Значення: Dovecot може перебудувати індекси. Вивід debug підтверджує завантаження модулів і завершення індексації.

Рішення: Якщо це виправляє відсутні повідомлення в клієнтах, у вас була невідповідність індексів, а не втрата повідомлень. Додайте періодичне обслуговування індексів або виправте корінну причину (права, помилки диска, примусові скидання).

10) Шукати помилки на рівні файлової системи (бюрократична правда)

cr0x@server:~$ dmesg -T | egrep -i 'ext4|xfs|btrfs|zfs|nvme|i/o error|reset|abort' | tail -n 10
[Fri Jan  3 11:58:41 2026] nvme nvme0: I/O 123 QID 6 timeout, completion polled
[Fri Jan  3 11:58:41 2026] nvme nvme0: resetting controller
[Fri Jan  3 11:58:43 2026] EXT4-fs warning (device sdb1): ext4_dx_add_entry: Directory index full, reach max htree level

Значення: NVMe таймаути і попередження індексації директорій ext4. Це не проблема Dovecot. Це поведінка зберігання і файлової системи під навантаженням.

Рішення: Виправте апаратне/прошивкове забезпечення, перевірте здоров’я NVMe і розгляньте налаштування файлової системи або перенесення поштового сховища на FS, краще придатну для великих каталогів.

11) Підтвердити фактичне здоров’я диска (перед тим як звинувачувати формат)

cr0x@server:~$ smartctl -a /dev/nvme0 | egrep -i 'critical_warning|media_errors|num_err_log_entries|temperature'
Critical Warning:                   0x00
Temperature:                       41 Celsius
Media and Data Integrity Errors:    0
Error Information Log Entries:      2

Значення: Немає помилок медіа, але є записи журналу помилок. У поєднанні з NVMe скиданнями це може означати періодичні проблеми контролера/прошивки.

Рішення: Заплануйте технічне обслуговування: оновлення прошивки, перевірки контролера і розгляньте надмірність. Формати пошти не врятують від ненадійного апаратного забезпечення.

12) Перевірити розподіл директорій і файлів (виявити патологічні макети)

cr0x@server:~$ du -sh /var/vmail/acme.example/jane/Maildir
96G	/var/vmail/acme.example/jane/Maildir

Значення: 96 GB для одного користувача. Великий об’єм — це нормально, але велика кількість дрібних файлів змінює правила гри.

Рішення: Якщо невелика кількість користувачів домінує у сховищі і продуктивності, ставте їх як виняток: окремий шар сховища, mdbox або виділений том.

13) Перевірити опції монтування файлової системи (тут ховаються вбивці латентності)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /var/vmail
/var/vmail /dev/sdb1 ext4 rw,relatime,errors=remount-ro

Значення: Стандартні опції. Якщо ви бачите sync або надто агресивні налаштування журналювання, ви могли самі собі створити латентність.

Рішення: Уникайте сліпого копіювання опцій монтування. Вносьте зміни тільки з виміряними покращеннями латентності і планом відкату.

14) Для mdbox: знайти ключові метадані і перевірити ознаки базової цілісності

cr0x@server:~$ ls -la /var/vmail/acme.example/jane/mdbox/ | head
total 64
drwx------  5 vmail vmail 4096 Jan  3 12:01 .
drwx------ 12 vmail vmail 4096 Jan  3 12:01 ..
-rw-------  1 vmail vmail 8192 Jan  3 11:59 dovecot.index
-rw-------  1 vmail vmail 4096 Jan  3 11:59 dovecot.index.log
-rw-------  1 vmail vmail 2048 Jan  3 12:00 dovecot.map.index
-rw-------  1 vmail vmail 4096 Jan  3 11:58 storage

Значення: Присутність індексних і map-файлів очікувана. Відсутні або нульового розміру файли під час нормальної роботи можуть індикувати корупцію або проблеми з правами.

Рішення: Якщо вони відсутні або недоступні для читання — спочатку виправте права/власність; якщо підозрюєте корупцію — переходьте до відновлення зі снапшоту або робочих процесів ремонту Dovecot.

15) Спостерігати активну конкуренцію блокувань файлів скриньки

cr0x@server:~$ lsof +D /var/vmail/acme.example/jane/Maildir 2>/dev/null | head -n 10
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
dovecot 23142 vmail   15r  REG  8,17     12456 918273 /var/vmail/acme.example/jane/Maildir/dovecot.index
dovecot 23142 vmail   16u  REG  8,17     40960 918274 /var/vmail/acme.example/jane/Maildir/dovecot.index.log
dovecot 23188 vmail   18r  REG  8,17     53248 918275 /var/vmail/acme.example/jane/Maildir/cur/1735891023.M1234P23188.server,S=53248:2,S

Значення: Ви бачите, які файли «гарячі». Якщо багато процесів змагаються за індексні/лог-файли, у вас може бути навантаження, що постійно збиває прапорці або примушує перезапис індексу.

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

Швидкий план діагностики

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

Перш за все: доведіть, чи це латентність сховища, CPU або конкуренція Dovecot

• IO wait і латентність: iostat -x 1 3 і pidstat -d 1 5. Високий iowait або await вказує на сховище або шаблони синхронізації.
• Навантаження CPU: top або pidstat -u 1 5. Якщо CPU завантажений, ви не обираєте між maildir і mdbox — ви обираєте між масштабуванням і переписуванням.
• Тиск підключень: doveadm service status. Якщо IMAP-з’єднання стрибають і процеси голодують, налаштуйте ліміти процесів і поведінку клієнтів.

По-друге: визначте, чи проблема — «метадані файлової системи», чи «метадані Dovecot»

• Підозри Maildir: використання інодів (df -ih), величезні підрахунки файлів у папці (find ... | wc -l), попередження ext4 в dmesg.
• Підозри mdbox: відсутні/некоректні dovecot.map.index і інтенсивний лог індексації, повільні запити статусу попри адекватні метрики сховища.

По-третє: перевірте, чи проблема локалізована або системна

• Запустіть doveadm mailbox status для одного «гарячого» і одного «нормального» користувача.
• Якщо лише кілька користувачів повільні — обробляйте їх як особливі випадки (архівування, розбиття скриньки, інший формат, інший том).
• Якщо всі повільні — підозрюйте сховище, глобальні індексери, резервні копії або недавні зміни в монтуванні/ядрі/прошивці.

По-четверте: оберіть найменш ризикову корекцію

• Перебудова індексів (безпечно і відкатно).
• Зупинити конкуренцію IO (резервні копії, антивірусні сканування, агресивне відпилювання логів).
• Виправити помилки файлової системи/апаратні проблеми перед тюнінгом Dovecot.
• Тільки потім розглядати міграцію між форматами.

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

1) «IMAP-вхід повільний, але завантаження диска низьке»

Симптоми: Користувачі повідомляють про затримки при відкритті папок; моніторинг показує низьке %util на дисках.

Корінь: Висока затримка на операцію (метадані IO, синхронні записи, пошуки в каталогах). Низьке використання не означає низьку затримку.

Виправлення: Виміряйте await за допомогою iostat -x. Якщо затримка висока, зменшіть синхронно-важкі поведінки, перемістіть резервні копії з живої FS і розгляньте mdbox, якщо домінує тиск інодів/каталогів.

2) «Резервні копії консистентні, бо ми використовуємо rsync вночі»

Симптоми: Відновлення дає дивні скриньки: відсутні недавні повідомлення, дублікати або клієнти запускають шалені синхронізації.

Корінь: Копіювання файл за файлом захопило maildir/mdbox під час оновлення; індекси і повідомлення з різних точок в часі.

Виправлення: Резервне копіювання через снапшоти. Відновлюйте зі снапшоту. Перебудуйте індекси після відновлення за допомогою doveadm index або обережно видаляючи застарілі індексні файли.

3) «Ми поклали все в одну масивну INBOX»

Симптоми: Один або два користувачі постійно повільні; вікна резервних копій вибухають; з’являються попередження файлової системи.

Корінь: Великі папки підсилюють витрати на перелік і метадані (maildir) або накладні витрати на індексацію (будь-який формат).

Виправлення: Впровадіть політики архівування і структурування папок. Розгляньте серверні правила Sieve. Розділіть «гарячі» скриньки по шарах зберігання.

4) «Ми мігрували формати і не спланували перехід індексів»

Симптоми: Після міграції клієнти бачать відсутні повідомлення поки не синхронізують; навантаження сервера зростає.

Корінь: Індекси не були чисто перебудовані або відновлені неконсистентно; клієнти викликають інтенсивну синхронізацію.

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

5) «Ми відключили fsync заради продуктивності»

Симптоми: Продуктивність покращилась… поки не стався збій або відключення живлення; тоді користувачі втрачають оновлення прапорців, недавні доставки або бачать корумпований стан.

Корінь: Небезпечні налаштування стійкості. Зберігання пошти інтенсивно пише метадані; втрата кількох секунд може створити заплутані невідповідності.

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

6) «Антивірус сканує весь поштовий магазин кожну годину»

Симптоми: Періодичні сплески латентності; багато пропусків кешу; IO-сплески; користувачі скаржаться хвилеподібно.

Корінь: Багато файлів Maildir карає за повні дерева сканування; навіть mdbox страждає, якщо сканування витрашає кеші.

Виправлення: Сканувати при прийомі (LMTP/SMTP pipeline) або використовувати цілеспрямоване сканування. Виключайте індекси і тимчасові папки з широких сканів, де це доречно.

7) «Ми вважали, що файлова система не має значення»

Симптоми: Одна і та сама конфігурація поводиться по-різному на різних хостах; оновлення «випадково» змінюють продуктивність.

Корінь: Індексація каталогів, поведінка аллокатора і журналювання залежать від файлової системи і версії ядра.

Виправлення: Стандартизуйте вибір файлової системи і опції монтування для поштових томів. Бенчмаркуйте операції зі скриньками, а не лише послідовну пропускну здатність.

Три корпоративні міні-історії (анонімізовані, правдоподібні та повчальні)

Міні-історія 1: Аварія, спричинена хибним припущенням

Вони керували середньою платформою пошти. Нічого екзотичного: Dovecot, Postfix, кластер віртуальних машин і «тимчасовий» том сховища, який став постійним. Новий член команди запитав, який формат скриньки вони використовують. Відповідь була впевненою і хибною: «Це Maildir, тож це просто файли. Резервні копії прості».

Резервне завдання було нічним копіюванням по дереву файлів. Без снапшотів. Завдання працювало під час доставок і іноді в піковий час мобільної синхронізації. Воно «працювало» у тому сенсі, що створювало купу файлів. Також воно захоплювало транзитні стани: повідомлення в tmp, перейменування напівзавершені, індексні логи в середині оновлення.

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

Корінь проблеми не був у Maildir. Корінь був у припущенні, що файлове резервне копіювання рівнозначне консистентному. Вони перейшли на снапшот-орієнтовані резервні копії і додали тренування відновлення, яке включало перебудову індексів і поетапне підключення клієнтів. Наступне відновлення було нудним. Всім стало менше боляче. Оце і показник успіху.

Міні-історія 2: Оптимізація, що відштовхнулася

Інша компанія мала серйозний тиск інодів. Вони перейшли на mdbox, щоб зменшити кількість файлів і скоротити час сканування резервних копій. Добре обґрунтоване рішення. Потім вони вирішили додатково підтиснути продуктивність, зменшивши налаштування стійкості: знизили синхронізацію і посилили кешування записів. Виглядало чудово в бенчмарках. Графіки стали гарніші.

Потім сталася подія живлення в одному стійці. Не катастрофа, просто кілька хвилин хаосу. Системи перезавантажилися. Більшість сервісів відновилися. Пошта — ні. Користувачі могли входити, але нові листи з’являлися неконсистентно, а прапорці поводилися як рекомендації. Деяка пошта існувала в box-файлах, але не відображалася в IMAP, поки індекси не були відремонтовані. Деякі ремонти спрацювали; інші вимагали відновлення метаданих зі снапшотів.

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

Вони відкотили ризикові налаштування, інвестували в захист від втрати живлення для сховища і стандартизували підхід snapshot+replication. Продуктивність стала трохи гірша за фантазію бенчмарків. Доступність була кращою за реальність відмов. Обирайте реальність.

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

Регульована організація експлуатувала Dovecot в масштабі. Їхнє сховище було настільки велике, що «відновити все» не було планом; це було прощальним листом. Вони використовували Maildir для більшості користувачів і mdbox для підмножини облікових записів з великим об’ємом. Ключем були не формати — ключем була дисципліна.

Вони практикували відновлення щоквартально. Не «ми тестували резервні копії». Справжні відновлення: вибрати випадкову скриньку, відновити її на ізольований хост, перебудувати індекси, перевірити доступ по IMAP і звірити кількість повідомлень і недавні доставки. Вони також мали політику: робити снапшоти кожні кілька хвилин, тримати короткий локальний ретеншн, реплікувати снапшоти поза вузлом і тестувати шлях відновлення наскрізь.

Коли контролер сховища почав давати збої, вони побачили це рано в dmesg і SMART. Перш ніж сталося відновлення даних, вони відключили поштовий сервіс на репліку і продовжили обслуговувати користувачів. Потім вони відновили декілька уражених скриньок з останнього відомо-робочого снапшоту і перевірили їх інструментами Dovecot перед поверненням у виробничу роботу.

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

Контрольні списки / покроковий план

Вибір формату: контрольний список рішень

1. Скільки повідомлень на користувача? Якщо багато користувачів мають понад 200k повідомлень у папці, Maildir покарає вашу файлову систему, якщо ви не керуєте розбиттям папок.
2. Чи обмежені ви інодами? Якщо df -ih показує тенденцію вище 70% і зростає, сприймайте це як проблему масштабування, а не попереджувальний знак.
3. Чи є у вас резервні копії на основі снапшотів? Якщо ні — виправте це перед змінюваністю формату. Інакше ви просто змінимо характер невідповідностей резервних копій.
4. Чи потрібне вам просте часткове відновлення? Maildir зазвичай дружніший для хірургічного відновлення. mdbox може бути придатний, але вам потрібні відпрацьовані інструменти і процеси.
5. Яка у вас файлова система? Бенчмаркуйте операції зі скриньками на реальній файловій системі і ядрі, на якому ви працюватимете. Поштові навантаження важко передбачувані і метадані-важкі.
6. Чи є у вас час персоналу на обслуговування? Якщо ні — оберіть шлях з найпростішими day-2 операціями: Maildir плюс хороше снапшотування.

План міграції: Maildir → mdbox (відносно безпечна послідовність)

1. Проведіть інвентар користувачів і визначте «гарячі» скриньки (великі папки, висока текучість).
2. Впровадьте резервні копії на основі снапшотів і проведіть відновлення до тестового зразка перед міграцією.
3. Налаштуйте стендовий сервер з цільовою версією Dovecot і конфігурацією.
4. Мігруйте маленьку пілотну групу першою. Моніторте затримку IMAP, час перебудови індексів і видимі проблеми для користувачів.
5. Плануйте міграції у непіковий час. Обмежуйте конкурентність. Не мігруйте всіх одразу, якщо вам не до вподоби ризик.
6. Після кожної партії: перебудуйте індекси, звірте кількість повідомлень і стежте за хвилями клієнтських синхронізацій.
7. Майте можливість відкотитися через снапшоти і чіткий маркер cutover.

Операційний базовий набір (незалежно від формату)

• Резервні копії на основі снапшотів з перевіреними відновленнями.
• Моніторинг використання інодів, росту каталогів і обсягу пошти.
• Моніторинг латентності сховища (await) і помилок ядра щодо зберігання.
• Визначені процедури для перебудови індексів і ремонту скриньок.
• Контроль поведінки клієнтів, де це можливо (агресивні схеми синхронізації можуть вас DOS-ити).

Часті запитання

1) Чи Maildir завжди безпечніший за mdbox?

Ні. Maildir часто має меншу зону ураження при пошкодженні окремого файлу, але може драматично падати через виснаження інодів і накладні витрати на метадані. «Безпечніший» залежить від того, що саме ви, ймовірно, зіпсуєте.

2) Чи mdbox завжди швидший?

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

3) Яка основна причина, чому Maildir-системи з часом повільнішають?

Зростання кількості файлів плюс операції метаданих. Система не сповільнюється лінійно; вона починає страждати, коли каталоги стають величезними, резервні копії повзуть, а використання інодів наближається до обриву.

4) Яка основна причина, чому mdbox-системи стають болючими?

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

5) Чи варто зберігати пошту на NFS?

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

6) Чи можна змішувати формати на одному хості?

Так, і інколи це прагматично: тримайте більшість користувачів на Maildir і перемістіть облікові записи з великим об’ємом в mdbox. Просто переконайтеся, що ваші оперативні інструменти покривають обидва варіанти.

7) Чи замінюють снапшоти реплікацію Dovecot?

Ні. Снапшоти допомагають повернутися назад і відновити стан. Реплікація допомагає залишатися доступним. Вони вирішують різні проблеми і відмовляють по-різному.

8) Як зрозуміти, чи це корупція індексів чи реальна втрата повідомлень?

Порівняйте реальність файлової системи з видом IMAP. Якщо повідомлення існують на диску (файли maildir або storage у mdbox), але не відображаються — перебудуйте індекси. Якщо їх нема на диску — це втрата, і потрібні відновлення.

9) Яке «мінімально життєздатне» обслуговування для здорового шару зберігання Dovecot?

Резервні копії на основі снапшотів, періодичні відновлення, моніторинг використання інодів і латентності сховища, а також рунбук для перебудови індексів/ремонту. Все інше — оптимізація.

Наступні кроки, які ви можете зробити цього тижня

1. Запустіть базові перевірки: doveconf -n, df -ih, iostat -x і doveadm mailbox status для «гарячого» користувача. Запишіть, що насправді правда.
2. Перевірте консистентність резервних копій: Якщо ви не робите снапшоти, вважайте свої резервні копії «кращими зусиллями», а не відновленням, на яке можна покластися.
3. Зробіть одне відновлення-тренування: Виберіть одну скриньку, відновіть її в ізольованому середовищі, перебудуйте індекси, перевірте IMAP. Заміряйте час. Задокументуйте процес.
4. Визначте «кліф зростання»: Іноди, величезні папки і латентність сховища — три великі проблеми. Встановіть оповіщення для них.
5. Приймайте рішення свідомо: Якщо ваша біль — тиск інодів і накладні витрати метаданих, mdbox може бути рішенням. Якщо ваша біль — відновлюваність і простота операцій, лишайтеся на Maildir і масштабируйте файлову систему та підхід до резервного копіювання правильно.

Оберіть формат, що відповідає вашому бюджету відмов і вашій реальності відновлення. Ваше майбутнє «я» буде тим, хто на виклику. Не жартуйте над ним.