Corrupción de buzones en Dovecot: pasos de recuperación que minimizan daños

Un modelo mental práctico: qué significa “corrupción” en Dovecot

Dovecot no es un “almacén de correo” monolítico. Es un conjunto de comportamientos superpuestos sobre tu formato de almacenamiento elegido (Maildir, mdbox, sdbox) más metadatos (índices, cachés, listas de UID), más funciones opcionales (cuotas, búsqueda de texto completo), más comportamiento del cliente (IMAP IDLE, CONDSTORE, QRESYNC).

La corrupción de buzones en Dovecot suele significar una de tres cosas:

1. Los metadatos discrepan con la realidad. Los archivos de índice dicen que el mensaje X existe, pero el archivo o registro subyacente no (o al revés). La mayoría de los tickets de “corrupción” aterrizan aquí.
2. El almacenamiento subyacente es inconsistente. Los nombres de archivo de Maildir están dañados, duplicados, parcialmente escritos; o el mapa/log de mdbox se desincronizó; o el sistema de archivos devolvió datos parciales/obsoletos. Aquí es donde “minimizar daños” importa más.
3. La vista del cliente es incompatible con lo que el servidor ahora afirma. Cambios de UIDVALIDITY, reinicios de modseq, errores de “unknown UID”. El servidor puede estar en lo correcto, pero aún debes manejar las consecuencias en los clientes.

Qué no hacer: tratar la corrupción como un solo bug con una sola solución. Es un desajuste entre capas. Tu trabajo es identificar qué capa está “mintiendo” y luego forzar una reconciliación controlada en la dirección más segura.

Dirección por defecto más segura: preferir el almacenamiento de mensajes subyacente como fuente de la verdad y luego reconstruir los metadatos. Pero si el almacenamiento subyacente está dañado, puede que necesites tomar una instantánea, copiar lo que sea legible y reconstruir el almacén a partir de los mensajes extraídos.

Además: la “corrupción” suele ser solo el síntoma de otra cosa: fallos de almacenamiento, antivirus que escanean en sitio, semánticas defectuosas de sistemas de ficheros en red o un script de migración demasiado ingenioso.

Una cita que vale la pena pegar en la pizarra: (idea parafraseada) “La esperanza no es una estrategia” — a menudo atribuida en círculos de operaciones a ingenieros como Gene Kranz. En la reparación de buzones, la esperanza es como sobrescribes la última copia buena.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el orden que te lleva al cuello de botella más rápido, con el menor daño autoinfligido.

Primero: confirma el radio de afectación y si todavía hay escrituras

• ¿Es un usuario, un buzón, o todo el sistema?
• ¿Los clientes siguen escribiendo (entrega de correo nuevo, IMAP APPEND, cambios de flags)?
• ¿Ves errores activos del sistema de archivos o del disco?

Si hay escrituras en curso y el almacén es inestable, no estás “reparando”, estás apostando. Congela o aísla.

Segundo: clasifica la falla por la firma en los logs

• Índices/cachés: “Corrupted index file”, “cache file is corrupted”, “index header mismatch”. Normalmente reparable con reconstrucción de índices.
• UID/UIDVALIDITY: “UIDVALIDITY changed”, “Invalid UIDNEXT”, “uidlist corruption”. Más impacto en clientes, pero aún típicamente reconstrucción de metadatos.
• Capa de almacenamiento: “read() failed”, “Short read”, “mbox map corrupted”, “mdbox: rebuild failed”, “Invalid message size”. Esto puede ser daño real en los datos.

Tercero: decide la postura de recuperación

1. Reparación no destructiva: snapshot/backup, detener escrituras, reconstruir índices, forzar resync.
2. Reconstrucción controlada: exportar lo legible (o dsync desde réplica), construir un buzón limpio, reimportar.
3. Modo forense: preservar todo, hacer una copia y trabajar sobre la copia cuando hay asuntos legales/compliance.

Antes de tocar nada: reglas de seguridad que previenen daños

La recuperación de buzones es una de esas tareas donde la herramienta hará exactamente lo que pediste, no lo que querías. Tu directiva principal es evitar convertir una inconsistencia local en un borrado irreversible.

Regla 1: Congelar escrituras o aislar el buzón

Reconstruir metadatos mientras el buzón está siendo modificado es como obtener corrupción repetida, desplazamiento de UIDNEXT y clientes que nunca convergen. Para un usuario, puedes deshabilitar temporalmente su login o redirigirlo a un host de mantenimiento. Para todo un backend, podrías detener IMAP/LMTP brevemente o drenar el proxy.

Regla 2: Tomar una instantánea/backup del directorio del buzón (y de los índices)

