Cómo automatizar la limpieza de logs antiguos en el servidor de MU Online

Un servidor de MU Online genera una cantidad impresionante de logs: conexiones en el ConnectServer, acciones de GM en el GameServer, errores de red, transacciones de ítems, intentos de login inválidos y mucho más. Sin una rutina de retención, estos archivos crecen indefinidamente hasta llenar el disco — y un disco lleno tumba la base de datos, traba el GameServer y hasta puede corromper datos que se estén escribiendo en el momento de la falla. Este tutorial muestra cómo armar una política de retención por tipo de log, automatizar la limpieza/compresión con cron (o el Programador de Tareas en Windows) y monitorear el uso de disco para nunca ser sorprendido.

Por qué los logs sin rotación son un riesgo real

Un servidor promedio de MU Online, con algunos cientos de jugadores simultáneos, puede generar cientos de megabytes hasta pocos gigabytes de log por día, dependiendo del nivel de verbosidad configurado. Sin rotación, en pocas semanas estos archivos ocupan decenas de gigabytes — y el síntoma más común no es un aviso elegante, es la base de datos trabándose por falta de espacio en disco en medio de una transacción, lo que puede generar inconsistencia en cuentas e ítems.

Clasificando los tipos de log por criticidad

No todo log merece el mismo trato. Definir una política de retención por tipo evita borrar algo importante y también evita mantener basura innecesaria durante meses:

Mapeando dónde graba sus logs cada emulador

En IGCN, los logs suelen estar en Data/Log/ dentro de la carpeta de cada servicio (GameServer, ConnectServer, JoinServer). En MuEMU, es común una carpeta Logs/ en la raíz con subcarpetas por día (Logs/2026-07-30/). Antes de escribir el script de limpieza, hacé un inventario real de tu entorno:

find /srv/muserver -iname "*.log" -o -iname "*.txt" | grep -i log | sort
du -sh /srv/muserver/*/Log* 2>/dev/null

Esto muestra exactamente qué carpetas están consumiendo más espacio y debe orientar la prioridad de la política de retención.

Script de limpieza por antigüedad de archivo (Linux)

El comando find con -mtime es la herramienta indicada para aplicar retención basada en la antigüedad del archivo, sin necesidad de lógica compleja:

#!/bin/bash
# limpeza_logs.sh — corre diariamente vía cron

# Logs de debug: borra después de 3 días
find /srv/muserver/Logs/debug -name "*.log" -mtime +3 -delete

# Logs de red: borra después de 7 días
find /srv/muserver/Logs/network -name "*.log" -mtime +7 -delete

# Logs de auditoría/comercio: comprime después de 7 días, borra después de 90
find /srv/muserver/Logs/audit -name "*.log" -mtime +7 ! -name "*.gz" -exec gzip {} \;
find /srv/muserver/Logs/audit -name "*.gz" -mtime +90 -delete

echo "$(date): limpieza de logs completada" >> /var/log/mu/limpeza.log

Script equivalente en Windows (PowerShell)

Para servidores corriendo en Windows, el mismo concepto con Get-ChildItem y filtro de fecha:

$limite = (Get-Date).AddDays(-7)
Get-ChildItem "C:\MuServer\Logs\network" -Filter *.log |
  Where-Object { $_.LastWriteTime -lt $limite } |
  Remove-Item -Force

$limiteAuditoria = (Get-Date).AddDays(-90)
Get-ChildItem "C:\MuServer\Logs\audit" -Filter *.gz |
  Where-Object { $_.LastWriteTime -lt $limiteAuditoria } |
  Remove-Item -Force

Guardalo como limpeza_logs.ps1 y configuralo en el Programador de Tareas de Windows con un disparador diario.

Comprimiendo antes de borrar (retención extendida barata)

Comprimir los logs antiguos antes de borrarlos definitivamente es una forma barata de extender la ventana de investigación sin consumir mucho espacio — los archivos de texto de log suelen comprimir 80-95% con gzip:

gzip -9 /srv/muserver/Logs/audit/GMLog_2026-06-*.txt

Esto convierte, por ejemplo, 500 MB de logs de junio en algo cercano a 30-50 MB, manteniendo la posibilidad de auditoría retroactiva durante mucho más tiempo por el mismo costo de disco.

Rotación nativa vs. script propio

En entornos Linux, logrotate es una alternativa nativa y más robusta que un script crudo de find, especialmente si los procesos del servidor escriben continuamente en el archivo (evita truncar un log en uso):

/srv/muserver/Logs/network/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

La directiva copytruncate es importante acá: copia el contenido actual, lo comprime, y trunca el archivo original en su lugar, sin necesidad de reiniciar el proceso del GameServer para que vuelva a escribir en un archivo "nuevo".

Monitoreando el uso de disco de forma proactiva

Además de limpiar, es importante saber cuándo el disco se está acercando al límite antes de que se convierta en una emergencia. Un script simple de chequeo, reutilizando el webhook de alertas ya usado en el backup y en los eventos:

USO=$(df -h /srv/muserver | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USO" -gt 85 ]; then
  curl -s -X POST "$DISCORD_WEBHOOK_URL" \
    -H "Content-Type: application/json" \
    -d "{\"content\":\"⚠️ ¡Disco del servidor MU al ${USO}% de uso!\"}"
fi

Programando la ejecución

En Linux, un cron diario de madrugada, fuera del horario pico:

30 3 * * * /usr/local/bin/limpeza_logs.sh >> /var/log/mu/limpeza_cron.log 2>&1

En Windows, el Programador de Tareas con un disparador diario a las 03:30, apuntando al script de PowerShell con la política de ejecución liberada (-ExecutionPolicy Bypass), en caso de que la política predeterminada bloquee scripts no firmados.

Diferencia entre borrar y archivar en la nube

Para servidores con requisitos de compliance o historial de disputas con jugadores, borrar definitivamente puede no ser ideal. Una alternativa es mover (no borrar) los logs comprimidos a almacenamiento en la nube antes de quitarlos del disco local, usando el mismo enfoque del tutorial de backup a Google Drive — esto preserva el historial fuera del servidor sin ocupar disco local indefinidamente.

Errores comunes y soluciones

Lista de verificación de limpieza automatizada de logs

• Inventario de carpetas de log realizado y volumen de cada una medido.
• Política de retención definida por tipo de log (auditoría, red, debug, crash).
• Script de limpieza (find/PowerShell o logrotate) implementado y probado.
• Compresión configurada para logs de auditoría antes de la eliminación definitiva.
• Monitoreo de uso de disco con alerta configurado.
• Programación automática confirmada (cron o Programador de Tareas).
• Proceso de archivado en la nube evaluado para logs sensibles.

Con la limpieza de logs corriendo sola y el disco monitoreado, eliminás una de las causas más triviales — y más evitables — de caída del servidor. Si la infraestructura todavía está en fase inicial, revisá el tutorial de creación de servidor de MU Online para garantizar que los discos y rutas de log ya nazcan bien dimensionados.

Preguntas frecuentes