Dovecot : maildir vs mdbox — choisissez un stockage qui ne vous hantera pas plus tard

La décision qui compte vraiment

« Maildir vs mdbox » ressemble à un débat de formats. Ce n’en est pas un. C’est un débat de philosophie opérationnelle :

• Maildir mise sur les sémantiques du système de fichiers : chaque message est un fichier distinct ; les renommages atomiques sont vos amis ; la corruption tend à être localisée ; et vous avez beaucoup d’inodes.
• mdbox mise sur l’agrégation gérée par Dovecot : les messages vivent dans de plus gros fichiers conteneurs avec des métadonnées Dovecot ; vous réduisez la pression sur les inodes ; certaines opérations peuvent être plus rapides selon les patterns d’E/S ; et quand vous faites une erreur, l’impact peut être plus vaste.

Si vous gérez un petit serveur avec un système de fichiers sain et que vous voulez un débogage simple et une restauration partielle facile, Maildir est le choix par défaut qui vieillit bien. Si vous opérez à grande échelle où le nombre d’inodes, le scan de répertoires et le coût des petits fichiers vous tuent, mdbox peut être la bonne douleur—mais seulement si vous êtes disciplinés concernant les sauvegardes, la maintenance et les outils opérationnels.

Une citation à garder sur un post-it, parce qu’elle s’applique directement aux formats de boîte aux lettres : « L’espoir n’est pas une stratégie. » — Gene Kranz.

Maildir et mdbox en un coup d’œil

Maildir : qu’est-ce que c’est

Maildir stocke chaque message comme un fichier séparé dans une structure de répertoires—typiquement cur/, new/ et tmp/ par boîte aux lettres. Les flags sont souvent encodés dans le nom de fichier. La livraison et les déplacements reposent sur le comportement de renommage atomique.

Ambiance opérationnelle : Quand quelque chose casse, vous pouvez souvent ouvrir un répertoire et voir les messages. Vous pouvez récupérer un seul utilisateur sans avoir l’impression de désamorcer une bombe.

mdbox : qu’est-ce que c’est

mdbox stocke les messages à l’intérieur de fichiers « box » gérés par Dovecot (avec des métadonnées d’index et de map associées). Pensez à Dovecot contrôlant davantage la couche de stockage : moins de fichiers, plus de structure, et plus de dépendance aux garanties de cohérence de Dovecot.

Ambiance opérationnelle : Quand c’est rapide, c’est agréable. Quand il faut réparer, vous voulez vos outils prêts et vos sauvegardes vérifiées.

Ce que vous devriez choisir (opinion)

• Choisissez Maildir si : vous êtes une petite à moyenne structure, vous valorisez la simplicité de récupération, vous avez des SSD décents, vous utilisez des snapshots/sauvegardes, et vous voulez des domaines de panne prévisibles.
• Choisissez mdbox si : vous avez beaucoup d’utilisateurs, beaucoup de messages, la pression sur les inodes est réelle, le coût de listing des répertoires est pénalisant, ou vous avez besoin de fonctionnalités de stockage comme un comptage de fichiers efficace—et vous êtes prêt à industrialiser la maintenance Dovecot et les drills de sauvegarde/restauration.
• Évitez « ça n’a pas d’importance » comme décision. Ça compte le jour où vous devez restaurer une seule boîte à 3 h du matin et que votre processus de restauration se résume à « tout restaurer et prier ».

Blague #1 : Les décisions de stockage de mail sont comme les tatouages : ça semble amusant jusqu’à ce que vous essayiez de les enlever pendant la revue trimestrielle des incidents.

Faits et historique qui expliquent les compromis actuels

Un peu de contexte rend les compromis moins arbitraires. Voici des points concrets qui montrent pourquoi ces formats existent et pourquoi ils se comportent comme ils le font :

