Como criar um plano de recuperação de desastre (DR) para o servidor de MU

Todo administrador de MU Online que ficou tempo suficiente na área tem uma história de terror: o VPS que morreu sem aviso, o banco que corrompeu depois de uma atualização, o provedor que suspendeu a conta, o disco que falhou levando junto o backup que também estava nele. Nessas horas, o que separa um susto de um fim de projeto é uma única coisa: existir, testado e ao alcance da mão, um plano de recuperação de desastre. Este tutorial mostra como construir um plano de DR de verdade para servidor de MU — não uma pasta de backups que você reza para nunca precisar abrir, mas um procedimento com metas claras, redundância em camadas, um caminho de recuperação e, o mais importante, testes que provam que ele funciona. Os valores, provedores e tempos citados são exemplo e variam por provedor/versão da sua infraestrutura.

Pré-requisitos

DR pressupõe algo a proteger: um servidor em produção com dados que doem perder. Se você ainda está montando a base, comece por como criar um servidor de MU Online e volte para blindá-lo. Para um plano de DR sério você precisa de:

• Um inventário completo do que compõe o servidor: banco de dados, arquivos de configuração do GameServer, site/painel, launcher, e as customizações que não estão no banco (spots, drops, eventos editados em arquivo).
• Backups já funcionando — o DR os organiza e testa, mas eles precisam existir. Se você ainda não tem rotina de backup, essa é a fundação e vem antes de tudo.
• Um segundo local de armazenamento independente do servidor principal: nuvem, outro datacenter, uma máquina física sua. A regra de ouro é que a cópia de segurança não pode morrer junto com o original.
• Decisão de negócio sobre RTO e RPO (quanto tempo offline e quantos dados perdidos você tolera). Sem isso, você não sabe quanto investir.
• Acesso a um VPS ou máquina de reposição para os testes de restauração — restaurar em cima do servidor de produção é proibido.

Passo 1 — Definir RTO e RPO (as metas do plano)

Antes de qualquer tecnologia, defina duas metas, porque elas ditam todo o resto do plano:

• RTO (Recovery Time Objective): o tempo máximo aceitável de servidor offline após um desastre. É a resposta para "caiu — em quanto tempo precisa voltar?".
• RPO (Recovery Point Objective): a perda máxima aceitável de dados. É a resposta para "de quanto tempo atrás pode ser o dado que sobrevive?". Um RPO de 6 horas significa aceitar perder até 6 horas de progresso dos jogadores.

Estas são decisões de negócio, não técnicas. A tabela abaixo mostra perfis típicos de servidor de MU e metas plausíveis — todas exemplo, variam por provedor/versão e pelo apetite de risco do projeto:

O RTO e o RPO que você escolher determinam o custo. Voltar em 15 minutos exige um segundo servidor rodando; voltar em um dia exige apenas backups e um bom procedimento. Não existe DR "certo" universal — existe o DR adequado às metas que o projeto pode e quer pagar.

Passo 2 — Mapear os ativos e classificar por criticidade

Você não recupera o que não sabe que existe. Faça o inventário completo do servidor e classifique cada ativo por criticidade e por RPO próprio:

## Inventário de ativos (exemplo — varia por provedor/versão)

CRÍTICO (RPO curto — perder dói muito):
- Banco de dados SQL (contas, personagens, inventário, guildas)
- Configs do GameServer NÃO no banco:
    Data\Monster\ (spots e drops customizados)
    Data\Item\ (atributos de itens editados)
    arquivos .ini/.txt de eventos customizados

IMPORTANTE (RPO médio — recriável com esforço):
- Site/painel web e seu banco
- Launcher e arquivos de patch do cliente
- Scripts de automação (D:\Scripts\)

RECRIÁVEL (RPO longo — pode remontar do instalador):
- Binários do emulador (GameServer.exe, ConnectServer.exe...)
- Runtime, dependências, cliente base

Essa classificação é o coração do DR. O banco de dados é insubstituível e precisa do backup mais frequente. Já os binários do emulador você reobtém do instalador, então não precisam de backup constante — mas precisam estar documentados para a reconstrução. O erro clássico é tratar tudo igual: ou você superprotege binários recriáveis, ou (pior) subprotege as configs em arquivo achando que "o backup do banco cobre tudo".

Passo 3 — Montar backups em camadas (a regra 3-2-1)

Com os ativos mapeados, estruture os backups seguindo a regra 3-2-1, o padrão de mercado para resiliência:

• 3 cópias dos dados (o original + 2 backups).
• 2 mídias/locais diferentes (ex.: disco local + nuvem).
• 1 cópia fora do local (offsite), imune a um desastre físico no datacenter.

Na prática, para um servidor de MU:

## Camadas de backup (exemplo — varia por provedor/versão)

Camada 1 — Local, rápida (para restauração comum):
- Backup do banco SQL a cada 6h em disco separado do banco
- Retenção: 3 dias

Camada 2 — Nuvem, offsite (para desastre do VPS):
- Envio diário do backup para armazenamento em nuvem
- Inclui: banco + pasta Data\ + configs do site
- Retenção em camadas: 7 diários, 4 semanais, 6 mensais

Camada 3 — Cópia fria, independente do provedor:
- Cópia semanal para outro provedor ou máquina física sua
- Protege contra: provedor suspender/perder a conta

A camada 3 é o que muita gente pula e é justamente a que salva no cenário "o provedor sumiu com minha conta". Manter tudo num só provedor de nuvem significa que uma suspensão de conta apaga original e backup de uma vez. Distribua o risco.