Sí, también los índices. A veces el índice “corrupto” contiene el único mapa a un archivo de mensaje que fue renombrado o desplazado, especialmente con migraciones parciales.

Regla 3: Trabaja sobre una copia cuando el propio almacén pueda estar dañado

Si el sistema de archivos está reportando errores, no ejecutes comandos de reparación agresivos sobre la única copia. Clona el volumen o al menos rsync el árbol de buzones a un almacenamiento sano.

Regla 4: Preferir reconstruir sobre “ediciones quirúrgicas”

Editar a mano archivos de índice de Dovecot es el equivalente en correo de editar un archivo de base de datos con un editor hex porque “es más rápido”. No lo es, y no funcionará bien.

Broma corta #1: La corrupción de buzones es como el glitter: crees que lo limpiaste y luego aparece en tus logs por tres semanas más.

Hechos y contexto histórico (por qué existen estas fallas)

• Los archivos de índice de Dovecot son una optimización, no la fuente de la verdad. Existen para acelerar IMAP: búsquedas rápidas de flags, ordenación, threading y caché.
• Maildir fue diseñado para entregas concurrentes seguras usando semánticas de nombre de archivo, pero asume un sistema de archivos que ofrece rename atómico y operaciones de directorio consistentes.
• UIDVALIDITY de IMAP es un contrato con los clientes. Cámbialo y los clientes pueden tratarlo como otro buzón; algunos re-sincronizan, otros duplican y otros se quejan.
• “dsync” nació por las necesidades de replicación de Dovecot y ahora es una herramienta útil de reparación porque fuerza una vista consistente re-recorrendo el almacén.
• mdbox/sdbox existen en gran parte porque el “un archivo por mensaje” de Maildir no siempre es amable con los discos (presión de inodos, escalado de directorios, sobrecarga en backups). Cambian simplicidad del sistema de archivos por consistencia administrada por Dovecot.
• Muchos informes de corrupción son en realidad bugs de semánticas de almacenamiento—particularmente sistemas de archivos en red que no se comportan como POSIX local bajo presión de rename/fsync.
• Dovecot históricamente ha sido exigente con la versionización de índices. Las actualizaciones pueden disparar reconstrucciones de índices; mezclar binarios viejos y nuevos contra los mismos índices puede crear confusión.
• Los índices de búsqueda de texto completo (FTS) son independientes de los índices del buzón y pueden estar incorrectos mientras el correo está bien. Los usuarios suelen llamar a esto “correos perdidos”. Normalmente es “resultados de búsqueda faltantes”.

Esto no son excusas. Son pistas. Los modos de falla están moldeados por décadas de expectativas IMAP y la verdad incómoda de que el correo es un sistema distribuido con opiniones.

Triage por formato de almacenamiento: Maildir vs mdbox/sdbox

Maildir: tus mensajes son archivos

Con Maildir, la corrupción a menudo significa inconsistencias de directorio y nombre de archivo:

• Mensajes existen en tmp/ que nunca se movieron a new/ o cur/.
• Nombres duplicados o nombres base no únicos (usualmente por comportamiento defectuoso del agente de entrega).
• Clientes y servidor discrepan en flags porque los nombres de archivo codifican flags y las cachés de metadatos quedan desfasadas.
• Problemas del sistema de archivos causan escrituras parciales o rarezas en las entradas de directorio.

Postura de recuperación: preservar el árbol de directorios y luego reconstruir los índices/cachés de Dovecot. Si los archivos de mensaje están dañados, entras en territorio de extracción.

mdbox/sdbox: tus mensajes son registros y Dovecot gestiona mapas

Con mdbox, los mensajes se almacenan en archivos más grandes y Dovecot usa mapeo/indexación para localizar registros de mensajes. La corrupción puede manifestarse como:

• Desajuste mapa/índice: los metadatos apuntan a un registro que no se puede parsear.
• Corrupción de log o mapa tras un cierre no limpio o un fallo de almacenamiento.
• Eventos de disco lleno que truncan una escritura a mitad de registro.

Postura de recuperación: ser conservador. Hacer snapshot primero. Reconstruir metadatos con herramientas de Dovecot; evitar “arreglar” borrando archivos al azar en dovecot.index* a menos que comprendas el formato y el alcance.

Tareas prácticas: comandos + qué significa la salida + la decisión que tomas

Estas son las tareas que realmente ejecuto. Cada una incluye qué buscar y qué decisión impulsa. Ajusta rutas para tu instalación y base de datos de usuarios.

Tarea 1: Identificar el buzón fallido y la firma del error