1. Maildir a été conçu pour éviter les problèmes de verrouillage d’mbox. Le mbox traditionnel stocke une boîte entière dans un seul fichier ; l’accès concurrent causait historiquement des douleurs de verrouillage et un risque de corruption.
2. Le « renommage atomique » de Maildir dépend des garanties du système de fichiers. Le schéma tmp→new/cur repose sur l’atomicité au sein du même filesystem.
3. L’IMAP a multiplié les besoins en « métadonnées » de boîte. L’indexation, les flags et le suivi des UID sont devenus critiques pour la performance ; les fichiers d’index de Dovecot sont une réponse à cette réalité.
4. Le coût des petits fichiers est devenu plus important à mesure que la rétention a grandi. Des millions de petits fichiers sollicitent les inodes, les recherches de répertoire et les outils de sauvegarde ; cette pression est une des raisons des formats agrégés.
5. Dovecot a introduit des formats « box » pour réduire l’agitation du système de fichiers. mdbox et des designs similaires déplacent le travail du système de fichiers vers des structures gérées par Dovecot.
6. L’évolution des systèmes de fichiers compte. Ext4, XFS, ZFS et btrfs gèrent différemment les répertoires et les métadonnées ; le même format peut être « acceptable » sur l’un et pénible sur l’autre.
7. Les snapshots copy-on-write ont changé les attentes de sauvegarde. Avec les snapshots ZFS/btrfs, le « point dans le temps cohérent » est plus facile—mais seulement si votre modèle d’indexation et de verrouillage se comporte bien avec les snapshots.
8. Les clients mail sont devenus plus agressifs. Les clients mobiles font des synchronisations fréquentes ; la recherche côté serveur/FTS est devenue attendue ; les formats de boîte qui amplifient les E/S de métadonnées peuvent sembler pires aujourd’hui qu’en 2008.

Comment chaque format échoue en production

Modes d’échec de Maildir

1) « Trop de fichiers » devient une vraie panne. Vous atteignez l’épuisement des inodes, les sauvegardes ralentissent, ou les scans de répertoire deviennent votre plancher de latence. Maildir ne vous prévient pas poliment ; il devient juste lent puis soudainement impossible.

2) La corruption partielle est survivable—mais coûteuse. Quelques fichiers message peuvent être corrompus par des problèmes de disque ou des transferts cassés. En général vous pouvez sauver le reste. Mais si vos fichiers d’index deviennent bizarres, les clients verront des messages manquants ou dupliqués jusqu’à ce que vous reconstruisiez les index.

3) Les sauvegardes mentent si vous ne faites pas de snapshot. Une sauvegarde fichier par fichier pendant que des livraisons sont en cours peut capturer des états incohérents (messages dans tmp/, renommages partiels). Ça peut toujours fonctionner, mais vous devez comprendre ce que « cohérent » signifie pour maildir.

Modes d’échec de mdbox

1) La cohérence des métadonnées devient votre vie. mdbox s’appuie sur les métadonnées Dovecot (indexes, fichiers map). Si celles-ci sont désynchronisées ou corrompues, la boîte peut sembler vide ou brouillée même si les fichiers box sous-jacents existent.

2) Rayon d’impact plus large par fichier. Un fichier conteneur corrompu peut affecter plus de messages. Les outils Dovecot peuvent réparer dans de nombreux cas, mais l’isolation « fichier par message » de Maildir n’est pas la valeur par défaut ici.

3) La complexité de restauration augmente. Restaurer une seule boîte peut être simple si vous avez des répertoires par utilisateur et de bons outils. Ça peut aussi être un cauchemar si vous avez fait « un volume géant et on verra bien ». La conception compte.

Blague #2 : Le meilleur format de boîte aux lettres est celui que vous pouvez restaurer pendant que votre café est encore buvable.

Modèle de performance : ce que vous payez vraiment

La taxe cachée de Maildir : métadonnées et opérations sur les répertoires

La performance de Maildir est dominée par les métadonnées du système de fichiers : création, renommage, stat, listing de répertoires et mise à jour des timestamps. Si vous avez des SSD et un système de fichiers qui gère bien les répertoires, maildir peut être très rapide. Si vous avez des disques rotatifs ou des chemins de métadonnées surchargés, maildir peut donner l’impression de tout faire sauf servir le courrier.

Quand les utilisateurs ont des centaines de milliers de messages dans un seul dossier, Maildir peut se dégrader fortement parce que le serveur effectue beaucoup d’opérations de répertoire juste pour répondre à « quoi de neuf ? » Les index Dovecot aident, mais le nombre de fichiers sous-jacent vous poursuit encore dans les sauvegardes, le temps de fsck et l’utilisation des inodes.

La taxe cachée de mdbox : structures gérées par Dovecot et flux de réparation

mdbox tend à réduire la pression sur le nombre de fichiers, ce qui peut diminuer le coût des répertoires et des inodes. Mais vous payez dans une autre devise : vous devez faire confiance et maintenir les structures de métadonnées de Dovecot. Cela signifie que vous vous souciez de l’intégrité des index, de la santé des fichiers map et de la façon dont vos sauvegardes/restaurations interagissent avec ces fichiers.

Sur les systèmes chargés, mdbox peut être plus amical au filesystem, mais il peut aussi amplifier les conséquences des réglages « astucieux » ou des pratiques de sauvegarde non sûres.

Latence vs débit : choisissez ce que vos utilisateurs ressentent

