Dovecot: maildir vs mdbox — elige el almacenamiento que no te perseguirá

La decisión que realmente importa

“Maildir vs mdbox” suena a debate de formatos. No lo es. Es un debate de filosofía operacional:

• Maildir apuesta por la semántica del sistema de archivos: cada mensaje es un archivo separado; los renombrados atómicos son tus aliados; la corrupción tiende a localizarse; y obtienes muchos inodos.
• mdbox apuesta por la agregación gestionada por Dovecot: los mensajes viven en archivos contenedor más grandes con metadatos de Dovecot; reduces la presión de inodos; las operaciones pueden ser más rápidas bajo ciertos patrones de E/S; y cuando fallas, puedes estropear más.

Si gestionas un servidor pequeño con un sistema de archivos razonable y quieres depuración sencilla y recuperación parcial fácil, Maildir es la opción por defecto que envejecerá bien. Si operas a escala donde el número de inodos, el escaneo de directorios y la sobrecarga de pequeños archivos te están matando, mdbox puede ser el dolor correcto—pero solo si eres disciplinado con las copias, el mantenimiento y las herramientas operativas.

Una cita que vale la pena pegar en una nota adhesiva, porque se aplica directamente a formatos de buzón: “La esperanza no es una estrategia.” — Gene Kranz.

Maildir y mdbox en una sola pantalla

Maildir: qué es

Maildir almacena cada mensaje como un archivo separado en una estructura de directorios—típicamente cur/, new/ y tmp/ por buzón. Las banderas a menudo se codifican en el nombre del archivo. La entrega y los movimientos dependen del comportamiento de renombrado atómico.

Ambiente operativo: Cuando algo se rompe, a menudo puedes abrir un directorio y ver los mensajes. Puedes recuperar a un usuario sin sentir que estás desactivando una bomba.

mdbox: qué es

mdbox almacena mensajes dentro de archivos “box” gestionados por Dovecot (con metadatos de índice y mapa acompañantes). Piénsalo como Dovecot ocupándose más de la capa de almacenamiento: menos archivos, más estructura y mayor dependencia de las garantías de consistencia de Dovecot.

Ambiente operativo: Cuando es rápido, es agradable. Cuando necesitas reparar, quieres tener tus herramientas listas y tus copias verificadas.

Qué deberías elegir (opinión)

• Elige Maildir si: eres una operación pequeña a mediana, valoras la recuperación simple, tienes SSD razonables, usas snapshots/copias y deseas dominios de fallo previsibles.
• Elige mdbox si: tienes muchos usuarios, muchos mensajes, la presión de inodos es real, el coste de listar directorios duele, o necesitas características de almacenamiento como recuentos de archivos eficientes—y estás dispuesto a operacionalizar el mantenimiento de Dovecot y los ensayos de copia/restauración.
• Evita “no importa” como decisión. Importa el día que necesites restaurar un buzón a las 3 a. m. y tu proceso de restauración sea básicamente “restaurar todo y rezar”.

Broma #1: Las decisiones sobre almacenamiento de correo son como los tatuajes: parecen divertidas hasta que intentas quitártelas durante la revisión trimestral de incidencias.

Hechos e historia que explican los compromisos actuales

Un poco de contexto hace que los compromisos parezcan menos arbitrarios. Aquí hay puntos concretos que muestran por qué existen estos formatos y por qué se comportan como lo hacen:

1. Maildir se diseñó para evitar los problemas de bloqueo de mbox. mbox tradicional almacena todo un buzón en un solo archivo; el acceso concurrente históricamente causó problemas de bloqueo y riesgo de corrupción.
2. El truco de “renombrado atómico” de Maildir depende de las garantías del sistema de archivos. El patrón tmp→new/cur depende de la atomicidad dentro del mismo sistema de archivos.
3. IMAP multiplicó las necesidades de “metadatos” del buzón. Indexado, banderas y seguimiento de UID se volvieron críticos para el rendimiento; los archivos de índice de Dovecot son respuesta a esa realidad.
4. La sobrecarga de archivos pequeños se convirtió en un gran problema conforme creció la retención de correo. Millones de archivos diminutos estresan inodos, búsquedas en directorios y herramientas de backup; esa presión es una razón por la que existen formatos agregados.
5. Dovecot introdujo formatos “box” para reducir el desgaste del sistema de archivos. mdbox y diseños similares trasladan trabajo desde el sistema de archivos a estructuras gestionadas por Dovecot.
6. La evolución de los sistemas de archivos importa. Ext4, XFS, ZFS y btrfs manejan directorios y metadatos de forma distinta; el mismo formato puede ser “aceptable” en uno y problemático en otro.
7. Los snapshots copy-on-write cambiaron las expectativas de respaldo. Con snapshots ZFS/btrfs, el “punto en el tiempo consistente” es más sencillo—pero solo si tu modelo de indexado y bloqueo se comporta bien bajo snapshots.
8. Los clientes de correo se volvieron más agresivos. Los clientes móviles hacen sincronizaciones frecuentes; la búsqueda/FTS en servidor se volvió esperada; los formatos que amplifican la E/S de metadatos pueden sentirse peor hoy que en 2008.