cr0x@server:~$ sudo journalctl -u dovecot --since "2 hours ago" | egrep -i "corrupt|uidvalidity|uidnext|index|mdbox|sdbox|short read|internal error" | tail -n 30
Jan 03 10:41:12 mx1 dovecot[2219]: imap(user@example.com)<11234>: Error: Mailbox INBOX: Corrupted index file /var/vmail/example.com/user/dovecot.index: Header size mismatch
Jan 03 10:41:14 mx1 dovecot[2219]: imap(user@example.com)<11234>: Error: Mailbox INBOX: UIDVALIDITY changed (14211 -> 18602)

Significado: Tienes una firma de corrupción de índices, más cambio de UIDVALIDITY (o al menos Dovecot piensa que cambió). Eso probablemente sea territorio de reconstrucción de metadatos, pero debes detener escrituras o arriesgar churn.

Decisión: Poner el buzón afectado en modo mantenimiento (bloquear login o redirigir el usuario), luego snapshot antes de las reparaciones.

Tarea 2: Confirmar versión de Dovecot y backend de almacenamiento

cr0x@server:~$ dovecot --version
2.3.19.1
cr0x@server:~$ doveconf -n | egrep -i "mail_location|mail_driver|mail_home|namespace inbox|mail_plugins"
mail_location = maildir:/var/vmail/%d/%n
mail_plugins = quota fts fts_lucene

Significado: Es Maildir y tienes quota + FTS. Espera problemas separados de FTS y necesidad de recálculo de cuotas tras las reparaciones.

Decisión: Planear reconstruir índices del buzón primero; reconstruir índices FTS solo después de que el correo sea consistente.

Tarea 3: Verificar señales de salud del sistema de archivos (no reparar en un disco moribundo)

cr0x@server:~$ dmesg -T | egrep -i "ext4|xfs|btrfs|zfs|I/O error|blk_update_request|nvme|ata|sense" | tail -n 20
[Fri Jan  3 10:35:22 2026] EXT4-fs warning (device sdb1): ext4_end_bio:342: I/O error 10 writing to inode 928381 (offset 0 size 4096 starting block 1234567)

Significado: Tienes errores de I/O de escritura. Si reconstruyes índices ahora, podrías estar escribiendo más metadatos en un sistema de archivos que falla.

Decisión: Detener. Estabilizar el almacenamiento primero: failover, remontar como solo lectura si es necesario, o restaurar desde snapshot/réplica.

Tarea 4: Comprobar espacio libre y disponibilidad de inodos (asesino silencioso clásico)

cr0x@server:~$ df -h /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       2.0T  1.9T   12G 100% /var/vmail
cr0x@server:~$ df -i /var/vmail
Filesystem     Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1     61054976 61054912     64  100% /var/vmail

Significado: Disco lleno y sin inodos. Maildir fallará de maneras entretenidas porque no puede crear nuevos archivos para entregas o reconstrucciones de índices.

Decisión: Liberar espacio/inodos primero, luego abordar la corrupción. Si no, lo “arreglarás” y lo dejarás peor.

Tarea 5: Snapshot/backup del directorio del buzón antes de cambios

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --info=progress2 /var/vmail/example.com/user/ /srv/recovery-snapshots/example.com/user-2026-01-03/
...output...

Significado: Ahora tienes una copia puntual que puedes comparar y desde la que puedes revertir. Si rsync da errores, eso en sí es una señal de integridad de almacenamiento.

Decisión: Si rsync informa errores de lectura, pasar a modo forense: clonar el sistema de archivos y evitar más escrituras.

Tarea 6: Verificar lista de buzones y acceso básico con doveadm (chequeo solo lectura)

cr0x@server:~$ sudo doveadm mailbox list -u user@example.com | head
INBOX
Sent
Drafts
Trash
Archive

Significado: Dovecot puede enumerar buzones. Si esto falla con errores internos, la corrupción puede ser más amplia que una sola carpeta.

Decisión: Si la lista falla, sospecha configuración de namespace, permisos o corrupción severa de índices; planear reconstrucción más amplia de índices.

Tarea 7: Comprobar el estado del buzón por contadores inconsistentes

cr0x@server:~$ sudo doveadm mailbox status -u user@example.com messages unread uidvalidity uidnext highestmodseq vsize INBOX
messages=842 unread=19 uidvalidity=18602 uidnext=901 highestmodseq=120044 vsize=188392012

Significado: Obtienes una línea de estado coherente. Si uidnext es menor que messages o aparecen errores, probablemente necesites un resync.

Decisión: Si los contadores UID parecen erróneos, programar doveadm force-resync después de backup y congelar escrituras.