La plupart des pannes mail ne sont pas « le serveur ne peut pas gérer le débit ». Elles sont « la connexion est lente », « l’ouverture de INBOX est lente », « la recherche est lente », « la mise à jour des flags est lente ». C’est de la latence. La latence vient des allers-retours de stockage et de la contention sur les métadonnées.

Règle empirique : Si votre douleur est axée sur les métadonnées (nombre de fichiers, scans de répertoire, crawling des sauvegardes), mdbox commence à sembler meilleur. Si votre douleur est la simplicité de réparation et de récupération, Maildir est difficile à battre.

Sauvegardes, restaurations, et pourquoi « ce n’est que des fichiers » est un piège

Sauvegardes Maildir : trompeusement simples

Maildir ressemble à « juste des fichiers », ce qui détend les gens. Ne le soyez pas. Maildir en production a des états transitoires (tmp/), des renommages et des mises à jour d’index. Si vous le sauvegardez sans snapshots, vous pouvez capturer une boîte en plein vol.

Ce qui fonctionne bien :

• Snapshots de filesystem (ZFS, btrfs, LVM thin snapshots) en lisant la sauvegarde depuis le snapshot.
• Sauvegardes qui préservent permissions, propriété et timestamps (la livraison de mail et Dovecot y sont sensibles).
• Pratiques régulières de reconstruction d’index lors des tests de restauration.

Sauvegardes mdbox : vous avez besoin de cohérence, pas de simples copies

mdbox exige que vous capturiez à la fois les fichiers box et les fichiers de métadonnées/index à un point dans le temps cohérent. Les sauvegardes par snapshot sont la base saine. Si vous comptez sur une copie fichier par fichier sans snapshots, vous risquez de capturer des états désaccordés—le fichier box dit une chose, l’index une autre, la map une troisième.

Restaurations : planifiez pour « un utilisateur, un dossier, un message »

La restauration qui compte n’est pas « restaurer tout le serveur ». C’est « restaurer un dossier de boîte pour un cadre parce qu’un client a synchronisé et tout supprimé ». Cette restauration devrait être un runbook, pas de l’improvisation héroïque.

Si vous ne pouvez pas restaurer une seule boîte sans tout restaurer, vous n’avez pas choisi un format de stockage ; vous avez choisi un incident futur.

Réalité de la réplication/HA

Le format de boîte ne remplace pas la stratégie de réplication. Il change juste les modes d’échec et l’ergonomie opérationnelle.

Réplication Dovecot et choix de format

Dovecot peut répliquer des boîtes au niveau applicatif. Cela peut lisser certaines différences de filesystem. Mais la réplication ne corrige pas :

• La mauvaise planification de capacité (l’épuisement des inodes arrive toujours, juste sur deux machines).
• Le stockage lent (vous avez maintenant du stockage lent plus la surcharge de réplication).
• Les pratiques de sauvegarde non sûres (la réplication répliquera volontiers des suppressions et certaines formes de corruption).

Les snapshots ne sont pas la réplication, la réplication n’est pas une sauvegarde

Les snapshots offrent une récupération à un point dans le temps ; la réplication offre de la disponibilité. Vous voulez les deux si le système mail compte. Si vous ne pouvez en permettre qu’un, choisissez des sauvegardes que vous avez testées. La disponibilité sans récupération n’est qu’un moyen plus rapide de rester en panne.

Tâches pratiques : commandes, sorties et ce que vous décidez

Voici les vérifications que j’exécute réellement quand quelqu’un dit « IMAP est lent », « des messages ont disparu » ou « le disque est OK, mais le mail meurt ». Chaque tâche inclut ce que la sortie signifie et la décision que vous prenez.

1) Confirmer le format de boîte actuel

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

Sens : Ce serveur utilise maildir dans le répertoire personnel de chaque utilisateur. Si vous attendiez mdbox, vos « hypothèses de performance » sont déjà fausses.

Décision : Alignez le dépannage selon le format : la pression sur les inodes et les opérations de répertoire comptent plus avec Maildir ; l’intégrité des métadonnées et des map/index compte plus avec mdbox.

2) Vérifier la version de Dovecot (les fonctionnalités et bugs comptent)

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

Sens : Vous êtes sur une 2.3.x moderne. Le comportement diffère selon les versions majeures/minores, notamment autour de la gestion des index et des valeurs par défaut de fsync.

Décision : Si vous êtes sur quelque chose d’ancien, envisagez une mise à jour avant des réglages « astucieux ». Les vieux bugs de stockage mail ne sont pas charmants.

3) Mesurer l’utilisation des inodes (le tueur silencieux de Maildir)

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