Cómo falla cada formato en producción

Modos de fallo de Maildir

1) “Demasiados archivos” se convierte en una interrupción real. Alcanzas la extenuación de inodos, las copias se ralentizan hasta arrastrarse o las exploraciones de directorios se convierten en tu piso de latencia. Maildir no te avisa cortésmente; simplemente se vuelve lento y luego repentinamente imposible.

2) La corrupción parcial es sobrevivible—pero no gratuita. Algunos archivos de mensaje pueden corromperse por problemas de disco o transferencias rotas. Normalmente puedes recuperar el resto. Pero si tus archivos de índice se vuelven raros, los clientes verán mensajes ausentes o duplicados hasta que reconstruyas índices.

3) Las copias mienten si no haces snapshots. Un backup archivo por archivo mientras la entrega está en curso puede capturar estados inconsistentes (mensajes en tmp/, renombrados parciales). Aún puede funcionar, pero necesitas entender qué significa “consistente” para maildir.

Modos de fallo de mdbox

1) La consistencia de metadatos se vuelve tu vida. mdbox se apoya en metadatos de Dovecot (índices, archivos map). Si esos están desincronizados o corruptos, el buzón puede parecer vacío o revuelto incluso si los archivos box subyacentes existen.

2) Radio de impacto mayor por archivo. Un archivo contenedor corrupto puede afectar a más mensajes. Las herramientas de Dovecot pueden reparar en muchos casos, pero el aislamiento de “archivo de mensaje único” de maildir no es lo habitual aquí.

3) La complejidad de restauración aumenta. Restaurar un buzón puede ser sencillo si tienes directorios por usuario y buenas herramientas. También puede ser un desastre si hiciste “un volumen gigante y esperanza”. El diseño importa.

Broma #2: El mejor formato de buzón es el que puedes restaurar mientras tu café todavía es potable.

Modelo de rendimiento: por lo que realmente pagas

El impuesto oculto en Maildir: metadatos y operaciones de directorio

El rendimiento de Maildir está dominado por metadatos del sistema de archivos: crear, renombrar, stat, listar directorios y actualizar marcas de tiempo. Si tienes SSD y un sistema de archivos que maneja bien los directorios, Maildir puede ser muy rápido. Si tienes discos giratorios o rutas de metadatos saturadas, Maildir puede sentirse como si hiciera todo excepto servir correo.

Cuando los usuarios tienen cientos de miles de mensajes en una sola carpeta, Maildir puede degradarse drásticamente porque el servidor termina haciendo muchas operaciones de directorio solo para responder “¿qué hay de nuevo?”. Los índices de Dovecot ayudan, pero el recuento subyacente de archivos aún te persigue en backups, tiempo de fsck y uso de inodos.

El impuesto oculto en mdbox: estructuras gestionadas por Dovecot y flujo de reparación

mdbox tiende a reducir la presión del recuento de archivos, lo que puede reducir la sobrecarga de directorios e inodos. Pero pagas en otra moneda: necesitas confiar y mantener las estructuras de metadatos de Dovecot. Eso significa que te importa la integridad de índices, la salud de los archivos map y cómo interactúan tus copias/restauraciones con esos archivos.

En sistemas muy ocupados, mdbox puede ser más amable con el sistema de archivos, pero también puede amplificar las consecuencias de afinamientos “ingeniosos” o prácticas de copia inseguras.

Latencia vs rendimiento sostenido: elige lo que sienten tus usuarios