Tarea 8: Forzar un resync de buzón (reconstrucción de metadatos sin borrar correo)

cr0x@server:~$ sudo doveadm force-resync -u user@example.com INBOX
cr0x@server:~$ sudo doveadm mailbox status -u user@example.com messages unread uidvalidity uidnext INBOX
messages=842 unread=19 uidvalidity=18602 uidnext=902

Significado: Dovecot re-recorró el almacenamiento y reconstruyó metadatos clave. UIDNEXT cambió en uno, lo cual puede ser normal tras la reconciliación.

Decisión: Si persisten errores, reconstruir explícitamente índices (siguiente tarea) y comprobar daños en el sistema de archivos.

Tarea 9: Reconstruir índices de Dovecot para un usuario (agresivo pero común)

cr0x@server:~$ sudo doveadm index -u user@example.com -q INBOX
cr0x@server:~$ sudo doveadm index -u user@example.com -q '*'

Significado: Recrea datos de índice. La bandera -q reduce el ruido; revisa logs para cualquier “corrupt” durante el indexado.

Decisión: Si la indexación dispara “read() failed” o “Short read”, trátalo como daño de almacenamiento/mensaje, no solo metadatos.

Tarea 10: Eliminar solo archivos de índice/caché (último recurso, pero a veces necesario)

cr0x@server:~$ sudo find /var/vmail/example.com/user/ -maxdepth 2 -type f -name "dovecot.index*" -o -name "dovecot-uidlist" -o -name "dovecot-uidvalidity" -o -name "dovecot.list.index*" -print
/var/vmail.example.com/user/dovecot-uidlist
/var/vmail.example.com/user/dovecot.index
/var/vmail.example.com/user/dovecot.index.cache
cr0x@server:~$ sudo mv /var/vmail/example.com/user/dovecot.index /var/vmail/example.com/user/dovecot.index.bak
cr0x@server:~$ sudo mv /var/vmail/example.com/user/dovecot.index.cache /var/vmail.example.com/user/dovecot.index.cache.bak
cr0x@server:~$ sudo mv /var/vmail/example.com/user/dovecot-uidlist /var/vmail.example.com/user/dovecot-uidlist.bak

Significado: Has eliminado archivos de metadatos para forzar que Dovecot los recree desde Maildir. Esto puede cambiar UIDs y molestar a los clientes, pero a menudo es el reinicio más limpio.

Decisión: Haz esto solo después del backup y tras detener escrituras. Si los clientes soportan QRESYNC, espera una resync; si no, espera descargas más pesadas.

Tarea 11: Detectar mensajes “varados” en Maildir tmp/ (entrega interrumpida)

cr0x@server:~$ sudo find /var/vmail/example.com/user/Maildir/tmp -type f | head
/var/vmail/example.com/user/Maildir/tmp/1704271042.M12345P6789.mx1,S=2048,W=2090
cr0x@server:~$ sudo find /var/vmail/example.com/user/Maildir/tmp -type f | wc -l
17

Significado: Mensajes atascados en tmp/ pueden ser invisibles para los clientes. Pueden estar parcialmente escritos o simplemente nunca renombrados por falta de disco o crash.

Decisión: Inspecciona algunos archivos (tamaño, headers). Si están sanos, puedes moverlos a new/ con cautela; si no, preservarlos para forense y no inyectar basura.

Tarea 12: Inspeccionar un archivo de mensaje sospechoso sin mutarlo

cr0x@server:~$ sudo ls -lh /var/vmail/example.com/user/Maildir/tmp/1704271042.M12345P6789.mx1,S=2048,W=2090
-rw------- 1 vmail vmail 2.0K Jan  3 10:30 /var/vmail/example.com/user/Maildir/tmp/1704271042.M12345P6789.mx1,S=2048,W=2090
cr0x@server:~$ sudo head -n 20 /var/vmail/example.com/user/Maildir/tmp/1704271042.M12345P6789.mx1,S=2048,W=2090
Return-Path: <sender@example.net>
Delivered-To: user@example.com
Received: by mx1 with LMTP id 7xYk...; Fri, 03 Jan 2026 10:30:41 +0000
Date: Fri, 03 Jan 2026 10:30:40 +0000
From: Sender <sender@example.net>
To: user@example.com
Subject: test
Message-ID: <...>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

Significado: Parece un mensaje RFC 5322 válido. Buena señal.

Decisión: Si es válido, puedes moverlo a new/ (con permisos correctos) y resync. Si los headers faltan/están dañados, mantenerlo en cuarentena.

Tarea 13: Mover con seguridad mensajes tmp varados a new/ (solo después de confirmar)