Sens : 83 % d’utilisation des inodes. Ce n’est pas « acceptable ». C’est « une importation ratée loin d’un arrêt ».

Décision : Si l’utilisation des inodes augmente rapidement, soit : (a) migrez vers un système de fichiers avec plus d’inodes / une stratégie d’allocation différente, (b) appliquez la rétention, (c) migrez les utilisateurs à fort volume vers mdbox, ou (d) repensez le découpage des dossiers/archivage.

4) Compter les fichiers messages dans un dossier chaud

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

Sens : 287k fichiers dans un seul répertoire. Beaucoup de systèmes de fichiers gèrent mal cela sous churn, même si les lectures sont en cache.

Décision : Envisagez un partitionnement des dossiers (archives par année), des changements de politique côté client, ou la migration de cet utilisateur vers mdbox si le coût opérationnel est récurrent.

5) Identifier si Dovecot passe du temps en 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

Sens : Le iowait CPU est élevé (24,5 %). Le stockage n’est pas saturé (%util ~10 %), mais la latence (await) n’est pas bonne. Cela pointe souvent vers des patterns riches en sync ou une contention des métadonnées plutôt que des limites de débit brut.

Décision : Vérifiez les paramètres fsync, les processus Dovecot provoquant des vagues de sync, et les options de montage du système de fichiers. Pour Maildir, les patterns d’écriture des métadonnées peuvent provoquer cela même sur SSD.

6) Voir quels processus causent la pression 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

Sens : Dovecot écrit beaucoup (probablement des mises à jour d’index, des changements de flags, des livraisons). Il y a aussi un rsync en cours—classique « sauvegarde qui concurrence les E/S live ».

Décision : Si vous n’avez pas de snapshots, arrêtez les sauvegardes qui parcourent les fichiers pendant les pics. Passez aux snapshots pour les sauvegardes ou planifiez rsync en dehors des heures de pointe, ou limitez son débit.

7) Vérifier la santé du service Dovecot et la concurrence

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

Sens : IMAP a 380 connexions actives. Les workers d’indexation sont actifs. Si vous êtes sous-approvisionné en indexers, les recherches et l’ouverture de boîtes peuvent traîner.

Décision : Ajustez les limites de processus avec responsabilité. Si les indexers sont saturés, augmentez le nombre de workers ou corrigez la cause (par ex. reconstruction d’index constante due à des permissions incorrectes ou caches cassés).

8) Mesurer la latence d’ouverture de boîte et de status (depuis 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

Sens : Cette commande doit revenir rapidement. Si elle bloque, vous avez de la latence IO, des problèmes d’index ou de la contention de verrouillage.

Décision : Si c’est lent : vérifiez la corruption d’index, des scans de filesystem coûteux, ou un stockage bloqué. Pour Maildir avec un INBOX énorme, encouragez l’archivage.

9) Identifier et reconstruire les fichiers d’index cassés en toute sécurité

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

Sens : Dovecot peut reconstruire les index. La sortie de debug confirme le chargement des modules et la fin de l’indexation.

Décision : Si cela corrige les messages manquants chez les clients, vous aviez une incohérence d’index plutôt qu’une perte de message. Ajoutez une maintenance d’index périodique ou réglez la cause racine (permissions, erreurs disque, resets forcés).

10) Chercher des erreurs au niveau du filesystem (le sérum de vérité ennuyeux)

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

Sens : Timeouts NVMe et un avertissement d’indexation de répertoire ext4. Ce n’est pas un problème Dovecot. C’est le stockage et le comportement du filesystem sous stress.

Décision : Corrigez le matériel/firmware, vérifiez la santé NVMe, et envisagez un tuning du système de fichiers ou de déplacer le stockage mail vers un filesystem mieux adapté aux gros répertoires.

11) Confirmer la santé réelle du disque (avant d’accuser le format de mail)

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

Sens : Pas d’erreurs média, mais il y a des entrées de log d’erreur. Combiné aux resets NVMe, vous pouvez avoir des problèmes intermittents de contrôleur/firmware.

Décision : Planifiez de la maintenance : mises à jour de firmware, vérifications du contrôleur, et considérez la redondance. Les formats de mail ne vous sauveront pas d’un matériel instable.

12) Vérifier la distribution des répertoires et fichiers (repérer des layouts pathologiques)

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

Sens : 96 GB pour un seul utilisateur. Le volume est acceptable, mais grand + beaucoup de petits fichiers change tout.

Décision : Si une poignée d’utilisateurs domine le stockage et la performance, traitez-les spécialement : tier de stockage séparé, mdbox, ou volume dédié.

13) Vérifier les options de montage du filesystem (les tueurs de latence se cachent ici)

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