La mayoría de las interrupciones de correo no son “el servidor no puede manejar el throughput”. Son “el login es lento”, “abrir INBOX es lento”, “la búsqueda es lenta”, “las actualizaciones de banderas son lentas”. Eso es latencia. La latencia viene de viajes de ida y vuelta al almacenamiento y de la contención de metadatos.

Regla práctica: Si tu dolor es intenso en metadatos (recuento de archivos, escaneos de directorio, rastreo de backups), mdbox empieza a verse mejor. Si tu dolor es sencillez de reparación y recuperación, Maildir es difícil de superar.

Copias, restauraciones y por qué “son solo archivos” es una trampa

Backups de Maildir: engañosamente simples

Maildir parece “solo archivos”, lo que hace que la gente se relaje. No lo hagas. Maildir en vivo tiene estados transitorios (tmp/), renombrados y actualizaciones de índices. Si lo respaldas sin snapshots, puedes capturar un buzón en pleno vuelo.

Qué funciona bien:

• Snapshots de sistema de archivos (ZFS, btrfs, snapshots LVM thin) y leer las copias desde el snapshot.
• Backups que preserven permisos, propietario y marcas de tiempo (la entrega de correo y Dovecot son sensibles a esto).
• Prácticas regulares de reconstrucción de índices durante las pruebas de restauración.

Backups de mdbox: necesitas consistencia, no solo copias

mdbox requiere capturar tanto los archivos box como los archivos de metadatos/índice en un punto en el tiempo consistente. Los backups basados en snapshots son la línea base sensata. Si te basas en copias archivo por archivo sin snapshots, corres el riesgo de capturar estados descoordinados—el archivo box dice una cosa, el índice otra y el mapa una tercera.

Restauraciones: planifica para “un usuario, una carpeta, un mensaje”

La restauración que importa no es “restaurar todo el servidor”. Es “restaurar una carpeta de buzón para un ejecutivo porque un cliente sincronizó y borró todo”. Esa restauración debe ser un runbook, no una improvisación heroica.

Si no puedes restaurar un solo buzón sin restaurar el mundo, no elegiste un formato de almacenamiento; elegiste un incidente futuro.

Replicación/HA: verificación de la realidad

El formato de buzón no reemplaza la estrategia de replicación. Solo cambia los modos de fallo y la ergonomía operativa.

Replicación de Dovecot y elección de formato

Dovecot puede replicar buzones a nivel de aplicación. Eso puede suavizar algunas diferencias del sistema de archivos. Pero la replicación no arregla:

• La mala planificación de capacidad (la extenuación de inodos sigue ocurriendo, solo que en dos máquinas).
• El almacenamiento lento (ahora tienes almacenamiento lento más sobrecarga de replicación).
• Prácticas de copia inseguras (la replicación replicará gustosamente eliminaciones y algunas formas de corrupción).

Snapshots no son replicación, replicación no es backup

Los snapshots te dan recuperación a un punto en el tiempo; la replicación te da disponibilidad. Quieres ambos si el sistema de correo importa. Si solo puedes permitirte uno, elige copias que hayas probado. Disponibilidad sin recuperación es solo una forma más rápida de permanecer caído.

Tareas prácticas: comandos, salidas y lo que decides

Estos son los chequeos que realmente ejecuto cuando alguien dice “IMAP está lento”, “los mensajes desaparecieron” o “el disco está bien, pero el correo muere”. Cada tarea incluye qué significa la salida y la decisión que tomas.

1) Confirmar el formato actual de buzón

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

Significado: Este servidor usa maildir en el directorio home de cada usuario. Si esperabas mdbox, tus “suposiciones de rendimiento” ya están equivocadas.

Decisión: Mantén la investigación alineada con el formato: la presión de inodos y las operaciones de directorio importan más con maildir; la consistencia de metadatos y la integridad map/índice importan más con mdbox.

2) Comprobar la versión de Dovecot (las funciones y errores importan)

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

Significado: Estás en una 2.3.x moderna. El comportamiento difiere entre versiones mayores/menores, especialmente alrededor del manejo de índices y los valores por defecto de fsync.

Decisión: Si estás en algo antiguo, considera actualizar antes de hacer afinamientos “ingeniosos”. Los errores antiguos en almacenamiento de correo no son encantadores.

3) Medir uso de inodos (el asesino silencioso de Maildir)

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

Significado: 83% de uso de inodos. Eso no es “bien”. Eso es “a una mala importación de tiempo de inactividad”.

