O aviso Attempted to load chunk saved with newer version significa que o servidor encontrou dados de mundo gravados por uma versão que o Paper atual não sabe interpretar. Isso costuma acontecer depois de trocar um JAR por uma versão mais antiga, iniciar a cópia errada do servidor ou restaurar somente parte de um backup. Trate a mensagem como um bloqueio de compatibilidade: preserve os arquivos e descubra qual versão gravou o mundo antes de tentar qualquer conversão.

Um mundo Minecraft não é um único arquivo. Regiões, entidades, dimensões, dados de jogador, datapacks e configurações podem ter sido gravados em momentos diferentes. Uma tentativa de abrir parte deles por um programa antigo pode causar perda que só aparece mais tarde, como chunks ausentes, inventários revertidos ou entidades que somem.

Interrompa as gravações e preserve o estado

Se o servidor continua ativo, salve mensagens importantes e desligue-o com o comando normal do painel ou com stop. Aguarde a confirmação de que a instância terminou. Não mate o processo Java à força, não reinicie em loop e não abra outra instância apontando para a mesma pasta. Cada inicialização pode tocar arquivos do mundo, então a primeira medida é interromper alterações concorrentes.

Faça uma cópia integral do diretório do servidor, incluindo todos os mundos, dimensões, arquivos level.dat, datapacks, configurações e plugins que guardem dados próprios. Se o mundo estiver em armazenamento remoto, confirme que a cópia terminou e que o tamanho não está crescendo. Guarde o backup em outro local e mantenha uma cópia intacta. Uma pasta duplicada no mesmo volume protege contra erros de configuração, mas não contra falha do disco.

Anote o horário, o último comando executado, o nome do JAR selecionado no painel, a versão exibida no log e a mensagem completa. Preserve logs/latest.log e os logs rotacionados. O trecho anterior ao aviso pode revelar que foi iniciado outro diretório, que uma atualização mudou a versão ou que um plugin tentou carregar uma cópia de mundo inesperada.

Confirme qual instância e qual mundo foram carregados

Leia o script de inicialização e o diretório de trabalho configurado pelo painel. Confira o caminho do JAR, o nome do arquivo de mundo em server.properties e o diretório onde os arquivos existem. Em uma hospedagem com várias instâncias, é fácil atualizar um JAR e iniciar outra pasta, ou enviar o mundo certo para um servidor que aponta para um mundo antigo.

Compare a versão de Minecraft/Paper do log atual com o registro de deploy ou backup mais recente. Verifique também se a mensagem menciona uma dimensão ou arquivo específico. Se há mundos como world_nether, world_the_end ou pastas criadas por plugins, não presuma que somente a pasta principal precisa ser recuperada. Um backup coerente precisa representar o mesmo ponto no tempo para todos os dados que se relacionam.

Se a equipe atualizou o servidor recentemente, confirme o sentido da mudança. A atualização para uma versão nova normalmente migra dados para frente, e voltar ao JAR antigo depois dessa gravação não equivale a desfazer a atualização. Reverter requer restaurar um backup criado antes da migração, não apenas selecionar o binário anterior.

Não force a leitura em uma versão antiga

Paper documenta a propriedade de JVM -DPaper.ignoreWorldDataVersion=true como opção de emergência que ignora a proteção. Ela não converte os dados para um formato antigo. O servidor pode interpretar bytes com regras erradas, sobrescrever chunks e tornar o mundo permanentemente inconsistente. Por isso, não use a opção como correção rotineira, em produção ou na única cópia do mundo.

Também não tente “consertar” renomeando arquivos, removendo regiões apontadas pelo log ou abrindo a pasta em editores aleatórios. Isso pode esconder o sintoma ao custo de descartar construções e progresso. Ferramentas de edição só devem ser usadas sobre uma cópia, com versão compatível e um objetivo específico de recuperação.

Se o teste com a propriedade de emergência for absolutamente necessário para extrair informação, mantenha-o offline, em cópia descartável e com o servidor sem acesso de jogadores ou integrações que salvem dados. Registre exatamente os argumentos utilizados. Mesmo que inicialize, isso não demonstra que o mundo foi convertido com segurança; examine regiões, inventários, dimensões e logs antes de decidir qualquer passo posterior.

Escolha entre voltar pelo backup ou continuar a atualização

Se há um backup anterior ao primeiro carregamento pela versão nova, restaure a cópia completa e verifique que ela corresponde à versão antiga. Faça a restauração em outra pasta, inicie uma instância de teste isolada e confira chunks, inventários, Nether, End, datapacks e plugins antes de substituir a produção. Nunca sobrescreva o único backup durante a validação.

Se não há backup prévio e o mundo foi efetivamente atualizado, a alternativa mais segura tende a ser continuar na versão que o gravou ou em uma versão posterior compatível. Localize o JAR correto, valide as dependências e faça cópia antes de cada etapa. Leia os avisos de migração do Paper e do Minecraft, pois mudanças entre versões podem exigir passos específicos ou incompatibilidades com plugins.

Se a versão exata que criou o mundo não está disponível, procure o histórico de deploy, arquivos antigos mantidos pelo painel e backups automatizados. Não confie apenas no nome do JAR: verifique a identificação de versão no log. Em caso de corrupção ou perda de dados, mantenha o estado atual congelado e peça suporte ao provedor ou a quem mantém a ferramenta de backup, fornecendo evidência e cópia para reprodução.

Teste a recuperação antes de reabrir o servidor

Restaure a cópia em uma instância de teste com outro diretório de trabalho, outra porta de jogo e sem acesso à rede pública. Desabilite plugins que possam enviar mensagens, cobrar pagamentos, sincronizar dados ou conectar a bancos de produção. O objetivo é verificar o mundo sem efeitos externos nem risco de duas instâncias disputarem os mesmos arquivos.

Depois do primeiro boot, procure erros de leitura, chunks ignorados, falhas de datapack e warnings de plugins. Entre com uma conta de teste e confira a área inicial, regiões construídas, inventário, baús, dimensões e pontos de teleporte. Percorra coordenadas citadas no log. Desligue normalmente, suba de novo e confirme que o estado permanece. Um mundo que apenas chegou ao menu ou aceitou a conexão ainda não foi validado.

Antes de mover a recuperação para produção, faça novo backup da cópia de teste aprovada. Planeje uma janela de manutenção, avise a comunidade e interrompa gravações na instância antiga. Mantenha a pasta original e o backup prévio separados até confirmar que a instância restaurada atende aos critérios e que a equipe consegue repetir a volta atrás.

Previna incompatibilidade na próxima atualização

Adote uma sequência simples: anuncie manutenção, desligue corretamente, gere backup completo e verificável, confirme o JAR e as dependências, atualize em staging e inspecione os dados antes de abrir acesso. Registre versão anterior, versão nova, caminho do backup e resultado do teste. Atualizações de mundo são migrações de dados, não apenas troca de programa.

Use backups com retenção que cubra vários dias e guarde ao menos uma cópia fora do armazenamento primário. Teste restaurações periodicamente; arquivo que nunca foi restaurado é uma hipótese de backup. Inclua dimensões e dados externos, como bancos SQLite/MySQL de plugins, quando eles fizerem parte da experiência do servidor.

Separe os diretórios por instância e deixe explícito no painel qual JAR e mundo cada uma usa. Evite executar scripts com diretório de trabalho implícito e mantenha um checklist de atualização. Em equipes, registre quem fez a mudança e como reverter. Essas medidas reduzem a chance de confundir um mundo recente com uma instalação antiga e tornam o próximo diagnóstico mais rápido.

Referências oficiais

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.