Sens : Options standard. Si vous voyez sync ou des réglages de journalisation extrêmement agressifs, vous pourriez vous être infligé de la latence.

Décision : Évitez les changements d’options de montage par mimétisme. Modifiez uniquement avec des améliorations de latence mesurées et un plan de retour arrière.

14) Pour mdbox : localiser les métadonnées clés et valider des signes d’intégrité basiques

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

Sens : La présence d’index et de fichiers map est attendue. Des fichiers manquants ou de taille zéro en fonctionnement normal peuvent indiquer une corruption ou des problèmes de permissions.

Décision : Si ces fichiers manquent ou sont illisibles, corrigez d’abord permissions/ownership ; si la corruption est suspectée, passez à une restauration depuis snapshot ou aux workflows de réparation Dovecot.

15) Observer la contention de lock active sur les fichiers de mailbox

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

Sens : Vous pouvez voir quels fichiers sont chauds. Si de nombreux processus se disputent les fichiers d’index/log, vous avez peut-être une charge qui tourne constamment les flags ou force des réécritures d’index.

Décision : Si la contention est constante, évaluez les paramètres d’index, la latence du stockage et le comportement des clients (par ex. clients qui resynchronisent tout constamment).

Guide de diagnostic rapide

Ceci est l’ordre qui trouve rapidement les goulots sans se transformer en un projet d’archéologie d’une semaine.

Premier : prouver si c’est la latence stockage, le CPU, ou la concurrence Dovecot

• IO wait et latence : iostat -x 1 3 et pidstat -d 1 5. Un iowait élevé ou un await élevé pointe vers le stockage ou des patterns de sync.
• Saturation CPU : top ou pidstat -u 1 5. Si le CPU est saturé, vous ne choisissez pas entre Maildir et mdbox—vous choisissez entre scaler et réécrire.
• Pression de connexions : doveadm service status. Si les connexions IMAP explosent et que les processus sont affamés, corrigez les limites de processus et le comportement client.

Deuxième : déterminer si le problème est « métadonnées du filesystem » ou « métadonnées Dovecot »

• Suspects Maildir : utilisation des inodes (df -ih), nombres de fichiers énormes dans un dossier (find ... | wc -l), avertissements ext4 de dmesg.
• Suspects mdbox : dovecot.map.index manquant/ invalide et churn des logs d’index, requêtes status lentes malgré des métriques de stockage raisonnables.

Troisième : valider si le problème est localisé ou systémique

• Exécutez doveadm mailbox status sur un utilisateur « chaud » et un utilisateur « normal ».
• Si seuls quelques utilisateurs sont lents, traitez-les comme des cas spéciaux (archivage, séparation de boîte, format différent, volume différent).
• Si tout le monde est lent, suspectez le stockage, les indexeurs globaux, les sauvegardes ou un changement récent de montage/options/kernel/firmware.

Quatrième : choisir l’action corrective la moins risquée

• Reconstruire les index (sûr et réversible).
• Arrêter les E/S concurrentes (sauvegardes, scans antivirus, shipping de logs agressif).
• Corriger les erreurs filesystem/matériel avant de tuner Dovecot.
• Ce n’est qu’ensuite que vous envisagerez une migration entre formats.

Erreurs fréquentes : symptômes → cause → correction

1) « La connexion IMAP est lente, mais l’utilisation disque est faible »

Symptômes : Les utilisateurs signalent des délais à l’ouverture des dossiers ; la surveillance montre un %util disque faible.

Cause : Haute latence par opération (E/S de métadonnées, écritures sync, recherches de répertoire). Faible utilisation ne signifie pas faible latence.

Correction : Mesurez await avec iostat -x. Si la latence est élevée, réduisez les comportements lourds en sync, déplacez les sauvegardes hors du FS live, et envisagez mdbox si les inodes/overhead de répertoire dominent.

2) « Les sauvegardes sont cohérentes parce qu’on utilise rsync la nuit »

Symptômes : Les restaurations produisent des boîtes bizarres : messages récents manquants, doublons, ou tempêtes de resync côté client.

Cause : La copie fichier par fichier a capturé Maildir/mdbox en cours de mise à jour ; les index et les messages ne sont pas du même point dans le temps.

Correction : Sauvegardes snapshot-first. Restaurer depuis snapshot. Reconstruire les index après restauration via doveadm index ou en supprimant prudemment les fichiers d’index obsolètes.

3) « On mettra tout dans un INBOX massif »

Symptômes : Un ou deux utilisateurs sont toujours lents ; les fenêtres de sauvegarde explosent ; des avertissements filesystem apparaissent.

