Como monitorar o espaço em disco do servidor de MU Online e evitar quedas por disco cheio

Disco cheio é uma das causas mais silenciosas e mais destrutivas de queda em servidores privados de MU Online: diferente de um pico de CPU que os jogadores sentem como lag, o disco enche aos poucos, sem sintoma visível, até o momento em que o MySQL simplesmente para de aceitar escritas — e nesse instante você já está lidando com dados de personagem potencialmente corrompidos, não apenas com um servidor fora do ar. Este tutorial mostra como identificar os maiores consumidores de espaço em um servidor de MU (logs, backups, tabelas de banco), configurar alertas automáticos antes que o disco chegue ao limite, e montar uma rotina de limpeza e arquivamento que mantém o servidor saudável sem perder histórico importante para investigações de ban e disputas entre jogadores.

Por que disco cheio é mais perigoso que CPU alta

Um pico de CPU degrada a experiência (lag), mas o servidor continua funcionando e se recupera sozinho quando o pico passa. Disco cheio é binário: em um momento o MySQL escreve normalmente, no seguinte ele recusa qualquer escrita, porque não há espaço físico para o arquivo de log de transações (ib_logfile) ou para o próprio tablespace crescer. Isso pode travar o GameServer no meio de um save de personagem, com risco real de corrupção de dados — um problema muito mais grave que qualquer lag.

Principais consumidores de espaço em um servidor de MU Online

Passo 1 — Medir o uso atual de disco

Antes de configurar qualquer alerta, entenda onde o espaço está sendo consumido hoje. No Linux:

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

No Windows, ferramentas como WinDirStat ou o próprio Get-ChildItem recursivo no PowerShell ajudam a mapear os maiores diretórios antes de decidir o que limpar ou rotacionar.

Passo 2 — Configurar rotação de logs

Em Linux, o logrotate compacta e arquiva logs automaticamente, evitando que um único arquivo cresça sem limite:

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

Isso mantém 30 dias de histórico compactado e descarta o que passar disso — suficiente para a maioria das investigações de disputa entre jogadores, sem deixar o disco crescer indefinidamente.

Passo 3 — Automatizar a limpeza de backups antigos

Backups do MySQL precisam de uma política clara de retenção. Um script simples rodando via cron/tarefa agendada resolve:

#!/bin/bash
# Mantém apenas os últimos 14 backups diários
find /backup/mysql -name "*.sql.gz" -mtime +14 -delete

Nunca apague backups manualmente sem confirmar que existe pelo menos uma cópia recente íntegra — sempre valide o backup mais novo antes de rodar a limpeza dos antigos.

Passo 4 — Arquivar tabelas de log de eventos/PK que crescem sem limite

Tabelas como logs de PK, logs de drop de itens raros e logs de chat podem crescer para milhões de linhas ao longo de meses. Em vez de deixá-las crescer indefinidamente dentro do banco ativo, arquive periodicamente os registros antigos em uma tabela separada ou em um dump externo:

-- Exemplo: mover registros com mais de 90 dias para uma tabela de arquivo
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;

Passo 5 — Configurar alertas automáticos de espaço

Um alerta simples com cron e um webhook do Discord já evita a maioria das surpresas, mesmo sem um stack completo de monitoramento:

#!/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 em ${USO}% de uso no servidor!\"}" https://discord.com/api/webhooks/SEU_WEBHOOK
fi

Agende esse script para rodar a cada 15-30 minutos via cron (Linux) ou Agendador de Tarefas (Windows).

Passo 6 — Definir limiares de alerta em camadas

Um único alerta em cima da hora não dá tempo de reação. Configure limiares progressivos, cada um com uma urgência diferente:

Passo 7 — Separar discos por função quando possível

Se o orçamento permitir, mantenha o MySQL em um disco (ou partição) separado dos logs e backups. Assim, mesmo que os logs cresçam descontroladamente, o MySQL continua tendo espaço para escrever — evitando o cenário mais grave de corrupção de dados de personagem.

Passo 8 — Testar a recuperação de espaço em um cenário simulado

Antes de confiar na rotina, simule um cenário de disco quase cheio em um ambiente de teste e confirme que a rotação de logs, a limpeza de backups e o arquivamento de tabelas realmente liberam espaço suficiente e a tempo. Um script de limpeza que nunca foi testado é tão arriscado quanto não ter nenhum.

Erros comuns e soluções

Checklist de monitoramento de disco

• Uso atual de disco mapeado por diretório (logs, backups, MySQL).
• Rotação de logs configurada com retenção definida (ex.: 30 dias).
• Script de limpeza automática de backups antigos implementado.
• Rotina de arquivamento de tabelas de log de crescimento rápido.
• Alertas automáticos configurados em camadas (70/85/92/97%).
• Discos de MySQL e logs/backups separados, se possível.
• Recuperação de espaço testada em ambiente simulado.

Com o espaço em disco sob controle, o próximo passo é integrar esses alertas a um painel de monitoramento mais completo, cruzando CPU, memória e conexões de banco no mesmo lugar — veja o tutorial de criação de servidor de MU Online para revisar a base de infraestrutura antes de avançar para um stack de observabilidade mais robusto.

Perguntas frequentes