cr0x@server:~$ sudo sh -c 'for f in /var/vmail/example.com/user/Maildir/tmp/*; do test -f "$f" && mv -n "$f" /var/vmail/example.com/user/Maildir/new/; done'
cr0x@server:~$ sudo doveadm force-resync -u user@example.com INBOX

Significado: Los mensajes ahora son detectables. El -n evita sobrescribir si ocurre una colisión de nombres.

Decisión: Si hay colisiones, detente e investiga por qué los nombres no son únicos—probablemente un agente de entrega defectuoso o snapshots restaurados mezclados.

Tarea 14: Recalcular cuotas (después de las reparaciones; las cuotas pueden fallar)

cr0x@server:~$ sudo doveadm quota get -u user@example.com
Quota name=User quota Type=STORAGE Value=2048M Limit=2048M %
cr0x@server:~$ sudo doveadm quota recalc -u user@example.com
cr0x@server:~$ sudo doveadm quota get -u user@example.com
Quota name=User quota Type=STORAGE Value=1460M Limit=2048M %

Significado: Antes del recálculo, el sistema de cuotas puede haber contado mensajes que no estaban presentes (o faltar mensajes que sí estaban). Tras el recalc, coincide con la realidad.

Decisión: Si los usuarios reportan “buzón lleno” después de las reparaciones, ejecutar recálculo de cuotas. No aumentes límites a ciegas; eso oculta problemas reales de almacenamiento.

Tarea 15: Diagnosticar confusión de FTS (búsqueda rota, correo bien)

cr0x@server:~$ sudo doveadm fts rescan -u user@example.com INBOX
cr0x@server:~$ sudo doveadm fts optimize -u user@example.com

Significado: FTS se reconstruye por separado. Esto arregla “la búsqueda no encuentra el correo que estoy viendo”.

Decisión: Hacer esto solo después de que los índices del buzón sean estables; de lo contrario indexas basura dos veces.

Tarea 16: Usar dsync como “aplicador de la verdad” (genial con réplicas)

cr0x@server:~$ sudo doveadm dsync -u user@example.com backup -R -f /var/vmail/example.com/user/ "remote:replica-user@example.com"
dsync(user@example.com): info: Sync: mailbox INBOX: 842 messages, 0 expunges, 2 flag changes

Significado: Dsync reconcilia diferencias entre dos almacenes. En modo backup, prefiere el lado local como fuente de la verdad; cambia la dirección con cuidado.

Decisión: Si el almacén local está dañado y la réplica está bien, ejecutar dsync en la dirección que sobrescriba el local con la réplica, pero solo después de snapshotear el local dañado.

Broma corta #2: La segunda cosa más peligrosa en un servidor de correo es un “arreglo rápido”. La primera es un “arreglo rápido” ejecutado como root sin una instantánea.

Listas de verificación / plan paso a paso (recuperación minimizando daños)

Elige el camino que coincida con tu situación. El error es tratar toda corrupción como una reconstrucción de índices.

Plan A: Solo corrupción de índices (más común, menos aterrador)

1. Confirmar alcance. ¿Es un buzón o muchos? Usa logs y doveadm mailbox status.
2. Congelar escrituras para ese buzón. Bloquear temporalmente el login del usuario o moverlo a un backend de mantenimiento.
3. Snapshot/backup del directorio del buzón. Incluir archivos ocultos y dovecot.*.
4. Ejecutar un resync. doveadm force-resync -u user@example.com INBOX
5. Reconstruir índices. doveadm index -u user@example.com -q '*'
6. Recalcular cuotas. Si usas cuota: doveadm quota recalc
7. Reconstruir FTS si los usuarios se quejan de la búsqueda.
8. Descongelar escrituras y vigilar logs. Si los errores se repiten de inmediato, detener y revisar almacenamiento/semánticas de entrega.

Plan B: Inconsistencias de directorio Maildir (desorden tmp/new/cur)

1. Congelar escrituras. Entrega + cambios IMAP deben pausarse para este buzón.
2. Respaldar todo el Maildir. Quieres preservar la versión desordenada.
3. Contar archivos tmp varados. Si son pocos, inspecciona; si son miles, tienes un problema sistémico de entrega/fsync.
4. Validar una muestra de archivos tmp. Comprobar headers y plausibilidad de tamaño.
5. Mover archivos tmp válidos a new/ usando movimientos sin sobreescritura.
6. Eliminar/reconstruir índices. Apartar dovecot.index* y dovecot-uidlist, luego resync.
7. Comunicación a usuarios. Pedirles reiniciar clientes; algunos volverán a descargar cabeceras. Si cambia UIDVALIDITY, avisar sobre duplicados en algunos clientes.