Cause : Les dossiers énormes amplifient le coût des listings et des métadonnées (Maildir) ou la surcharge d’indexation (tout format).

Correction : Appliquez des politiques d’archivage et de dossier. Envisagez des règles Sieve côté serveur. Scindez les boîtes chaudes sur des tiers de stockage.

4) « Nous avons migré les formats et n’avons pas planifié la transition des index »

Symptômes : Après migration, les clients voient des mails manquants jusqu’à resync ; la charge serveur monte en flèche.

Cause : Les index n’ont pas été reconstruits proprement ou ont été restaurés de façon incohérente ; les clients déclenchent un resync lourd.

Correction : Reconstruction d’index post-migration, reconnexion client par étapes et contrôle de la concurrence. Communiquez le comportement attendu de resync au support.

5) « Nous avons désactivé fsync pour la perf »

Symptômes : La performance s’est améliorée… jusqu’à un crash ou une coupure ; ensuite les utilisateurs perdent des mises à jour de flags, des livraisons récentes, ou voient des états corrompus.

Cause : Réglages de durabilité non sûrs. Le stockage mail est riche en métadonnées d’écriture ; perdre quelques secondes peut créer des incohérences confuses.

Correction : Conservez une durabilité raisonnable. Si vous voulez de la vitesse, achetez du meilleur stockage ou repensez l’architecture ; ne jouez pas à la roulette avec l’intégrité sauf si vous tolérez la perte.

6) « L’antivirus scanne tout le store mail chaque heure »

Symptômes : Pics périodiques de latence ; beaucoup de misses de cache ; pics IO ; plaintes utilisateurs par vagues.

Cause : Les nombreux fichiers de Maildir punissent les scans complets ; même mdbox souffre si les scans déstabilisent les caches.

Correction : Scannez à l’ingestion (pipeline LMTP/SMTP) ou utilisez des scans ciblés. Excluez les index et répertoires transitoires des scans larges quand c’est approprié.

7) « On a supposé que le filesystem n’avait pas d’importance »

Symptômes : La même configuration se comporte différemment selon les hôtes ; des mises à jour « changent la perf au hasard ».

Cause : L’indexation de répertoire, le comportement de l’allocateur et la journalisation diffèrent selon le FS et la version du kernel.

Correction : Standardisez le choix du filesystem et les options de montage pour les volumes mail. Faites des benchmarks d’opérations de boîte, pas seulement du débit séquentiel.

Trois mini-histoires d’entreprise (anonymisées, plausibles et instructives)

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

Ils géraient une plateforme mail corporate de taille moyenne. Rien d’exotique : Dovecot, Postfix, un cluster de VM, et un volume de stockage « temporaire » devenu permanent. Un nouveau membre a demandé quel format de boîte ils utilisaient. La réponse fut confiante et fausse : « C’est Maildir, donc ce ne sont que des fichiers. Les sauvegardes sont faciles. »

Le job de sauvegarde était une copie par parcours de fichiers la nuit. Pas de snapshots. Le job tournait pendant des livraisons et parfois pendant les pics de sync mobile. Il « fonctionnait » dans le sens où il produisait un tas de fichiers. Il capturait aussi des états transitoires : messages dans tmp, renommages à moitié faits, logs d’index en cours de mise à jour.

Des mois plus tard, une défaillance de stockage a forcé une restauration. La restauration s’est terminée rapidement—la direction a applaudi. Puis la file d’attente du support s’est transformée en attaque par déni de service. Les utilisateurs voyaient des messages manquants, des fils dupliqués et des dossiers qui semblaient vides jusqu’à ce qu’ils cliquent et attendent. Certains clients « ont réparé » en retéléchargeant tout, ce qui a alourdi le serveur, qui a fait que les clients retentaient encore plus.

La cause racine n’était pas Maildir. C’était l’hypothèse que la sauvegarde au niveau fichier équivaut à une sauvegarde cohérente. Ils sont passés aux sauvegardes basées sur snapshot et ont ajouté un drill de restauration incluant la reconstruction d’index et la reconnexion client par étapes. La restauration suivante était ennuyeuse. Tout le monde l’a moins détestée. C’est comme ça qu’on sait que ça a marché.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre entreprise avait une forte pression d’inodes. Ils sont passés à mdbox pour réduire le nombre de fichiers et diminuer le temps de scan des sauvegardes. Bonne idée. Puis ils ont décidé de pousser la perf en ajustant la durabilité : réduire les syncs et pousser le cache d’écriture. Les résultats des benchs s’amélioraient. Les graphiques étaient beaux.