Decisión: Si el uso de inodos crece rápido, o bien (a) migra a un sistema de archivos con más inodos/estrategia de asignación distinta, (b) aplica retención, (c) mueve usuarios de alto volumen a mdbox, o (d) rediseña el particionado/archivo de carpetas.

4) Contar archivos de mensaje en una carpeta caliente

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

Significado: 287k archivos en un directorio. Muchos sistemas de archivos manejan esto mal bajo churn, incluso si las lecturas están cacheadas.

Decisión: Considera particionar carpetas (archivos por año), cambios en la política del cliente, o mover a ese usuario a mdbox si el coste operativo se repite.

5) Identificar si Dovecot pasa tiempo 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

Significado: El iowait de CPU es alto (24.5%). El almacenamiento no está saturado (%util ~10%), pero la latencia (await) no es buena. Eso a menudo apunta a patrones intensivos en sync o contención de metadatos más que a límites de throughput bruto.

Decisión: Revisa ajustes de fsync, procesos Dovecot que provoquen picos de sync y opciones de montaje del sistema de archivos. Para maildir, los patrones de escritura de metadatos pueden provocar esto incluso en SSD.

6) Ver qué procesos causan presión de 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

Significado: Dovecot está escribiendo intensamente (probablemente actualizaciones de índices, cambios de banderas, entregas). También hay un rsync en ejecución—clásico “backup compitiendo con la E/S en vivo”.

Decisión: Si no tienes snapshots, detén los backups que rastrean archivos durante las horas pico. Pasa a backups basados en snapshot o programa rsync fuera de horas, o aplícale throttling.

7) Comprobar salud del servicio Dovecot y concurrencia

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

Significado: IMAP tiene 380 conexiones activas. Los indexer workers están activos. Si estás infraaprovisionado en indexers, las búsquedas y la apertura de buzones pueden arrastrarse.

Decisión: Ajusta límites de procesos con responsabilidad. Si los indexers están saturados, aumenta workers o arregla la causa (por ejemplo, reconstrucciones constantes de índices por problemas de permisos o cachés rotas).

8) Medir latencia de apertura de buzón y status (desde la perspectiva de 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

Significado: Este comando debe devolver rápido. Si se queda colgado, tienes latencia de E/S, problemas de índice o contención de bloqueo.

Decisión: Si es lento: busca corrupción de índices, costosas exploraciones de sistema de archivos o almacenamiento bloqueado. Para maildir con INBOX enorme, fomenta archivado.

9) Identificar y reconstruir archivos de índice rotos de forma segura

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

Significado: Dovecot puede reconstruir índices. La salida de depuración confirma la carga de módulos y que el indexado finalizó.

Decisión: Si esto arregla mensajes faltantes en los clientes, tuviste inconsistencia de índices en lugar de pérdida de mensajes. Añade mantenimiento periódico de índices o arregla la causa raíz (permisos, errores de disco, reinicios forzados).

10) Buscar errores a nivel de sistema de archivos (el suero de la verdad aburrido)

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

Significado: Timeouts NVMe y una advertencia de indexado de directorio en ext4. Eso no es un problema de Dovecot. Es comportamiento de almacenamiento y sistema de archivos bajo estrés.

Decisión: Repara hardware/firmware, revisa la salud del NVMe y considera afinamiento del sistema de archivos o mover el almacenamiento de correo a un sistema de archivos mejor adaptado para directorios enormes.

11) Confirmar salud real del disco (antes de culpar al formato 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

Significado: No hay errores de medio, pero hay entradas en el registro de errores. Combinado con resets NVMe, puedes tener problemas intermitentes de controlador/firmware.

Decisión: Programa mantenimiento: actualizaciones de firmware, comprobaciones de controlador y considera redundancia. Los formatos de buzón no te salvarán de hardware inestable.

12) Comprobar distribución de directorios y archivos (detectar layouts patológicos)

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

Significado: 96 GB para un solo usuario. Grande está bien, pero grande más muchos archivos pequeños lo cambia todo.

Decisión: Si unos pocos usuarios dominan almacenamiento y rendimiento, trátalos de forma especial: tier de almacenamiento separado, mdbox o volumen dedicado.

13) Comprobar opciones de montaje del sistema de archivos (los asesinos de latencia se esconden aquí)

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

Significado: Opciones estándar. Si ves sync u opciones de journaling extremadamente agresivas, podrías haberte infligido latencia a ti mismo.