Plan C: Sospecha de daño en el almacenamiento subyacente (errores I/O, short reads, registros truncados)

1. Detener escrituras inmediatamente. Si es posible, remontar almacenamiento de correo como solo lectura o hacer failover.
2. Obtener una copia byte a byte o instantánea. Trabajar sobre la copia.
3. Intentar reconstrucciones no destructivas de Dovecot sobre la copia primero. Si fallan con errores de lectura, no sigas insistiendo.
4. Extraer mensajes legibles. Para Maildir, copiar archivos intactos. Para mdbox, usar herramientas de Dovecot para exportar si es posible.
5. Restaurar desde réplica/backup las partes faltantes. Dsync puede ayudar a conciliar.
6. Levantar un almacén de buzones limpio. Importar mensajes extraídos en un buzón nuevo y luego cambiar a los clientes.
7. Postmortem del evento de almacenamiento. Corregir la causa raíz: disco, controlador, semánticas de FS en red o planificación de capacidad.

Plan D: Existe réplica y parece sana (el plan “usar la segunda copia”)

1. Verificar señales de salud de la réplica. Confirmar que la réplica puede servir el buzón sin errores.
2. Snapshot de ambos lados. Sí, incluso del bueno. Errores en replicación pueden ser desastres simétricos.
3. Elegir la dirección deliberadamente. Si el primario está corrupto, preferir la réplica como fuente de la verdad.
4. Ejecutar dsync en el modo correcto. Hacer pruebas pequeñas en un buzón primero.
5. Validar conteos de mensajes y comprobar una muestra de correo reciente.
6. Reactivar el tráfico normal y monitorizar.

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

1) Síntoma: “Correos perdidos” pero solo la búsqueda está rota

Causa raíz: Corrupción o desfase del índice FTS; el buzón está bien.

Solución: Ejecutar doveadm fts rescan para usuarios/buzones afectados tras estabilizar los índices del buzón.

2) Síntoma: UIDVALIDITY cambió; los clientes duplican o vuelven a descargar todo

Causa raíz: Se eliminó/volvió a crear dovecot-uidvalidity o una reconstrucción forzada que reseteó UIDVALIDITY; o el buzón fue recreado durante una migración.

Solución: Evitar borrar UIDVALIDITY salvo que sea necesario. Si ya cambió, comunicar pasos a los usuarios; para clientes tercos, quitar y volver a añadir la cuenta suele ser la solución más limpia del lado cliente.

3) Síntoma: Reconstruir índices “funciona” pero la corrupción vuelve a diario

Causa raíz: Problema de semánticas del almacenamiento subyacente (FS en red, antivirus, herramienta de backup que altera archivos), o errores de disco, o espacio agotado.

Solución: Investigar dmesg, opciones de montaje y agentes terceros que tocan archivos. Arreglar el entorno y luego reconstruir una sola vez.

4) Síntoma: Muchos mensajes atascados en tmp/ y entregas nuevas intermitentemente faltantes

Causa raíz: Disco lleno / agotamiento de inodos / crash durante entrega / comportamiento roto de LMTP/LDA.

Solución: Resolver la capacidad. Luego validar y mover tmp a new, seguido de force-resync.

5) Síntoma: “Internal error occurred. Refer to server log” al abrir un buzón

Causa raíz: Desajuste de permisos/propiedad tras una restauración, o índices creados por un UID equivocado, o herencia de ACL rota.

Solución: Verificar propiedad del sistema de archivos y expectativas de Dovecot para mail_uid/mail_gid; corregir permisos y luego reconstruir índices.

6) Síntoma: mdbox muestra huecos repentinos, “Invalid message size”

Causa raíz: Archivo mdbox truncado por evento de disco lleno o error de I/O durante la escritura.

Solución: Snapshot, intentar reconstrucción/export en una copia, restaurar mensajes faltantes desde réplica/backup. No “rm archivos al azar”.

7) Síntoma: Una carpeta rota, otras bien; error menciona dovecot.list.index

Causa raíz: Corrupción del índice de lista de buzones, a veces tras un cierre abrupto o binarios de distintas versiones mezclados.

Solución: Mover a un lado dovecot.list.index* para el usuario, luego dejar que Dovecot regenere listando buzones y resyncando.

8) Síntoma: Las reparaciones causan caos en flags de mensajes (cambios leído/no leído)

Causa raíz: Flags de Maildir en los nombres de archivo discrepan con la caché; o los clientes re-aplican estado cacheado tras reconectar.

