Cómo borrar los registros de auditoría de Zimbra para liberar espacio en disco de forma segura

Empieza por decidir qué es lo que realmente necesitas eliminar.

Un servidor Zimbra con poco espacio en disco puede hacer que la limpieza de registros parezca urgente, pero /opt/zimbra/log/audit.logno se trata solo de información de diagnóstico desechable. Zimbra la documenta como el registro de auditoría de eventos de autenticación y actividad administrativa. Esto significa que el mejor método de limpieza depende de si se necesita espacio inmediato, evidencia histórica o una solución de retención a largo plazo.

La opción más segura es dejar el audit.logarchivo activo intacto y ocuparse primero de las copias rotadas más antiguas. Si está sujeto a una política de retención interna, una retención legal o un requisito de cumplimiento, archive esos archivos en otro sistema de archivos antes de eliminar nada. Si el archivo activo ha alcanzado un tamaño anormalmente grande, puede borrarlo, pero esto debe considerarse una medida de emergencia, ya que elimina el historial de auditoría actual y puede generar un pequeño riesgo de concurrencia si el servidor continúa escribiendo mientras lo copia.

La propia documentación de registro de Zimbra sitúa a Log4j audit.logen /opt/zimbra/logy lo describe como el componente responsable de rotar archivos como audit.logy mailbox.log. Otros registros de Zimbra pueden usar la logrotateconfiguración del sistema operativo, así que no asuma que todos los archivos del directorio siguen el mismo mecanismo. Consulte la referencia oficial de archivos de registro de Zimbra y las notas sobre la rotación de registros de Zimbra .

Compare las opciones de limpieza antes de actuar.

Paso 1: Mida el problema antes de eliminar nada.

Primero, confirme que los registros de auditoría son realmente los responsables de la presión. Ejecútelos como root:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

El primer comando indica el grado de ocupación del sistema de archivos /opt. El segundo muestra el espacio total que ocupa el registro de Zimbra. El tercero revela el archivo de auditoría activo y las generaciones rotadas. Si los archivos de auditoría representan solo una pequeña fracción del sistema de archivos, eliminarlos podría no solucionar el problema; es posible que el espacio se esté consumiendo en su lugar mediante buzones de correo, copias de seguridad, archivos de base de datos u otro tipo de registro.

Anota también la versión instalada antes de modificar el comportamiento:

su - zimbra -c 'zmcontrol -v'

Esto es importante porque la documentación de Zimbra abarca varias generaciones de productos, y la sintaxis exacta de Log4j, la configuración generada y las tareas de limpieza pueden variar. No copie un valor de retención de un ejemplo antiguo de la wiki y lo asuma como su valor predeterminado actual.

Antes de decidir qué eliminar, compruebe el uso del sistema de archivos, el tamaño total del registro de Zimbra y las generaciones individuales de registros de auditoría.

Paso 2: Compruebe cómo este servidor rota y elimina los registros.

Zimbra documenta dos mecanismos relevantes: Log4j para archivos que incluyen audit.log, y el del sistema operativo logrotatepara otros registros de Zimbra. También señala que el crontab de Zimbra puede contener tareas de mantenimiento de registros. Revise la configuración en vivo en lugar de adivinar:

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

Si alguno de esos archivos no contiene la configuración esperada en su versión, revise la configuración de registro circundante en lugar de intentar usar un ejemplo anterior. Los archivos generados también pueden sobrescribirse tras reiniciar el servicio o regenerar la configuración. Las notas de registro de Zimbra distinguen específicamente las modificaciones temporales del archivo de propiedades generado de los cambios permanentes realizados en la .inplantilla correspondiente.

Para servidores con un volumen de auditoría inesperadamente alto, verifique si se habilitó intencionalmente el registro adicional. Las notas de la versión de Zimbra 10.0.6 documentan el zimbra_additional_loggingatributo de configuración local, que puede agregar más eventos de autenticación fallidos o útiles audit.log. No desactive el registro de seguridad útil solo para ahorrar espacio; si el volumen es legítimo, una mejor solución suele ser la retención, la compresión o el almacenamiento centralizado de registros. Consulte las notas de la versión oficial de Zimbra 10.0.6 .

Revise la configuración actual de crontab y Log4j del servidor antes de modificar el comportamiento de retención o rotación.

Paso 3: Priorice el archivado o la eliminación de los registros rotados.

Para la mayoría de los administradores, los registros de auditoría rotados antiguos son el mejor primer objetivo. Úselos finden modo de solo informe antes de eliminar cualquier cosa. El siguiente ejemplo muestra los registros de auditoría rotados con más de 30 días de antigüedad; 30 días es solo un umbral de ejemplo, no un período de retención prescrito por Zimbra:

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

Si esos archivos ya no son necesarios, elimine solo los archivos rotados que haya revisado. Si necesita conservarlos, cópielos o archívelos primero en un sistema de archivos diferente. Es importante usar otro punto de montaje cuando la partición de Zimbra está casi llena, ya que crear un archivo comprimido en el mismo sistema de archivos lleno puede consumir aún más espacio temporalmente.

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

Repita el proceso con los nombres de archivo exactos que revisó. Verifique la copia de seguridad antes de eliminar el origen. Evite patrones generales como rm -f /opt/zimbra/log/audit.log*; ese patrón también coincide con el archivo activo.