Passo 4 — Escolher a estratégia de contingência conforme o RTO

Backup responde "os dados sobreviveram?". A contingência responde "onde eles voltam a rodar?". A escolha depende do RTO definido no Passo 1:

1. Rebuild manual (RTO folgado, horas a um dia): você tem um procedimento documentado para montar um servidor novo do zero num VPS de reposição, restaurar o banco e as configs, apontar o DNS e subir. Mais barato, mais lento. Exige que o procedimento esteja escrito e testado.
2. VPS de reposição pré-configurado (RTO médio, 1-4 h): um segundo VPS com o emulador já instalado e configurado, esperando. No desastre, você só restaura o backup mais recente e sobe. Custa um VPS parado, mas corta horas do RTO.
3. Servidor standby com replicação (RTO curto, minutos): um segundo servidor que recebe cópias frequentes do banco e pode assumir rapidamente. É o mais caro e complexo, justificável só para servidores grandes com receita que a indisponibilidade compromete.

Para a maioria dos servidores de MU de porte médio, a opção 2 é o ponto ideal de custo-benefício: um VPS de reposição barato, mantido atualizado, transforma um desastre de dia inteiro num de poucas horas.

Passo 5 — Escrever o procedimento de failover

O plano precisa de um procedimento de recuperação passo a passo, escrito para ser seguido sob estresse. Exemplo para o cenário "VPS principal morreu, recuperar no VPS de reposição":

### DR-01 — Recuperação total no VPS de reposição

**Gatilho:** VPS principal inacessível e sem previsão de retorno.

**Meta:** RTO 3h, RPO 6h (exemplo).

**Passos:**
1. Confirmar que o principal está mesmo perdido (não é queda passageira).
   Avisar a comunidade que há manutenção emergencial.
2. Acessar o VPS de reposição (credenciais no cofre X).
3. Baixar da nuvem o backup mais recente do banco + pasta Data\.
4. Restaurar o banco no SQL do VPS de reposição (ver DR-02).
5. Copiar a pasta Data\ restaurada para o GameServer.
6. Conferir as configs de conexão (IPs internos, portas).
7. Subir os componentes na ordem: banco > DataServer >
   ConnectServer > JoinServer > GameServer.
8. Atualizar o DNS/IP para apontar ao VPS de reposição.
9. Testar login com uma conta de teste; validar personagem carrega.
10. Comunicar o retorno à comunidade.

**Se o backup mais recente falhar:** usar o anterior (perde mais RPO).
**Escalar para:** dono do projeto se passar de 3h.

O passo 1 (confirmar que é desastre de verdade) evita o erro caro de iniciar failover por causa de uma queda de 10 minutos que se resolveria sozinha. O passo 3 e o passo 4 são onde a maioria dos planos não testados falha — por isso o próximo passo é o mais importante de todos.

Passo 6 — Testar o plano (o drill de DR)

Um plano de DR nunca testado é um documento de esperança. O teste, o drill, é o que revela os furos antes que o desastre os revele por você. Faça periodicamente:

1. Teste de restauração isolado (mensal): restaure o backup mais recente num ambiente separado — nunca em produção — e confirme que o banco monta, os personagens carregam e as configs estão presentes. Cronometre.
2. Drill de failover completo (trimestral): execute o procedimento DR-01 inteiro no VPS de reposição, do zero, seguindo apenas o texto do plano. Cronometre e compare com o RTO alvo. Cada hesitação é um furo a corrigir.
3. Teste do pior caso (semestral): simule o cenário "provedor sumiu": recupere usando apenas a camada 3 de backup, a cópia fria independente. É o teste que valida se você realmente sobrevive à perda do provedor inteiro.

Anote os resultados de cada drill: tempo real x RTO alvo, o que falhou, o que faltava no plano. O DR não é um documento que você escreve uma vez — é um ciclo de testar, achar furos e corrigir, que só amadurece com repetição.

Erros comuns e soluções

O erro do backup só do banco é especialmente cruel porque dá falsa sensação de segurança: você tem "o backup", restaura, os personagens estão lá — e só então percebe que meses de configuração de drops e eventos, que viviam em arquivos, se perderam. Backup de DR é do servidor inteiro, não só da tabela de personagens.

Checklist de lançamento

• RTO e RPO definidos como decisão de negócio e documentados
• Inventário completo de ativos, classificado por criticidade
• Pasta Data\ e configs em arquivo incluídas no backup (não só o banco)
• Backups em camadas seguindo a regra 3-2-1
• Pelo menos uma cópia offsite, independente do provedor principal
• Cópia fria em provedor/local separado (cenário "provedor sumiu")
• Estratégia de contingência escolhida conforme o RTO (rebuild, reposição ou standby)
• Procedimento de failover (DR-01) escrito, com passos numerados e tempos
• Procedimento de restauração do banco (DR-02) escrito e validado
• Credenciais de recuperação guardadas em cofre acessível à equipe
• Teste de restauração isolado executado e cronometrado
• Drill de failover completo executado, comparado ao RTO alvo
• Teste do pior caso (só cópia fria) executado ao menos uma vez
• Resultados dos drills registrados e furos corrigidos
• Calendário de testes recorrentes definido (mensal/trimestral/semestral)

Com um plano de DR real, testado e em camadas, o seu servidor de MU deixa de estar a um disco falho de distância do fim. O desastre que derruba servidores despreparados vira, para você, um procedimento cronometrado com resultado previsível. É o trabalho invisível que ninguém elogia enquanto tudo funciona — e o único que importa no dia em que tudo para.

Perguntas frequentes