Solución: Reconstruir índices; luego dejar una ventana de estabilización. Para usuarios clave, recomendar reiniciar clientes después de la reparación del servidor.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una compañía mediana ejecutaba Dovecot con Maildir sobre un sistema de archivos en red. El equipo asumió que “son solo ficheros” significaba que se comportaría como disco local. Funcionó durante meses, que es como las suposiciones se promocionan a “hechos”.

Entonces ocurrió una ventana de mantenimiento: un failover de almacenamiento, una breve pausa y un puñado de clientes que nunca dejaron de sincronizar. El lunes por la mañana: usuarios reportaron correos perdidos en Sent, pero solo en ciertas subcarpetas. Los logs mostraron corrupción intermitente de índices y ocasionales “short read”.

La respuesta inicial fue predecible: reconstruir índices para los usuarios afectados uno por uno. Ayudó unas horas, luego los mismos buzones volvieron a “corromperse”. Alguien intentó un enfoque más agresivo—eliminar dovecot.* a lo ancho—porque había funcionado una vez en laboratorio. Esto disparó cambios de UIDVALIDITY para un grupo de buzones y los clientes respondieron re-descargando, duplicando y esencialmente convirtiendo la cola de helpdesk en arte performático.

La causa raíz no era Dovecot. El sistema de archivos en red no respetaba de forma fiable las semánticas esperadas de rename+fsync bajo failover. Maildir depende de esas operaciones para presentar una transición atómica de “mensaje aparece”. Bajo estrés, las transiciones tmp/new se volvían extrañas y los índices de Dovecot eran solo el mensajero.

Lo arreglaron mudando el almacenamiento de correo a disco local en los nodos de correo y usando replicación correcta a nivel de Dovecot. Las reconstrucciones de índices dejaron de ser un ritual diario. La lección: un sistema que “generalmente se comporta como POSIX” no es lo mismo que POSIX cuando el iPhone de tu CEO hace 20 operaciones IMAP por segundo.

Microhistoria 2: La optimización que salió mal

Otra organización quería backups más rápidos y menos inodos. Maildir pareció “ineficiente”, así que migraron a mdbox. Fue una decisión razonable con un costo oculto: la memoria operacional del equipo seguía siendo Maildir y sus runbooks todavía eran “simplemente mover archivos”.

También afinaron para velocidad: caching agresivo y una configuración FTS ocupada. Todo fue rápido, hasta un evento de disco lleno durante ingestión pico. Disco lleno no es dramático cuando ocurre; es aburrido, y después todo lo demás se vuelve dramático.

Tras el evento, un subconjunto de usuarios no pudo abrir su INBOX. Los logs incluían “Invalid message size” en mdbox y la reconstrucción de índices no lo resolvió. Alguien intentó borrar lo que parecía “solo índices” en el directorio mdbox. Eso lo empeoró porque removieron archivos de mapeo que no eran meramente cachés.

La recuperación funcionó, pero requirió disciplina: snapshot de lo que quedaba, restaurar desde réplica cuando fue posible y exportar/importar mensajes legibles para el resto. Su optimización entregó rendimiento, pero exigió mayor rigor en monitoreo de capacidad y mejor entendimiento de qué archivos eran metadatos vs esenciales.

La lección: las optimizaciones de rendimiento están bien. Pero cada optimización tiene un coste operativo. Si no lo pagas gradualmente (monitoreo, runbooks, formación), lo pagarás todo de una vez durante una incidencia.

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

Una empresa regulada ejecutaba Dovecot con replicación y una estricta política de “snapshot antes de mutar”. No era glamoroso. También significaba que on-call tenía una respuesta inicial más lenta, porque cada runbook empezaba con “congelar, snapshotear, verificar”.

Un día, un lote de buzones empezó a lanzar errores de corrupción de índices tras un evento de pérdida de energía no limpio. Los usuarios eran ruidosos; la dirección más. El SRE de guardia siguió la lista aburrida de todas formas: aislar un buzón, snapshotearlo, intentar force-resync, reconstruir índices y luego verificar con un conjunto pequeño de comprobaciones doveadm status.

Para el puñado de buzones que aún fallaban, no reventaron el sistema. Inmediatamente cambiaron esos usuarios a la réplica y luego usaron dsync para conciliar cuando el primario estuvo estable. No hubo ediciones manuales. No hubo borrados aleatorios. No hubo bucles de “probar y ver”.

Porque tenían snapshots antes de cada mutación, pudieron revertir un par de intentos desafortunados de un ingeniero junior sin drama. Los auditores luego preguntaron cómo aseguraban la integridad durante la recuperación. La respuesta fue aburrida, precisa y correcta: snapshots inmutables más reconstrucciones controladas. Ese tipo de aburrido mantiene tus fines de semana intactos.