Puis un événement d’alimentation est survenu dans un rack. Pas un désastre, juste quelques minutes de chaos. Les systèmes ont redémarré. La plupart des services se sont remis correctement. Le mail non. Les utilisateurs pouvaient se connecter, mais les nouveaux mails apparaissaient de façon incohérente, et les flags se comportaient comme des suggestions. Certains mails existaient dans les fichiers box mais n’apparaissaient pas en vue IMAP avant la réparation des index. Certaines réparations ont fonctionné ; d’autres ont nécessité la restauration des métadonnées depuis des snapshots.

La revue post-incident n’a pas été agréable. L’« optimisation » avait réduit le coût de chaque écriture en échange de propriétés de fiabilité qu’ils utilisaient implicitement. Avec un stockage agrégé et des structures de métadonnées, de petites incohérences peuvent cascader en états visibles par les utilisateurs, difficiles à expliquer et plus difficiles à supporter.

Ils ont annulé les réglages risqués, investi dans une protection d’alimentation correcte pour le stockage, et standardisé une approche snapshot+réplication testée. La performance était un peu moins bonne que dans le fantasme des benchs. La disponibilité était meilleure que la réalité de la panne. Choisissez la réalité.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée exploitait Dovecot à grande échelle. Leur stockage mail était suffisamment grand pour que « tout restaurer » ne soit pas un plan ; c’était une lettre de démission. Ils utilisaient Maildir pour la plupart des utilisateurs et mdbox pour un sous-ensemble de comptes à fort volume. La clé n’était pas les formats. C’était la discipline.

Ils pratiquaient des restaurations trimestrielles. Pas « on a testé les sauvegardes ». De vraies restaurations : choisir une boîte au hasard, la restaurer sur une machine isolée, reconstruire les index, valider l’accès IMAP et vérifier les comptes de messages et les livraisons récentes. Ils pratiquaient aussi une politique : snapshot toutes les quelques minutes, conserver une courte rétention localement, répliquer les snapshots hors site, et tester le chemin de restauration de bout en bout.

Quand un contrôleur de stockage a commencé à glitcher, ils l’ont vu tôt dans dmesg et SMART. Avant que cela ne devienne une perte de données, ils ont basculé le service mail vers la réplique et ont continué à servir les utilisateurs. Ensuite ils ont restauré quelques boîtes affectées depuis le dernier snapshot sain et les ont validées avec les outils Dovecot avant de les réintroduire.

Pas d’héroïsme. Pas de mystère. Juste le genre d’hygiène opérationnelle ennuyeuse qui semble chère jusqu’au moment où c’est la chose la moins coûteuse que vous ayez jamais faite.

Listes de contrôle / plan étape par étape

Choisir un format : checklist de décision

1. Combien de messages par utilisateur ? Si beaucoup d’utilisateurs dépassent 200k messages dans un dossier, Maildir punira votre filesystem à moins que vous ne gériez le fractionnement des dossiers.
2. Êtes-vous contraint par les inodes ? Si df -ih montre une tendance au-dessus de 70 % et en croissance, traitez-le comme un problème d’échelle, pas une simple étiquette d’avertissement.
3. Avez-vous des sauvegardes basées sur snapshot ? Si non, corrigez cela avant de changer de format. Sinon vous ne ferez que modifier la forme de l’incohérence de sauvegarde.
4. Avez-vous besoin d’une récupération partielle facile ? Maildir est généralement plus adapté pour des récupérations chirurgicales. mdbox peut convenir, mais vous aurez besoin d’outils et de processus rodés.
5. Quel est votre système de fichiers ? Faites des benchmarks d’opérations de boîte sur le filesystem et le kernel réels que vous allez utiliser. Les charges mail sont riches en métadonnées et étranges.
6. Avez-vous du temps de personnel pour la maintenance ? Si non, choisissez la voie avec les opérations day-2 les plus simples : Maildir plus un bon snapshoting.

Plan de migration : Maildir → mdbox (séquence sûre-ish)

1. Inventoriez les utilisateurs et identifiez les boîtes chaudes (dossiers volumineux, churn élevé).
2. Mettez en place des sauvegardes snapshot et effectuez un drill de restauration avant la migration.
3. Installez un serveur de staging avec la version et la configuration Dovecot cible.
4. Migrez d’abord un petit groupe pilote. Surveillez la latence IMAP, le temps de reconstruction d’index et les problèmes visibles par les utilisateurs.
5. Planifiez les migrations hors-peak. Limitez la concurrence. Ne migrez pas tout le monde en même temps sauf si vous aimez vivre dangereusement.
6. Après chaque lot : reconstruisez les index, validez les comptes de messages, et surveillez les tempêtes de resync côté client.
7. Conservez la capacité de rollback via snapshots et un marqueur de cutover clair.

