Backup incremental vs. completo para servidores de MU Online: qual escolher

Perder o banco de dados de um servidor de MU Online — contas, personagens, itens, guildas, histórico de ranking — é o tipo de incidente que pode encerrar um projeto da noite para o dia, especialmente se a comunidade já investiu tempo e dinheiro nele. A pergunta "backup incremental ou completo" não tem uma resposta única: a escolha certa depende do tamanho do banco, da frequência de mudança dos dados e do tempo aceitável de recuperação em caso de desastre. Este tutorial explica as diferenças técnicas entre os tipos de backup, mostra como combiná-los na prática para um servidor de MU, e apresenta um plano de recuperação testável — porque um backup nunca restaurado é apenas uma suposição.

Os três tipos de backup

Antes de decidir uma estratégia, é preciso entender exatamente o que cada tipo faz:

A escolha entre incremental e diferencial é o ponto mais confundido: incremental é mais leve para gerar, mas mais arriscado para restaurar, porque a cadeia inteira (completo + incremental 1 + incremental 2 + ... + incremental N) precisa estar intacta. Se um arquivo intermediário corromper, tudo depois dele se torna inútil.

O que precisa entrar no backup de um servidor de MU

Muitos administradores fazem backup só do banco de dados e esquecem arquivos essenciais para a recuperação completa:

Estratégia recomendada por porte de servidor

Não existe uma estratégia única — o tamanho do banco e o volume de jogadores ativos mudam o cálculo de custo-benefício.

Exemplo de script de backup completo (MySQL/MariaDB)

A maioria dos emuladores de MU (MuEmu, IGCN) usa MySQL ou MariaDB. Um script básico de backup completo, agendado via cron:

#!/bin/bash
DATA=$(date +%Y%m%d_%H%M%S)
DESTINO="/backup/mu/completo"
BANCO="mu_online"

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p"SENHA_AQUI" "$BANCO" | gzip > "$DESTINO/full_${BANCO}_${DATA}.sql.gz"

# Remove backups completos com mais de 30 dias
find "$DESTINO" -name "full_${BANCO}_*.sql.gz" -mtime +30 -delete

O parâmetro --single-transaction é essencial em bancos InnoDB — ele garante uma foto consistente do banco sem travar as tabelas durante o dump, evitando impacto perceptível para jogadores online no momento do backup.

Exemplo de backup incremental via binlog (MySQL)

Para incremental de verdade (não um "completo pequeno"), habilite o binary log do MySQL e faça backup dele periodicamente:

# my.cnf — habilitar binlog
[mysqld]
log-bin = /var/log/mysql/mu-bin
binlog_expire_logs_seconds = 604800
server-id = 1

#!/bin/bash
# Copia os binlogs gerados desde o último backup completo
DESTINO="/backup/mu/incremental"
mysqladmin -u backup_user -p"SENHA_AQUI" flush-logs
cp /var/log/mysql/mu-bin.* "$DESTINO/"

Restaurar com binlog exige aplicar o completo mais recente e depois "reproduzir" os binlogs na ordem exata — por isso documente sempre a ordem cronológica dos arquivos no nome ou em um índice separado.

Rotação e política de retenção (3-2-1)

A regra clássica de backup 3-2-1 se aplica bem a servidores de MU: 3 cópias dos dados, em 2 mídias diferentes, com 1 cópia fora do local físico do servidor (outra cidade, outro provedor de nuvem). Um VPS que hospeda o backup na mesma máquina do servidor de produção não é backup real — é só uma cópia que morre junto no mesmo incidente (falha de disco, invasão, banimento da conta do provedor).

Criptografia e segurança do backup

Um backup com dados de contas de jogadores (mesmo que senhas estejam hasheadas) é um ativo sensível — se vazado, expõe e-mails, IPs de login e histórico de compras da loja. Criptografe o arquivo antes de enviar para a nuvem:

gpg --symmetric --cipher-algo AES256 --output "full_mu_online_${DATA}.sql.gz.gpg" "full_mu_online_${DATA}.sql.gz"

Armazene a senha de criptografia em um cofre de senhas separado da infraestrutura do servidor — se o servidor for comprometido, o backup criptografado continua protegido mesmo que o invasor tenha acesso à máquina.

Testando a restauração (o passo que todos pulam)

Um cronograma de teste de restauração deve existir independentemente do quão "confiável" o processo pareça:

1. Reserve um ambiente isolado (VPS de teste ou container) sem acesso à rede de produção.
2. Restaure o backup completo mais recente do zero.
3. Aplique os incrementais/binlogs na ordem correta, se aplicável.
4. Suba o GameServer apontando para esse banco restaurado e valide login, personagem e inventário de uma conta de teste conhecida.
5. Documente o tempo total gasto — esse número é o seu RTO real (tempo de recuperação), não uma estimativa teórica.

Monitoramento e alertas de falha de backup

Um backup que falha silenciosamente é pior que não ter backup, porque cria falsa sensação de segurança. Configure alerta automático (webhook no Discord, e-mail) quando o script de backup terminar com erro ou quando o arquivo gerado tiver tamanho anormalmente pequeno comparado ao histórico:

TAMANHO=$(stat -c%s "$DESTINO/full_${BANCO}_${DATA}.sql.gz")
if [ "$TAMANHO" -lt 1000000 ]; then
  curl -H "Content-Type: application/json" -d '{"content":"⚠️ Backup do MU gerou arquivo suspeito de pequeno!"}' "$WEBHOOK_DISCORD"
fi

Erros comuns e soluções

Checklist de estratégia de backup

• Backup completo agendado com frequência adequada ao porte do servidor.
• Incremental ou diferencial configurado se o volume de mudança justificar.
• Regra 3-2-1 aplicada (cópia fora do servidor de produção).
• Arquivos criptografados antes de qualquer envio à nuvem.
• Alerta automático de falha de backup configurado.
• Teste de restauração completo realizado em ambiente isolado no último mês.
• Documentação da ordem de restauração (completo + incrementais) atualizada.

Com a estratégia de backup validada e testada, o próximo passo natural é revisar a infraestrutura geral do servidor — desde o provisionamento até a configuração de segurança — descrita com mais detalhe no tutorial de criação de servidor de MU Online.

Perguntas frequentes