Como automatizar a limpeza de logs antigos no servidor de MU Online

Um servidor de MU Online gera uma quantidade impressionante de logs: conexões no ConnectServer, ações de GM no GameServer, erros de rede, transações de item, tentativas de login inválidas e muito mais. Sem uma rotina de retenção, esses arquivos crescem indefinidamente até encher o disco — e um disco cheio derruba o banco de dados, trava o GameServer e pode até corromper dados em gravação no momento da falha. Este tutorial mostra como montar uma política de retenção por tipo de log, automatizar a limpeza/compactação com cron (ou Agendador de Tarefas no Windows) e monitorar o uso de disco para nunca ser pego de surpresa.

Por que logs sem rotação são um risco real

Um servidor médio de MU Online, com algumas centenas de jogadores simultâneos, pode gerar centenas de megabytes a poucos gigabytes de log por dia, dependendo do nível de verbosidade configurado. Sem rotação, em poucas semanas esses arquivos ocupam dezenas de gigabytes — e o sintoma mais comum não é um aviso elegante, é o banco de dados travando por falta de espaço em disco no meio de uma transação, o que pode gerar inconsistência em contas e itens.

Classificando os tipos de log por criticidade

Nem todo log merece o mesmo tratamento. Definir uma política de retenção por tipo evita apagar algo importante e evita também manter lixo desnecessário por meses:

Mapeando onde cada emulador grava seus logs

No IGCN, os logs costumam ficar em Data/Log/ dentro da pasta de cada serviço (GameServer, ConnectServer, JoinServer). No MuEMU, é comum uma pasta Logs/ na raiz com subpastas por dia (Logs/2026-07-30/). Antes de escrever o script de limpeza, faça um inventário real do seu ambiente:

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

Isso mostra exatamente quais pastas estão consumindo mais espaço e deve orientar a prioridade da política de retenção.

Script de limpeza por idade de arquivo (Linux)

O comando find com -mtime é a ferramenta certa para aplicar retenção baseada em idade do arquivo, sem precisar de lógica complexa:

#!/bin/bash
# limpeza_logs.sh — roda diariamente via cron

# Logs de debug: apaga após 3 dias
find /srv/muserver/Logs/debug -name "*.log" -mtime +3 -delete

# Logs de rede: apaga após 7 dias
find /srv/muserver/Logs/network -name "*.log" -mtime +7 -delete

# Logs de auditoria/trade: compacta após 7 dias, apaga após 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): limpeza de logs concluída" >> /var/log/mu/limpeza.log

Script equivalente no Windows (PowerShell)

Para servidores rodando em Windows, o mesmo conceito com Get-ChildItem e filtro de data:

$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

Salve como limpeza_logs.ps1 e configure no Agendador de Tarefas do Windows com gatilho diário.

Compactando antes de apagar (retenção estendida barata)

Compactar logs antigos antes de apagar de fato é uma forma barata de estender a janela de investigação sem consumir muito espaço — arquivos de texto de log costumam comprimir 80–95% com gzip:

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

Isso transforma, por exemplo, 500 MB de logs de junho em algo próximo de 30–50 MB, mantendo a possibilidade de auditoria retroativa por muito mais tempo pelo mesmo custo de disco.

Rotação nativa vs. script próprio

Em ambientes Linux, o logrotate é uma alternativa nativa e mais robusta que um script cru de find, especialmente se os processos do servidor escrevem continuamente no arquivo (evita truncar um log em uso):

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

A diretiva copytruncate é importante aqui: ela copia o conteúdo atual, comprime, e trunca o arquivo original no lugar, sem precisar reiniciar o processo do GameServer para que ele volte a escrever em um arquivo "novo".

Monitorando o uso de disco proativamente

Além de limpar, é importante saber quando o disco está se aproximando do limite antes que vire uma emergência. Um script simples de checagem, reaproveitando o webhook de alertas já usado no backup e nos 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 do servidor MU em ${USO}% de uso!\"}"
fi

Agendando a execução

No Linux, um cron diário de madrugada, fora do horário de pico:

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

No Windows, o Agendador de Tarefas com gatilho diário às 03:30, apontando para o script PowerShell com política de execução liberada (-ExecutionPolicy Bypass), caso a política padrão bloqueie scripts não assinados.

Diferença entre apagar e arquivar em nuvem

Para servidores com requisitos de compliance ou histórico de disputas com jogadores, apagar de vez pode não ser ideal. Uma alternativa é mover (não apagar) os logs compactados para armazenamento em nuvem antes de removê-los do disco local, usando a mesma abordagem do tutorial de backup para Google Drive — isso preserva o histórico fora do servidor sem ocupar disco local indefinidamente.

Erros comuns e soluções

Checklist de limpeza automatizada de logs

• Inventário de pastas de log feito e volume de cada uma medido.
• Política de retenção definida por tipo de log (auditoria, rede, debug, crash).
• Script de limpeza (find/PowerShell ou logrotate) implementado e testado.
• Compactação configurada para logs de auditoria antes da exclusão definitiva.
• Monitoramento de uso de disco com alerta configurado.
• Agendamento automático confirmado (cron ou Agendador de Tarefas).
• Processo de arquivamento em nuvem avaliado para logs sensíveis.

Com a limpeza de logs rodando sozinha e o disco monitorado, você elimina uma das causas mais banais — e mais evitáveis — de queda de servidor. Se a infraestrutura ainda está em fase inicial, revise o tutorial de criação de servidor de MU Online para garantir que os discos e caminhos de log já nasçam bem dimensionados.

Perguntas frequentes