Decisión: Evita cambios aleatorios de opciones de montaje por moda. Haz cambios solo con mejoras medidas de latencia y un plan de reversión.

14) Para mdbox: localizar metadatos clave y validar signos básicos de integridad

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

Significado: La presencia de archivos de índice y mapa es esperada. Archivos faltantes o de tamaño cero durante la operación normal pueden indicar corrupción o problemas de permisos.

Decisión: Si faltan o son ilegibles, arregla permisos/propietario primero; si sospechas corrupción, pasa a restauración desde snapshot o a los flujos de reparación de Dovecot.

15) Observar contención activa de locks en archivos de buzón

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

Significado: Puedes ver qué archivos están calientes. Si muchos procesos compiten por archivos de índice/log, puedes tener una carga que churnea banderas o fuerza reescrituras de índice.

Decisión: Si la contención es consistente, evalúa la configuración de índices, la latencia del almacenamiento y el comportamiento del cliente (por ejemplo, clientes que se resyncéan todo constantemente).

Guía rápida de diagnóstico

Este es el orden que encuentra cuellos de botella rápidamente sin convertirse en un proyecto arqueológico de una semana.

Primero: prueba si es latencia de almacenamiento, CPU o concurrencia de Dovecot

• IO wait y latencia: iostat -x 1 3 y pidstat -d 1 5. Iowait alto o await alto apunta a almacenamiento o patrones de sync.
• Saturación de CPU: top o pidstat -u 1 5. Si la CPU está al máximo, no estás eligiendo entre maildir y mdbox—estás eligiendo entre escalar y reescribir.
• Presión de conexiones: doveadm service status. Si las conexiones IMAP se disparan y los procesos se quedan sin recursos, ajusta límites y comportamiento de clientes.

Segundo: determina si el problema es “metadatos de sistema de archivos” o “metadatos de Dovecot”

• Sospechas de Maildir: uso de inodos (df -ih), recuentos enormes de archivos en carpetas (find ... | wc -l), advertencias de directorio ext4 en dmesg.
• Sospechas de mdbox: dovecot.map.index faltante/inválido y churn de logs de índice, consultas status lentas pese a métricas de almacenamiento razonables.

Tercero: valida si el problema está localizado o es sistémico

• Ejecuta doveadm mailbox status en un usuario “caliente” y en uno “normal”.
• Si solo unos pocos usuarios son lentos, trátalos como casos especiales (archivado, división de buzón, formato distinto, volumen distinto).
• Si todos están lentos, sospecha del almacenamiento, indexers globales, backups o un cambio reciente en montaje/opciones/kernel/firmware.

Cuarto: elige la acción correctiva de menor riesgo

• Reconstruir índices (seguro y reversible).
• Detener E/S competidora (backups, escaneos antivirus, envío de logs agresivo).
• Arreglar errores de sistema de archivos/hardware antes de afinar Dovecot.
• Solo entonces considera migrar entre formatos.

Errores comunes: síntomas → causa raíz → solución

1) “El login IMAP es lento, pero la utilización del disco es baja”

Síntomas: Usuarios reportan retrasos al abrir carpetas; el monitoreo muestra %util de discos bajo.

Causa raíz: Alta latencia por operación (E/S de metadatos, escrituras sincrónicas, búsquedas en directorios). Baja utilización no significa baja latencia.

Solución: Mide await con iostat -x. Si la latencia es alta, reduce comportamientos sync-intensivos, mueve backups fuera del FS en vivo y considera mdbox si la sobrecarga de inodos/directorios domina.

2) “Las copias son consistentes porque usamos rsync nocturno”

Síntomas: Las restauraciones producen buzones raros: mensajes recientes ausentes, duplicados o tormentas de resync en clientes.

Causa raíz: Copia archivo por archivo capturó maildir/mdbox a medio actualizar; índices y mensajes no son del mismo punto en el tiempo.

Solución: Backups basados en snapshot. Restaura desde snapshot. Reconstruye índices post-restauración usando doveadm index o eliminando archivos de índice obsoletos con cuidado.

3) “Lo pondremos todo en un INBOX masivo”

Síntomas: Uno o dos usuarios siempre lentos; ventanas de backup se disparan; aparecen advertencias del sistema de archivos.

Causa raíz: Carpetas gigantes amplifican costos de listado y metadatos (maildir) o sobrecarga de indexado (cualquier formato).

