Como Configurar Backups Automáticos Externos no Servidor de MU

Todo administrador de MU Online vive sob a mesma ameaça silenciosa: um disco que falha, um comando errado no SQL, um ataque de ransomware ou um provedor que simplesmente some com a sua máquina. O banco de dados guarda contas, personagens, inventários, guildas, resets e o histórico econômico inteiro do servidor. Perder isso não é um problema técnico — é o fim do projeto e da confiança da comunidade. Este tutorial mostra como montar um fluxo de backup automático externo, ou seja, que copia os dados críticos para fora da máquina de origem, de forma agendada, verificada e com rotação. O foco aqui não é apenas "gerar um .bak", mas garantir que exista sempre uma cópia recuperável em um lugar que sobreviva à morte do servidor principal. Os caminhos, versões e valores citados são exemplos e variam por provedor/versão — o que importa é entender o conceito e adaptar à sua estrutura.

Pré-requisitos

Antes de automatizar qualquer coisa, garanta que o básico está no lugar. Este tutorial assume um servidor de MU já rodando (se você ainda está montando o seu, veja o guia de como criar servidor de MU Online).

• Acesso administrativo ao VPS ou máquina que hospeda o servidor (RDP no Windows, ou SSH no Linux).
• Banco de dados funcional — normalmente SQL Server (2008/2014/2019 são comuns em MU S6) ou MySQL/MariaDB em servidores mais modernos.
• Um destino externo definido: nuvem (armazenamento de objetos, drive), um segundo VPS ou storage remoto acessível por SFTP/rclone.
• Ferramenta de sincronização instalada. O rclone é a escolha mais versátil por falar com dezenas de provedores; SFTP nativo também serve.
• Espaço em disco local suficiente para gerar o arquivo comprimido antes do envio (regra prática: 2x o tamanho atual do banco).
• Um usuário de serviço dedicado para o backup, sem privilégios além do necessário.

Entenda o que realmente precisa ser copiado

O erro mais comum é achar que "backup do servidor" é só o banco de dados. Um MU tem duas categorias de dados críticos, e as configurações não estão dentro do SQL.

Se você customizou spots em mapas de fim de jogo ou drops de um evento, esses dados vivem em arquivos de texto do GameServer — um backup só do SQL não os recupera. Trate a pasta de dados do servidor como parte obrigatória do backup.

Passo 1 — Gerar o backup do banco de forma consistente

O backup precisa ser um "retrato" consistente do banco, não uma cópia de arquivos abertos em uso. Nunca copie os arquivos .mdf/.ldf (SQL) ou o diretório de dados do MySQL "na mão" com o serviço rodando — isso gera arquivos corrompidos.

No SQL Server, use o comando nativo, que garante consistência e ainda comprime:

BACKUP DATABASE [MuOnline]
    TO DISK = N'D:\Backups\MuOnline\MuOnline_full.bak'
    WITH
        COMPRESSION,   -- reduz muito o tamanho do arquivo
        CHECKSUM,      -- grava verificacao de integridade
        INIT,
        STATS = 10,
        NAME = N'Backup completo MuOnline';

No MySQL/MariaDB, o mysqldump gera um dump lógico consistente:

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p muonline > /backups/muonline_$(date +%F).sql

O parâmetro --single-transaction evita travar as tabelas durante o dump em bancos InnoDB. O objetivo desta etapa é ter, ao final, um único arquivo por execução, com data no nome, pronto para ser comprimido e enviado.

Passo 2 — Empacotar banco e configurações juntos

Um backup útil junta o banco e as pastas de configuração no mesmo pacote datado. Assim, na hora de restaurar, tudo veio do mesmo momento. Um script simples resolve isso no Windows com PowerShell:

# gera-pacote.ps1 — junta .bak + pasta Data em um zip datado
$stamp   = Get-Date -Format 'yyyyMMdd_HHmm'
$destino = "D:\Backups\Pacotes\mu_$stamp.zip"

# 1) executa o backup SQL (procedure ou comando direto)
sqlcmd -S localhost -Q "BACKUP DATABASE [MuOnline] TO DISK='D:\Backups\MuOnline\MuOnline_full.bak' WITH COMPRESSION, CHECKSUM, INIT"

# 2) empacota o .bak + a pasta de configuracoes do GameServer
Compress-Archive -Path @(
    "D:\Backups\MuOnline\MuOnline_full.bak",
    "D:\MuServer\GameServer\Data"
) -DestinationPath $destino -Force

Write-Host "Pacote gerado: $destino"

Em Linux, o equivalente é um tar com o dump e a pasta de dados:

tar -czf /backups/mu_$(date +%F_%H%M).tar.gz \
    /backups/muonline_$(date +%F).sql \
    /opt/muserver/GameServer/Data

Passo 3 — Enviar para o destino externo com rclone

Com o pacote pronto localmente, o envio externo é o coração deste tutorial. O rclone conecta a praticamente qualquer provedor (drives, armazenamento de objetos S3-compatível, SFTP) com a mesma sintaxe. Depois de rodar rclone config uma vez para criar o "remote", o envio é uma linha:

