Cómo monitorear el espacio en disco del servidor de MU Online y evitar caídas por disco lleno

Disco lleno es una de las causas más silenciosas y más destructivas de caída en servidores privados de MU Online: a diferencia de un pico de CPU que los jugadores sienten como lag, el disco se llena poco a poco, sin síntoma visible, hasta el momento en que MySQL simplemente deja de aceptar escrituras — y en ese instante ya estás lidiando con datos de personaje potencialmente corruptos, no solo con un servidor fuera de línea. Este tutorial muestra cómo identificar a los mayores consumidores de espacio en un servidor de MU (logs, backups, tablas de base de datos), configurar alertas automáticas antes de que el disco llegue al límite, y armar una rutina de limpieza y archivado que mantiene al servidor saludable sin perder historial importante para investigaciones de baneo y disputas entre jugadores.

Por qué el disco lleno es más peligroso que la CPU alta

Un pico de CPU degrada la experiencia (lag), pero el servidor sigue funcionando y se recupera solo cuando el pico pasa. El disco lleno es binario: en un momento MySQL escribe normalmente, al siguiente rechaza cualquier escritura, porque no hay espacio físico para que el archivo de log de transacciones (ib_logfile) o el propio tablespace crezcan. Esto puede trabar al GameServer en medio de un guardado de personaje, con riesgo real de corrupción de datos — un problema mucho más grave que cualquier lag.

Principales consumidores de espacio en un servidor de MU Online

Paso 1 — Medir el uso actual de disco

Antes de configurar cualquier alerta, entiende dónde se está consumiendo el espacio hoy. En Linux:

df -h
du -sh /var/lib/mysql /var/log /caminho/do/servidor/Logs /backup

En Windows, herramientas como WinDirStat o el propio Get-ChildItem recursivo en PowerShell ayudan a mapear los directorios más grandes antes de decidir qué limpiar o rotar.

Paso 2 — Configurar rotación de logs

En Linux, logrotate comprime y archiva logs automáticamente, evitando que un único archivo crezca sin límite:

# /etc/logrotate.d/mu-gameserver
/caminho/do/servidor/Logs/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

Esto mantiene 30 días de historial comprimido y descarta lo que pase de eso — suficiente para la mayoría de las investigaciones de disputa entre jugadores, sin dejar que el disco crezca indefinidamente.

Paso 3 — Automatizar la limpieza de backups antiguos

Los backups de MySQL necesitan una política clara de retención. Un script simple corriendo vía cron/tarea programada lo resuelve:

#!/bin/bash
# Mantiene solo los últimos 14 backups diarios
find /backup/mysql -name "*.sql.gz" -mtime +14 -delete

Nunca borres backups manualmente sin confirmar que existe al menos una copia reciente íntegra — valida siempre el backup más nuevo antes de correr la limpieza de los antiguos.

Paso 4 — Archivar tablas de log de eventos/PK que crecen sin límite

Tablas como logs de PK, logs de drop de ítems raros y logs de chat pueden crecer hasta millones de líneas a lo largo de meses. En lugar de dejarlas crecer indefinidamente dentro de la base de datos activa, archiva periódicamente los registros antiguos en una tabla separada o en un dump externo:

-- Ejemplo: mover registros de más de 90 días a una tabla de archivo
INSERT INTO LOG_PK_ARQUIVO SELECT * FROM LOG_PK WHERE Data < NOW() - INTERVAL 90 DAY;
DELETE FROM LOG_PK WHERE Data < NOW() - INTERVAL 90 DAY;
OPTIMIZE TABLE LOG_PK;

Paso 5 — Configurar alertas automáticas de espacio

Una alerta simple con cron y un webhook de Discord ya evita la mayoría de las sorpresas, incluso sin un stack completo de monitoreo:

#!/bin/bash
USO=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USO" -gt 85 ]; then
  curl -H "Content-Type: application/json" -d "{\"content\":\"⚠️ ¡Disco al ${USO}% de uso en el servidor!\"}" https://discord.com/api/webhooks/SEU_WEBHOOK
fi

Programa este script para correr cada 15-30 minutos vía cron (Linux) o el Programador de Tareas (Windows).

Paso 6 — Definir umbrales de alerta en capas

Una sola alerta a último momento no da tiempo de reacción. Configura umbrales progresivos, cada uno con una urgencia diferente:

Paso 7 — Separar discos por función cuando sea posible

Si el presupuesto lo permite, mantén MySQL en un disco (o partición) separado de los logs y backups. Así, incluso si los logs crecen descontroladamente, MySQL sigue teniendo espacio para escribir — evitando el escenario más grave de corrupción de datos de personaje.

Paso 8 — Probar la recuperación de espacio en un escenario simulado

Antes de confiar en la rutina, simula un escenario de disco casi lleno en un entorno de prueba y confirma que la rotación de logs, la limpieza de backups y el archivado de tablas realmente liberan espacio suficiente y a tiempo. Un script de limpieza que nunca fue probado es tan arriesgado como no tener ninguno.

Errores comunes y soluciones

Lista de verificación de monitoreo de disco

• Uso actual de disco mapeado por directorio (logs, backups, MySQL).
• Rotación de logs configurada con retención definida (ej.: 30 días).
• Script de limpieza automática de backups antiguos implementado.
• Rutina de archivado de tablas de log de crecimiento rápido.
• Alertas automáticas configuradas en capas (70/85/92/97%).
• Discos de MySQL y logs/backups separados, si es posible.
• Recuperación de espacio probada en entorno simulado.

Con el espacio en disco bajo control, el siguiente paso es integrar estas alertas a un panel de monitoreo más completo, cruzando CPU, memoria y conexiones de base de datos en el mismo lugar — mira el tutorial de creación de servidor de MU Online para revisar la base de infraestructura antes de avanzar hacia un stack de observabilidad más robusto.

Preguntas frecuentes