Solución: Aplica políticas de archivado y foldering. Considera reglas Sieve en servidor. Divide buzones calientes entre tiers de almacenamiento.

4) “Migramos formatos y no planificamos la transición de índices”

Síntomas: Tras la migración, los clientes ven correo faltante hasta que se resyncean; la carga del servidor se dispara.

Causa raíz: Los índices no se reconstruyeron limpiamente o se restauraron de forma inconsistente; los clientes disparan sincronizaciones pesadas.

Solución: Reconstrucción de índices post-migración, reconexión escalonada de clientes y control de concurrencia. Comunica el resync esperado al helpdesk.

5) “Afinamos fsync para mejorar rendimiento”

Síntomas: El rendimiento mejora… hasta un fallo o corte de energía; entonces los usuarios pierden actualizaciones de banderas, entregas recientes o ven estado corrupto.

Causa raíz: Ajustes de durabilidad inseguros. El almacenamiento de correo es intensivo en escrituras de metadatos; perder unos segundos puede crear inconsistencias confusas.

Solución: Mantén la durabilidad razonable. Si quieres velocidad, compra mejor almacenamiento o rediseña; no apuestes la integridad a menos que toleres la pérdida.

6) “El antivirus escanea toda la tienda de correo cada hora”

Síntomas: Picos periódicos de latencia; muchas fallas de caché; picos de E/S; usuarios se quejan en oleadas.

Causa raíz: Los muchos archivos de Maildir castigan los escaneos completos; incluso mdbox sufre si los escaneos thrashéan caches.

Solución: Escanea en la ingestión (pipeline LMTP/SMTP) o usa escaneos dirigidos. Excluye índices y directorios transitorios de escaneos amplios cuando sea apropiado.

7) “Asumimos que el sistema de archivos no importa”

Síntomas: La misma configuración se comporta distinto en hosts diferentes; las actualizaciones cambian el rendimiento “aleatoriamente”.

Causa raíz: El indexado de directorios, el comportamiento del asignador y el journaling difieren por sistema de archivos y versión de kernel.

Solución: Estandariza la elección del sistema de archivos y las opciones de montaje para volúmenes de correo. Mide operaciones de buzón, no solo throughput secuencial.

Tres mini-historias corporativas (anonimizadas, plausibles e instructivas)

Mini-historia 1: La caída causada por una suposición equivocada

Gestionaban una plataforma de correo corporativa mediana. Nada exótico: Dovecot, Postfix, un clúster de VM y un volumen de almacenamiento “temporal” que se volvió permanente. Un miembro nuevo del equipo preguntó qué formato de buzón usaban. La respuesta fue segura y equivocada: “Es Maildir, así que son solo archivos. Las copias son fáciles.”

El trabajo de backup era una copia por recorrido nocturno. Sin snapshots. El trabajo corría mientras había entregas y ocasionalmente durante la sincronización móvil pico. “Funcionó” en el sentido de que produjo un montón de archivos. También capturó estados transitorios: mensajes en tmp, renombrados a medio completar, logs de índice a medio actualizar.

Meses después, una falla de almacenamiento obligó a una restauración. La restauración completó rápido—la dirección aplaudió. Luego la cola del helpdesk se volvió un ataque de denegación de servicio. Los usuarios vieron mensajes faltantes, hilos duplicados y carpetas que parecían vacías hasta que hacían clic y esperaban. Algunos clientes “lo arreglaron” volviendo a descargar todo, lo que hizo que el servidor trabajara más, lo que hizo que los clientes reintentaran más.

La causa raíz no fue Maildir. Fue la suposición de que el backup a nivel de archivo equivale a un backup consistente. Pasaron a backups basados en snapshot y añadieron un ensayo de restauración que incluía reconstrucción de índices y reconexión escalonada de clientes. La siguiente restauración fue aburrida. A todos les molestó menos. Así supieron que funcionó.

Mini-historia 2: La optimización que salió mal

Otra compañía tenía presión seria de inodos. Pasaron a mdbox para reducir el recuento de archivos y acortar el tiempo de escaneo de backups. Buena intuición. Luego decidieron exprimir rendimiento extra ajustando la durabilidad: reduciendo comportamiento de sync y empujando más el cache de escritura. En benchmarks se veía genial. Sus gráficas quedaron más bonitas.