Preguntas frecuentes

1) ¿Debo borrar dovecot.index para arreglar la corrupción?

A veces, sí—pero solo después de un backup/snapshot y después de detener escrituras para ese buzón. Prefiere doveadm force-resync y doveadm index primero. Borrar archivos de índice puede causar cambios de UID/flags y dolor en la resync de clientes.

2) ¿Borra doveadm force-resync mensajes?

Está diseñado para conciliar metadatos con el almacén subyacente, no para borrar correo. Pero si tu almacén subyacente no tiene mensajes que los índices referenciaban, el “resultado” es que esos mensajes ya no aparecen. Eso no es borrado por el comando; es la realidad siendo reconocida.

3) Los usuarios dicen que el correo desapareció, pero yo puedo ver archivos en Maildir. ¿Por qué?

Dovecot puede no verlos por corrupción de índices, problemas de permisos o porque están atascados en tmp/. Valida propiedad y ubicación, luego resync.

4) ¿Cómo manejo cambios de UIDVALIDITY con mínimo caos en clientes?

Evita provocarlos innecesariamente. Si ocurrieron, comunicar con claridad: los clientes pueden re-descargar o duplicar. Recomienda reiniciar clientes; para duplicados persistentes, quitar y volver a añadir la cuenta suele ser el reset más limpio en el cliente.

5) ¿Es Maildir “más seguro” que mdbox contra corrupción?

Maildir es más fácil de inspeccionar y rescatar a nivel de archivos. mdbox puede ser más eficiente y consistente bajo carga, pero requiere más respeto por metadatos gestionados por Dovecot. “Más seguro” depende de si tu equipo entiende el formato y si tu almacenamiento se comporta correctamente.

6) ¿Pueden antivirus o agentes de backup causar corrupción de buzones?

Sí. Cualquier cosa que modifique, bloquee, renombre o lea/escriba parcialmente archivos de mensaje y metadatos de dovecot puede crear inconsistencias. El fallo clásico es un agente que escanea en sitio y compite con la entrega o actualizaciones de índices.

7) ¿Cuál es la diferencia entre problemas de índice de buzón y problemas de FTS?

Los índices de buzón afectan el contenido de carpetas, flags y operaciones IMAP básicas. FTS afecta resultados de búsqueda. Los usuarios con frecuencia reportan fallos de FTS como “correo perdido” porque buscan en lugar de navegar.

8) ¿Debo ejecutar reparaciones mientras el servidor está en producción?

No si puedes evitarlo. Para un solo buzón a veces se puede, pero lo más seguro es congelar las escrituras para el alcance afectado. Reparar mientras los clientes martillan el buzón genera resultados no repetibles.

9) ¿Cómo sé si la corrupción la causa el sistema de archivos?

Busca errores de I/O en dmesg, advertencias del sistema de archivos y fallos de rsync/lectura al copiar maildirs. Si los errores correlacionan con eventos de almacenamiento (failover, disco lleno, picos de latencia), trata al almacenamiento como sospechoso principal.

10) Después de una reparación, ¿por qué los contadores de no leídos están mal?

El estado de no leídos es combinación de flags de mensajes y estado de índices/caché. Tras reconstruir, los contadores pueden cambiar para coincidir con lo que hay en disco. Algunos clientes también “reaplican” estado cacheado tras reconectar; da una ventana de estabilización.

Conclusión: próximos pasos que puedes hacer hoy

La recuperación de corrupción de buzones es principalmente cuestión de disciplina: detener escrituras, preservar evidencia, reconstruir metadatos desde la fuente de la verdad más segura y solo entonces preocuparse por añadidos de rendimiento como FTS. Cuando omites el snapshot o ignoras la salud del almacenamiento, conviertes una reparación en una reescritura de la historia.

Próximos pasos prácticos:

1. Añadir una puerta en el runbook: “snapshot antes de mutar” para cualquier reparación de buzón.
2. Instrumentar alertas de espacio en disco e inodos específicamente para almacenamiento de correo; disco lleno es una fábrica de corrupción.
3. Decidir tu política de “fuente de la verdad” por adelantado (primario vs réplica) y documentar elecciones de dirección de dsync.
4. Auditar agentes terceros (antivirus, backup, indexado) que tocan directamente el almacén de correo.
5. Practicar en una copia de staging: ejecutar doveadm force-resync, doveadm index, recálculo de cuotas y reconstrucción FTS para que on-call no aprenda durante una incidencia.

Si no te llevas otra cosa: haz menos cosas, pero con más cuidado. El correo es paciente; tus usuarios no lo son.