# envia o pacote mais recente e mantem log
$arquivo = Get-ChildItem "D:\Backups\Pacotes\*.zip" |
           Sort-Object LastWriteTime -Descending | Select-Object -First 1

rclone copy $arquivo.FullName "remote:backups/mu/" `
    --bwlimit 8M `        # limita banda para nao afogar os jogadores
    --log-file "D:\Backups\Logs\rclone.log" `
    --log-level INFO

O parâmetro --bwlimit (exemplo: 8 MB/s, ajuste ao seu link) evita que o upload consuma toda a banda e cause lag no jogo. Se preferir SFTP puro para um segundo VPS, o conceito é o mesmo: transferir o pacote datado para uma máquina fisicamente diferente da de origem.

> Um destino externo só é externo de verdade se estiver em outra máquina/infraestrutura. Copiar para "outra pasta" ou "outro disco do mesmo VPS" não protege contra a perda da máquina inteira.

Passo 4 — Verificar a integridade antes de confiar

Enviar um arquivo corrompido é pior do que não ter backup, porque cria falsa segurança. Sempre valide. No SQL Server, a verificação nativa confere o CHECKSUM sem restaurar:

RESTORE VERIFYONLY
FROM DISK = N'D:\Backups\MuOnline\MuOnline_full.bak'
WITH CHECKSUM;

Para o pacote enviado, compare o tamanho e o hash local com o remoto. O rclone tem um comando dedicado que confere isso automaticamente:

rclone check "D:\Backups\Pacotes\" "remote:backups/mu/" --one-way

Se o hash bater, o arquivo chegou íntegro. Registre o resultado no log de cada execução — assim, se algo travar no meio da madrugada, você sabe exatamente qual foi o último backup bom.

Passo 5 — Rotação e retenção em camadas

Guardar tudo para sempre enche o storage e dificulta achar o arquivo certo numa emergência. Use retenção em camadas, mantendo mais granularidade nos dados recentes:

remote:backups/mu/
  ├── diario/    → ultimos 7 dias
  ├── semanal/   → 1 por semana, por 4 semanas
  └── mensal/    → 1 por mes, por 6 meses

A limpeza dos antigos também é automatizável. O rclone remove arquivos além de uma idade com um único comando:

# apaga backups diarios com mais de 7 dias no destino externo
rclone delete "remote:backups/mu/diario/" --min-age 7d

Localmente, faça a mesma rotação para não encher o disco do VPS, mantendo apenas os últimos dias antes do envio.

Passo 6 — Agendar a execução automática

Backup manual funciona enquanto você lembra; backup automático funciona enquanto o servidor está ligado. No Windows, use o Agendador de Tarefas apontando para o script:

1. Abra o Agendador de Tarefas (taskschd.msc).
2. Crie uma tarefa com disparador diário na madrugada (exemplo: 03:00).
3. Ação: iniciar powershell.exe com argumentos -NonInteractive -ExecutionPolicy Bypass -File "D:\Scripts\gera-pacote.ps1".
4. Marque "Executar mesmo se o usuário não estiver conectado" e use o usuário de serviço dedicado.
5. Nas configurações, ative "Executar a tarefa o quanto antes se um início agendado for perdido".

Em Linux, uma linha no crontab -e resolve:

# 03:00 todos os dias: gera pacote e envia
0 3 * * * /opt/scripts/backup-mu.sh >> /var/log/backup-mu.log 2>&1

Passo 7 — Alertas de falha

Você precisa saber quando um backup não aconteceu, e não descobrir isso no dia do desastre. Adicione um alerta ao final do fluxo, disparado apenas em caso de erro. Um exemplo simples por e-mail em PowerShell:

if ($LASTEXITCODE -ne 0) {
    Send-MailMessage -SmtpServer "smtp.seuprovedor.com" -Port 587 -UseSsl `
        -From "[email protected]" -To "[email protected]" `
        -Subject "FALHA no backup externo do MU" `
        -Body "O backup externo falhou em $(Get-Date). Verifique o log." `
        -Encoding UTF8
}

Muitos administradores preferem um webhook para o Discord da equipe — o conceito é o mesmo: transformar um erro silencioso em uma notificação que alguém vai ver.

Erros comuns e soluções

Checklist de lançamento

• Backup do banco gerado com comando nativo (com compressão e checksum)
• Pasta GameServer\Data e configs do ConnectServer/JoinServer incluídas no pacote
• Destino externo em máquina/infraestrutura diferente da de origem
• Envio automático com limite de banda configurado
• Verificação de integridade (RESTORE VERIFYONLY / rclone check) no fluxo
• Rotação e retenção em camadas (diário/semanal/mensal) ativas
• Rotação local do disco do VPS ativa
• Agendamento automático rodando sob usuário de serviço dedicado
• Alerta de falha por e-mail ou Discord funcionando
• Teste de restauração mensal em banco separado agendado

Com esse fluxo você deixa de depender da própria memória e passa a ter um sistema que protege o servidor mesmo enquanto você dorme: banco e configurações empacotados, enviados para fora da máquina, verificados, rotacionados e monitorados. É a diferença entre um imprevisto de hardware ser um susto de uma hora ou o fim do seu servidor.

Perguntas frequentes