Como automatizar o backup do seu servidor de MU Online para o Google Drive

Perder o banco de dados de um servidor de MU Online — com contas, personagens, itens e histórico de compras — é o tipo de incidente que pode encerrar um projeto da noite para o dia. Ainda assim, é comum ver administradores fazendo backup manual "quando lembram", o que é uma questão de tempo até dar errado. Este tutorial monta um pipeline completo e automatizado: dump do banco, compactação, criptografia opcional, envio para o Google Drive via rclone, rotação de versões antigas e alerta em caso de falha — tudo agendado para rodar sozinho todos os dias.

Por que a nuvem é parte essencial da estratégia de backup

A regra clássica de backup é 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, com uma cópia fora do local (off-site). Um backup que fica só no mesmo disco do servidor de produção não protege contra falha de hardware, ransomware ou erro de operação que apaga tudo. O Google Drive cumpre o papel de cópia off-site, com custo baixo e integração simples via rclone.

Visão geral do pipeline

O fluxo completo tem cinco etapas, executadas em sequência por um único script agendado:

Instalando e configurando o rclone

O rclone é a ferramenta padrão para sincronizar arquivos com dezenas de provedores de nuvem, incluindo o Google Drive, sem precisar de credenciais expostas em texto puro no script.

curl https://rclone.org/install.sh | sudo bash
rclone config

No assistente interativo, escolha n para novo remote, dê o nome gdrive_mu, selecione o tipo drive (Google Drive) e siga o fluxo de autenticação OAuth no navegador. Ao final, confirme o funcionamento:

rclone lsd gdrive_mu:

Se listar as pastas da sua conta do Google Drive, a configuração está correta.

Gerando o dump do banco de dados

Para MySQL/MariaDB (comum em MuEMU e derivados), use --single-transaction para não travar tabelas em uso durante o dump:

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p"$DB_PASS" mu_online > /backup/mu_$(date +%F).sql

Para SQL Server (comum em servidores IGCN), use sqlcmd com um BACKUP DATABASE direto para arquivo .bak:

BACKUP DATABASE MuOnline
TO DISK = 'C:\Backup\MuOnline_20260730.bak'
WITH COMPRESSION, INIT;

Crie um usuário de banco dedicado a backups (backup_user), com permissão apenas de leitura e BACKUP, nunca o usuário administrativo do GameServer — isso reduz o risco em caso de vazamento do script.

Empacotando arquivos de configuração críticos

Além do banco, vale incluir no backup os arquivos de configuração do GameServer/ConnectServer (que raramente mudam, mas custam caro para reconstruir do zero) e os últimos dias de log:

tar -czf /backup/config_$(date +%F).tar.gz \
  /srv/muserver/Data/*.txt \
  /srv/muserver/Data/*.xml \
  /srv/muserver/logs/*.log

Criptografando o backup antes do envio

Como o dump contém dados sensíveis (senhas com hash, histórico de compras, e-mails de jogadores), é recomendável criptografar antes de enviar para a nuvem, mesmo que o Google Drive já seja privado por padrão:

gpg --symmetric --cipher-algo AES256 --batch --passphrase "$BACKUP_PASSPHRASE" \
  /backup/mu_$(date +%F).sql

Isso gera um arquivo .gpg que só pode ser aberto com a senha definida — guarde essa senha em um cofre separado do servidor (gerenciador de senhas da equipe), nunca no mesmo script.

Enviando para o Google Drive

Com os arquivos prontos, o envio é uma única linha:

rclone copy /backup/ gdrive_mu:mu-backups/$(date +%Y-%m)/ --progress

Organizar por pasta de mês (2026-07/) facilita a navegação manual no Drive quando for necessário localizar um backup específico rapidamente.

Script completo de backup diário

Juntando as etapas em um único script (backup_diario.sh):

#!/bin/bash
set -e
DATA=$(date +%F)
BACKUP_DIR=/backup
DB_DUMP="$BACKUP_DIR/mu_$DATA.sql"

mysqldump --single-transaction -u backup_user -p"$DB_PASS" mu_online > "$DB_DUMP"
tar -czf "$BACKUP_DIR/config_$DATA.tar.gz" /srv/muserver/Data/*.txt /srv/muserver/Data/*.xml
gpg --symmetric --cipher-algo AES256 --batch --passphrase "$BACKUP_PASSPHRASE" "$DB_DUMP"
rm -f "$DB_DUMP"

rclone copy "$BACKUP_DIR/" gdrive_mu:mu-backups/$(date +%Y-%m)/ --progress
echo "Backup de $DATA concluído com sucesso." >> /var/log/mu/backup.log

Rotação: apagando backups antigos

Manter todos os backups para sempre esgota espaço rapidamente. Um esquema comum é reter os últimos 7 backups diários e apagar o resto, tanto localmente quanto no Drive:

find /backup -name "*.gpg" -mtime +7 -delete
rclone delete gdrive_mu:mu-backups/ --min-age 90d

Alertando em caso de falha

Um backup que falha silenciosamente é pior do que não ter backup — dá falsa sensação de segurança. Adicione um trap no script para notificar em caso de erro, reaproveitando o mesmo webhook de Discord/Telegram usado nos avisos de evento:

trap 'curl -s -X POST "$DISCORD_WEBHOOK_URL" -d "{\"content\":\"⚠️ Falha no backup diário do MU Online!\"}" -H "Content-Type: application/json"' ERR

Agendando a execução automática

No Linux, agende via cron para rodar de madrugada, fora do horário de pico de jogadores:

0 4 * * * /usr/local/bin/backup_diario.sh >> /var/log/mu/backup_cron.log 2>&1

No Windows, use o Agendador de Tarefas apontando para um .bat que chama o rclone e o sqlcmd, com gatilho diário às 04:00.

Testando a restauração periodicamente

Um backup nunca testado é uma aposta. A cada mês, baixe o arquivo mais recente e restaure em um ambiente de teste isolado (nunca em produção) para validar que o processo completo funciona ponta a ponta:

rclone copy gdrive_mu:mu-backups/2026-07/mu_2026-07-30.sql.gpg /tmp/teste/
gpg --decrypt --batch --passphrase "$BACKUP_PASSPHRASE" /tmp/teste/mu_2026-07-30.sql.gpg > /tmp/teste/mu_restaurado.sql
mysql -u root -p mu_teste < /tmp/teste/mu_restaurado.sql

Erros comuns e soluções

Checklist de backup automatizado

• rclone instalado e remote do Google Drive configurado e testado.
• Usuário de banco dedicado a backup, com permissões mínimas.
• Script de dump + compactação + criptografia funcionando manualmente.
• Envio ao Google Drive validado com rclone lsd.
• Rotação local e remota configurada.
• Alerta de falha via Discord/Telegram implementado.
• Agendamento diário confirmado (cron ou Agendador de Tarefas).
• Restauração testada em ambiente isolado no último mês.

Com o backup rodando sozinho e testado, a maior fonte de risco operacional do seu servidor deixa de ser "esquecer de salvar" e passa a ser apenas monitorar os alertas. Se você ainda está montando a infraestrutura do zero, volte ao tutorial de criação de servidor de MU Online para garantir que a base está sólida antes de automatizar o resto.

Perguntas frequentes