Checklist opérationnelle de base (quel que soit le format)

• Sauvegardes basées sur snapshot avec restaurations testées.
• Surveillance de l’utilisation des inodes, de la croissance des répertoires et du volume de mail.
• Surveillance de la latence de stockage (await) et des erreurs kernel liées au stockage.
• Procédures définies pour la reconstruction d’index et la réparation de boîtes.
• Contrôle du comportement des clients quand c’est possible (les patterns de sync agressifs peuvent vous faire un DOS).

FAQ

1) Maildir est-il toujours plus sûr que mdbox ?

Non. Maildir a souvent un rayon d’impact plus petit pour une corruption d’un seul fichier, mais il peut échouer de façon spectaculaire via l’épuisement des inodes et l’overhead des métadonnées. « Plus sûr » dépend de ce que vous êtes susceptible de mal gérer.

2) mdbox est-il toujours plus rapide ?

Non. mdbox peut réduire le coût des petits fichiers, mais si votre goulot est le churn d’index, les réglages de sync ou la latence de stockage lente, il ne corrigera pas magiquement cela. Il peut aussi ajouter de la complexité pendant les réparations et restaurations.

3) Quelle est la principale raison pour laquelle les systèmes Maildir deviennent lents avec le temps ?

La croissance du nombre de fichiers plus les opérations sur les métadonnées. Le système ne ralentit pas linéairement ; il se dégrade quand les répertoires deviennent énormes, que les sauvegardes commencent à ramper et que l’utilisation des inodes approche du précipice.

4) Quelle est la principale raison pour laquelle les systèmes mdbox deviennent pénibles ?

La dépendance opérationnelle aux métadonnées gérées par Dovecot et le besoin de sauvegardes cohérentes. Si vous ne snapshottez pas, vous pouvez restaurer une boîte qui existe mais qui « n’a pas de sens » pour Dovecot jusqu’à réparation.

5) Dois-je stocker le mail sur NFS ?

Seulement si vous comprenez la sémantique de locking client/serveur NFS, les caractéristiques de latence et le comportement en cas de panne sous charge. Le stockage réseau est riche en métadonnées et sensible aux pics de latence. Beaucoup de problèmes « mystérieux » de mail ne sont que le stockage réseau qui fait son travail.

6) Puis-je mélanger les formats sur le même système ?

Oui, et parfois c’est la réponse pragmatique : gardez la plupart des utilisateurs sur Maildir et migrez les comptes à fort volume et à fort usage d’inodes vers mdbox. Assurez-vous simplement que vos outils opérationnels couvrent les deux.

7) Les snapshots remplacent-ils la réplication Dovecot ?

Non. Les snapshots vous aident à revenir en arrière et à restaurer. La réplication vous aide à rester disponible. Ils résolvent des problèmes différents et échouent différemment.

8) Comment savoir si c’est une corruption d’index ou une vraie perte de message ?

Comparez la réalité du filesystem à la vue IMAP. Si les messages existent sur disque (fichiers maildir ou storage mdbox) mais n’apparaissent pas, reconstruisez les index. S’ils n’existent pas sur disque, c’est une perte et vous devez restaurer.

9) Quelle est la maintenance minimale viable pour une couche de stockage Dovecot saine ?

Sauvegardes basées sur snapshot, drills de restauration périodiques, surveillance de l’utilisation des inodes et de la latence de stockage, et un runbook pour la reconstruction/réparation d’index. Le reste n’est que optimisation.

Prochaines étapes que vous pouvez faire cette semaine

1. Exécutez les bases : doveconf -n, df -ih, iostat -x, et doveadm mailbox status sur un utilisateur chaud. Notez ce qui est réellement vrai.
2. Vérifiez la cohérence des sauvegardes : Si vous ne faites pas de snapshots, considérez vos sauvegardes comme des « copies best-effort », pas des restaurations fiables pour votre poste.
3. Faites un drill de restauration : Choisissez une boîte, restaurez-la dans un environnement isolé, reconstruisez les index, validez IMAP. Chronométrez et documentez.
4. Identifiez la falaise de croissance : Inodes, dossiers énormes et latence stockage sont les trois gros facteurs. Mettez des alertes dessus.
5. Décidez avec intention : Si votre douleur vient des inodes et de l’overhead des métadonnées, mdbox peut être la solution. Si votre douleur est la récupérabilité et la simplicité opérationnelle, restez sur Maildir et adaptez le filesystem et les sauvegardes.

Choisissez le format qui correspond à votre budget de défaillance et à votre réalité de restauration. Votre futur vous sera celui qui sera en astreinte. Ne lui faites pas une mauvaise blague.