Migrar um servidor Minecraft Java para outra hospedagem sem perder progresso

Migrar um servidor Java envolve terreno, inventários, dimensões, permissões, plugins, mods e identidade dos jogadores. A hospedagem antiga deve permanecer parada e disponível para retorno até que a nova passe por uma validação privada completa.

Faça o inventário antes da manutenção

Registre versões de Minecraft e Java, software e build, loader, mods, plugins, datapacks, memória, argumentos, porta, online-mode, proxy e opções exclusivas do painel. Liste todos os mundos e dimensões; Paper, plugins multiworld e mods podem usar layouts diferentes.

Anote também DNS, endereço público e porta. Transforme economia, claims, homes e permissões em itens concretos de teste.

Gere um backup autoritativo com tudo parado

Avise a manutenção, bloqueie entradas, salve quando necessário e execute stop. Só depois compacte o diretório completo. Armazene o arquivo fora das duas hospedagens, registre o tamanho e compare hashes quando possível.

Não cancele nem reabra a hospedagem antiga. Uma cópia ao vivo pode misturar dados de momentos diferentes e não serve como ponto confiável de retorno.

Prepare um destino compatível

Instale a mesma versão de Java, servidor, loader, mods e plugins. Ao trocar entre Vanilla, Spigot, Paper, Fabric ou Forge, siga a documentação do software para o layout dos mundos. Inicie uma vez apenas se o painel precisar criar arquivos, depois pare e arquive esse teste.

Confira espaço, proprietário dos arquivos, comando de início, porta e raiz real. Um upload correto na instância errada parece exatamente um upload ausente.

Transfira mundos, identidades e configuração juntos

Envie e extraia o snapshot pelo método aceito. Verifique level-name, mundo principal, Nether, End, jogadores, avanços, estatísticas, datapacks, whitelist, bans, operadores, permissões e bancos de plugins.

Não inclua senhas ou chaves em arquivos públicos; rotacione o que tiver sido exposto. Preserve online-mode e encaminhamento de identidade do proxy, pois outro UUID pode simular perda de inventário e permissões.

Teste por um endereço privado

Não troque o domínio ainda. Restrinja com whitelist ou endereço temporário e leia o boot completo. Resolva dependências, versões e permissões. Teste com administrador e usuário comum: spawn, construções, dimensões, inventários, economia, claims, portais e comandos.

Faça uma alteração, pare e reinicie. Uma conexão bem-sucedida não demonstra que o servidor grava e reabre corretamente.

Faça a virada sem dois mundos graváveis

Após aprovação, mantenha o antigo desligado e altere DNS, proxy ou endereço publicado. Nunca abra as duas cópias para jogadores reais: o progresso se divide imediatamente e não existe fusão genérica segura.

Monitore logs e erros na primeira sessão. Cache de DNS pode levar alguns usuários ao host antigo. Mantenha backups e serviço anterior até confirmar reinício real e rotinas automáticas.

Reverta como uma operação inteira

Se o novo destino danificar dados ou não suportar a pilha, pare-o primeiro. O retorno mais limpo restaura o snapshot autoritativo no host anterior e devolve o endereço, em vez de copiar arquivos soltos nos dois sentidos.

Documente o erro e o item de aceitação que falhou. Mudar versão, layout e seleção de arquivos ao mesmo tempo esconde a causa.

Critérios para concluir

• Ambiente, mundos e painel foram inventariados.
• O backup foi criado após parada limpa e guardado fora dos hosts.
• O destino replica a pilha ou segue migração documentada.
• Mundos, identidade, permissões e configuração viajaram juntos.
• Testes privados cobriram logs, jogadores, dimensões, gravação e reinício.
• Apenas um servidor público aceitou gravações durante a virada.
• O host antigo segue disponível durante o período de risco.

A migração termina quando a comunidade continua sua história e existe recuperação testada, não quando o painel novo fica verde.