Entonces tuvieron un evento de energía en un rack. No un desastre, solo unos minutos de caos. Los sistemas reiniciaron. La mayoría de servicios se recuperó. El correo no se recuperó limpiamente. Los usuarios podían iniciar sesión, pero el correo nuevo aparecía de forma inconsistente y las banderas se comportaban como sugerencias. Parte del correo existía en archivos box pero no aparecía en vistas IMAP hasta que los índices fueron reparados. Algunas reparaciones funcionaron; otras requirieron restauraciones de metadatos desde snapshots.

La revisión post-mortem no fue agradable. La “optimización” redujo el coste de cada escritura cambiando las propiedades de fiabilidad en las que confiaban implícitamente. Con almacenamiento agregado y estructuras de metadatos, pequeñas inconsistencias pueden cascada en estados visibles al usuario difíciles de explicar y más difíciles de soportar.

Revirtieron los ajustes riesgosos, invirtieron en protección de energía adecuada para el almacenamiento y estandarizaron en un enfoque probado de snapshots+replicación. El rendimiento quedó algo peor que la fantasía del benchmark. La disponibilidad fue mejor que la realidad de la caída. Elige la realidad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada ejecutaba Dovecot a escala. Su tienda de correo era lo bastante grande como para que “restaurar todo” no fuera un plan; era una carta de renuncia. Usaban Maildir para la mayoría de usuarios y mdbox para un subconjunto de cuentas de alto volumen. La clave no eran los formatos. Era la disciplina.

Practicaban restauraciones trimestralmente. No “probamos backups”. Restauraciones reales: elegir un buzón al azar, restaurarlo en un host aislado, reconstruir índices, validar acceso IMAP y verificar recuentos de mensajes y entregas recientes. También tenían una política: snapshot cada pocos minutos, retención corta localmente, replicar snapshots fuera del host y probar la ruta de restauración de extremo a extremo.

Cuando un controlador de almacenamiento empezó a fallar, lo vieron temprano en dmesg y SMART. Antes de que se convirtiera en pérdida de datos, hicieron failover del servicio de correo al replicado y siguieron sirviendo usuarios. Luego restauraron algunos buzones afectados desde el último snapshot conocido bueno y los validaron con herramientas de Dovecot antes de reintroducirlos.

Sin heroísmos. Sin misterio. Solo el tipo de higiene operativa aburrida que parece cara hasta que es lo más barato que alguna vez hiciste.

Listas de verificación / plan paso a paso

Elegir un formato: lista de decisión

1. ¿Cuántos mensajes por usuario? Si muchos usuarios superan 200k mensajes en una carpeta, Maildir castigará a tu sistema de archivos a menos que gestiones el particionado de carpetas.
2. ¿Estás limitado por inodos? Si df -ih tiende por encima del 70% y sigue creciendo, trátalo como un problema de escalado, no como una simple etiqueta de advertencia.
3. ¿Tienes backups basados en snapshots? Si no, arregla eso antes de cambiar formatos. Si no, solo cambiarás la forma de la inconsistencia de backups.
4. ¿Necesitas recuperación parcial fácil? Maildir tiende a ser más amigable para recuperación quirúrgica. mdbox puede estar bien, pero necesitas herramientas y procesos practicados.
5. ¿Cuál es tu sistema de archivos? Mide operaciones de buzón en el sistema de archivos y kernel reales que vas a ejecutar. Las cargas de correo son intensivas en metadatos y raras.
6. ¿Tienes tiempo de personal para mantenimiento? Si no, elige la vía con las operaciones day-2 más simples: Maildir más buen snapshotting.

Plan de migración: Maildir → mdbox (secuencia relativamente segura)

1. Inventaría usuarios e identifica buzones calientes (carpetas grandes, churn intenso).
2. Implementa backups basados en snapshot y realiza un ensayo de restauración antes de migrar.
3. Prepara un servidor de staging con la versión y configuración objetivo de Dovecot.
4. Migra un grupo piloto pequeño primero. Monitoriza latencia IMAP, tiempo de reconstrucción de índices y problemas visibles por usuarios.
5. Programa migraciones fuera de horas. Limita la concurrencia. No migres a todos a la vez a menos que disfrutes vivir peligrosamente.
6. Después de cada lote: reconstruye índices, valida recuentos de buzones y observa tormentas de resync en clientes.
7. Mantén capacidad de rollback vía snapshots y un marcador claro de corte.

Lista operativa base (independientemente del formato)