Si desea conservar los registros antiguos localmente pero reducir su tamaño, comprima solo los archivos rotados:

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

La conveniencia de la compresión depende de la configuración actual de rotación de registros. Algunas implementaciones ya comprimen los registros históricos como parte del mantenimiento. Verifique la configuración existente antes de añadir otra capa.

Las directrices de Zimbra sobre el registro histórico también advierten que los registros de auditoría pueden contener datos confidenciales. Aplique a los archivos los mismos controles de acceso que a los registros en tiempo real. Consulte las directrices oficiales de Zimbra sobre el registro .

Primero, enumere los archivos antiguos rotados, copie el historial necesario a un almacenamiento separado y solo entonces elimine las generaciones revisadas.

Cuándo está justificado truncar el archivo audit.log activo

Si el problema no reside en los archivos rotados, sino en el archivo activo audit.logque consume espacio crítico, el truncamiento puede liberar espacio de inmediato. Sin embargo, esta es la opción con la desventaja más evidente: el historial de auditoría actual se pierde al truncar el archivo.

Un procedimiento de emergencia más seguro consiste en detener brevemente mailboxd, copiar el archivo activo a otro sistema de archivos, truncar el original en el mismo lugar para que se conserven la propiedad y los permisos, y volver a iniciar mailboxd:

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

Esto provoca interrupciones en el servicio de correo, por lo que no es la opción adecuada para todos los entornos. Copiar el archivo activo sin detener mailboxd evita las interrupciones, pero crea una condición de carrera en la que se pueden perder las entradas escritas después de la copia y antes del truncamiento. Si la presión sobre el disco no es excesiva, es preferible limpiar los archivos rotados y corregir la retención.

No utilice rmel registro activo como primera opción. Un proceso puede seguir escribiendo a través de un descriptor de archivo abierto incluso después de que se elimine la entrada del directorio, por lo que el espacio en disco esperado podría no recuperarse de inmediato. Truncar el inodo existente es más predecible cuando realmente se necesita una limpieza de emergencia.

Paso 4: Verifique tanto la recuperación del disco como el registro continuo.

Tras la limpieza, confirme el resultado en lugar de confiar en la ausencia de errores:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

Un buen resultado se caracteriza por tres señales: el espacio libre en el sistema de archivos previsto ha aumentado, el audit.logsistema sigue activo y recibe nuevos eventos, y los servicios de Zimbra relevantes continúan en ejecución. Si dfel sistema de archivos sigue mostrando un nivel de llenado, aunque el espacio disponible duhaya disminuido drásticamente, compruebe si hay archivos eliminados que aún estén abiertos por procesos en ejecución antes de eliminar más datos.

Verifique el espacio recuperado, la actividad de auditoría reciente y el estado del servicio después de la limpieza.

Elija la solución a largo plazo en función de por qué crecieron los registros.

Si el crecimiento es normal pero la retención es demasiado prolongada

Ajuste el proceso de retención o eliminación solo después de documentar el período de historial requerido. Revise la configuración existente de crontab de Zimbra y Log4j, y luego realice el cambio mínimo que corresponda a la versión. Conserve una copia de la configuración original y compruebe que la siguiente rotación genere los archivos esperados.

Si el ruido de autenticación está impulsando el volumen

Es mejor investigar el origen del problema que simplemente eliminarlo rápidamente. Los intentos repetidos de inicio de sesión, los clientes mal configurados, las sondas de monitoreo o el registro de autenticación ampliado intencionalmente pueden aumentar el volumen de auditoría. Dado que audit.loges útil para la investigación de seguridad, reducir el ruido subyacente suele ser mejor que suprimir la evidencia.

Si debe conservar meses de historial de auditoría

Mueva o envíe los registros a un almacenamiento diseñado para su retención. El registro centralizado, el almacenamiento de objetos o un sistema de archivos de registro dedicado separan el historial de cumplimiento de la capacidad requerida por la plataforma de correo. La documentación de archivos de registro de Zimbra analiza explícitamente las opciones de registro centralizado, incluyendo audit.log.

Qué no hacer

• No elimine audit.log*con un comodín no revisado.
• No asuma /etc/logrotate.d/zimbraque controla el registro de auditoría activo en cada lanzamiento; Zimbra documenta Log4j como el mecanismo de rotación para audit.log.
• No comprima ni archive los archivos en el mismo sistema de archivos, que estará casi lleno, a menos que haya confirmado que hay suficiente espacio temporal.
• No reduzca el período de retención sin verificar los requisitos organizativos, legales o de seguridad.
• No edite de forma permanente los archivos Log4j generados sin antes comprender si Zimbra los regenerará a partir de una plantilla.

Verificación final

Si los registros antiguos rotados fueran el principal consumidor de espacio, el resultado ideal sería sencillo: el registro de auditoría activo permanece intacto, los archivos históricos se archivan o eliminan según la política establecida, y el sistema de archivos recupera suficiente espacio para funcionar con normalidad. Si el espacio comienza a desaparecer de nuevo inmediatamente, deje de considerar la limpieza como la solución e investigue la tasa de escritura, la actividad de autenticación, la configuración de rotación y cualquier otra configuración de registro. Esta distinción —limpieza puntual frente a crecimiento recurrente— es lo que determina si realmente se ha solucionado el problema.