Como testar o plano de recuperação de desastre do seu servidor de MU Online

Todo administrador de servidor de MU Online diz que "tem backup". Poucos já testaram, de fato, restaurar esse backup do zero, sob pressão de tempo, e colocar o servidor de volta ao ar sem perder dados críticos. Um plano de recuperação de desastre (DRP) só vale alguma coisa depois de testado — no papel, ele é só uma lista de boas intenções. Este tutorial mostra como estruturar um DRP para um servidor de MU e, principalmente, como simular desastres reais para validar que o plano funciona antes que você precise dele de verdade.

Por que "ter backup" não é a mesma coisa que "ter um plano"

Um backup é um arquivo. Um plano de recuperação de desastre é um processo: quem executa, com qual acesso, restaurando o quê, em qual ordem, e como validar que tudo voltou correto. Servidores que só têm o arquivo descobrem na hora da crise que falta a senha do provedor de hospedagem, que o script de restauração está desatualizado, ou que o backup do banco não inclui as tabelas de personagem mais recentes. Testar o plano transforma essas suposições em fatos verificados.

Definindo RTO e RPO antes de qualquer teste

Antes de simular qualquer desastre, defina dois números:

Esses números orientam decisões técnicas: um RPO de 15 minutos exige backup incremental do banco a cada 15 minutos (ou replicação), não apenas um dump diário. Um RTO de 2 horas exige que o processo de restauração completo (banco + GameServer + ConnectServer + painel web) esteja documentado e cronometrado — se hoje leva 6 horas, o plano precisa de ajuste antes de qualquer desastre real.

Inventário do que precisa ser recuperado

Um servidor de MU tem várias peças que precisam ser recuperadas juntas e na ordem certa:

Sem esse inventário documentado, é comum restaurar o banco primeiro e descobrir que a versão do GameServer não é compatível com o schema restaurado — um erro evitável com um checklist de ordem correto.

Cenários de desastre que valem a pena simular

Não teste apenas "o servidor caiu". Simule cenários específicos, cada um com uma resposta diferente:

Montando o ambiente de teste isolado

Nunca teste restauração sobre o ambiente de produção. Monte uma VPS de teste ou VM local com a mesma stack (SQL Server/MySQL, GameServer, ConnectServer) e execute a restauração completa ali. Isso permite cronometrar o processo sem risco e documentar cada passo real — comandos exatos, tempo gasto em cada etapa, credenciais necessárias.

# Exemplo de restauração de banco em ambiente de teste (MySQL)
mysql -u root -p mu_test < backup_2026-07-15_0300.sql

# Exemplo para SQL Server via sqlcmd
sqlcmd -S localhost -Q "RESTORE DATABASE MuOnline FROM DISK = 'D:\Backups\MuOnline_full.bak' WITH REPLACE"

Depois de restaurar o banco, suba o GameServer apontando para essa instância de teste e confirme login, criação de personagem e persistência de item — restaurar o banco sem validar que o servidor consegue lê-lo corretamente é um teste incompleto.

Cronometrando o processo real

Durante o teste, registre o tempo de cada etapa em uma tabela como esta:

Se o tempo real ultrapassar o RTO definido, o plano precisa de ajuste — seja automatizando etapas manuais, seja pré-provisionando um host de contingência já configurado (standby quente).

Validando integridade dos dados pós-restauração

Restaurar sem validar é arriscado. Depois de qualquer teste de restauração, rode verificações específicas:

• Contagem de contas e personagens bate com o esperado (comparar com métrica monitorada antes do backup).
• Login de uma conta de teste conhecida funciona e reflete o estado esperado de itens e Zen.
• Logs do GameServer não mostram erros de schema ou tabela ausente.
• Ranking e ligas carregam sem erro (indicativo de integridade de tabelas relacionadas).

Comunicação durante um desastre real

Parte do plano é como você se comunica enquanto restaura. Prepare com antecedência uma mensagem-modelo para o Discord/site informando que houve um incidente, uma estimativa de retorno e um canal para atualização — isso reduz o volume de tickets duplicados e protege a reputação do servidor mesmo durante uma falha real.

Frequência de testes e gatilhos de retest

Defina uma cadência mínima e gatilhos que disparam um novo teste fora do calendário:

Documentando o plano para quem não é você

Um plano de recuperação de desastre só funciona se outra pessoa da equipe conseguir executá-lo sem você disponível. Documente cada passo em linguagem simples, com comandos exatos, caminhos de arquivo e onde encontrar credenciais (idealmente em um cofre de senhas compartilhado, nunca em texto puro no Discord). Teste isso literalmente pedindo para outro membro da equipe seguir o documento sem sua ajuda.

Erros comuns e soluções

Checklist de teste de recuperação de desastre

• RTO e RPO definidos e documentados.
• Inventário de componentes e ordem de restauração documentado.
• Ambiente de teste isolado provisionado.
• Cenários de desastre (host, corrupção, exclusão, ataque) simulados individualmente.
• Tempo real de cada etapa cronometrado e comparado ao RTO.
• Validação de integridade pós-restauração executada.
• Plano documentado e testado por uma segunda pessoa da equipe.
• Calendário de retestes definido com gatilhos adicionais.

Um plano testado é o que separa um incidente de algumas horas de uma perda permanente de confiança da comunidade. Depois de validar sua recuperação de desastre, revise também a base de infraestrutura descrita no guia de criação de servidor de MU Online para garantir que os fundamentos de backup e monitoramento já nascem alinhados com o seu plano.

Perguntas frequentes