• Backups basados en snapshot con restauraciones probadas.
• Monitoreo de uso de inodos, crecimiento de directorios y crecimiento de volumen de correo.
• Monitoreo de latencia de almacenamiento (await) y errores del kernel relacionados con almacenamiento.
• Procedimientos definidos para reconstrucción de índices y reparación de buzones.
• Controles sobre el comportamiento de clientes cuando sea posible (los patrones de sync agresivos pueden hacerte un DOS).

Preguntas frecuentes

1) ¿Maildir siempre es más seguro que mdbox?

No. Maildir suele tener un radio de impacto menor por corrupción de un solo archivo, pero puede fallar espectacularmente por extenuación de inodos y sobrecarga de metadatos. “Más seguro” depende de lo que sea más probable que estropees.

2) ¿mdbox siempre es más rápido?

No. mdbox puede reducir la sobrecarga de archivos pequeños, pero si tu cuello de botella es churn de índices, ajustes de sync o latencia de almacenamiento lenta, no lo arreglará mágicamente. También puede añadir complejidad durante reparaciones y restauraciones.

3) ¿Cuál es la mayor razón por la que los sistemas Maildir se vuelven lentos con el tiempo?

El crecimiento del recuento de archivos más las operaciones de metadatos. El sistema no se ralentiza linealmente; se ralentiza cuando los directorios se vuelven enormes, los backups comienzan a arrastrarse y el uso de inodos se acerca al precipicio.

4) ¿Cuál es la mayor razón por la que los sistemas mdbox se vuelven problemáticos?

La dependencia operativa en metadatos gestionados por Dovecot y la necesidad de copias consistentes. Si no snapshotteas, puedes restaurar un buzón que existe pero que no “tiene sentido” para Dovecot hasta que lo repares.

5) ¿Debería almacenar correo en NFS?

Sólo si entiendes la semántica de bloqueo del servidor/cliente NFS, las características de latencia y el comportamiento bajo carga. El almacenamiento de correo es intensivo en metadatos y sensible a picos de latencia. Muchos problemas “misteriosos” de correo son simplemente almacenamiento en red portándose mal.

6) ¿Puedo mezclar formatos en el mismo sistema?

Sí, y a veces es la respuesta pragmática: mantiene a la mayoría de usuarios en Maildir y mueve cuentas de alto volumen e intensivas en inodos a mdbox. Solo asegúrate de que tus herramientas operativas cubran ambos.

7) ¿Los snapshots reemplazan la replicación de Dovecot?

No. Los snapshots te ayudan a retroceder y restaurar. La replicación te ayuda a mantener disponibilidad. Resuelven problemas distintos y fallan de formas distintas.

8) ¿Cómo sé si es corrupción de índices o pérdida real de mensajes?

Compara la realidad del sistema de archivos con la vista IMAP. Si los mensajes existen en disco (archivos maildir o almacenamiento mdbox) pero no aparecen, reconstruye índices. Si no existen en disco, es pérdida y necesitas restauraciones.

9) ¿Cuál es el mantenimiento “mínimo viable” para una capa de almacenamiento Dovecot sana?

Backups basados en snapshot, ejercicios periódicos de restauración, monitoreo de uso de inodos y latencia de almacenamiento, y un runbook para reconstrucción/reparación de índices. Todo lo demás es optimización.

Próximos pasos que puedes hacer esta semana

1. Ejecuta lo básico: doveconf -n, df -ih, iostat -x y doveadm mailbox status en un usuario caliente. Anota qué es realmente cierto.
2. Verifica la consistencia de backups: Si no snapshotteas, trata tus backups como “copias a mejor esfuerzo”, no como restauraciones en las que te jugarías tu puesto.
3. Haz un ensayo de restauración: Elige un buzón, restaúralo en un entorno aislado, reconstruye índices, valida IMAP. Mide el tiempo. Documenta el proceso.
4. Identifica el precipicio de crecimiento: Inodos, carpetas enormes y latencia de almacenamiento son los tres grandes. Pon alertas en ellos.
5. Decide con intención: Si tu dolor es inodos y sobrecarga de metadatos, mdbox podría ser el movimiento. Si tu dolor es recuperabilidad y simplicidad operativa, mantén Maildir y escala el sistema de archivos y el enfoque de backups correctamente.

Elige el formato que coincida con tu presupuesto de fallos y tu realidad de restauración. Tu yo del futuro será quien esté de guardia. No le hagas una broma pesada.