A propriedade level-name em server.properties indica o nome do diretório do mundo principal que o Paper deve usar. Se o valor aponta para outra pasta, o servidor pode carregar um mundo diferente ou gerar um novo, dando a impressão de que construções desapareceram. Antes de renomear ou editar, identifique a pasta ativa e faça cópia completa.
O nome não é necessariamente o título visível para jogadores nem uma URL. É parte do layout de dados no diretório da instância. Em instalações com dimensões, plugins e vários mundos, caminhos podem ser mais complexos do que um único diretório chamado world.
Localize a pasta e a instância certas
Confira o diretório de trabalho do processo no painel ou script. Leia level-name da mesma instância que gera o log. Verifique se existe uma pasta com esse nome e se contém dados de mundo esperados, como level.dat e arquivos de região. Não se baseie apenas no nome exibido no gerenciador de arquivos.
Se há várias instalações, marque o JAR e o caminho do mundo de cada uma. Uma instância de teste pode ter mesmo nome de pasta e porta diferente. Compare data e tamanho dos arquivos antes de fazer qualquer restauração.
Em ambientes com painel, diretório do servidor pode ser diferente do diretório do upload. Um script iniciado em pasta incorreta pode criar um mundo novo sem alterar a pasta antiga. Confirme processo, working directory e path do JAR antes de concluir que os dados foram apagados.
Entenda o que acontece ao mudar o nome
Se Paper não encontra o diretório indicado, pode gerar mundo novo conforme configuração do servidor. Isso não migra automaticamente blocos, inventários, dimensões ou dados de plugin do mundo anterior. Jogadores podem nascer num mapa vazio enquanto o mundo original continua intacto em outra pasta.
Trocar `level-name` não renomeia com segurança todos os dados associados. Nether e End, plugins de múltiplos mundos, claims e bancos externos podem usar nomes e caminhos próprios. Antes de mover ou renomear, leia documentação de migração e descubra como cada plugin referencia seus dados.
Se o objetivo é mudar a pasta para outro nome, desligue o servidor, faça snapshot integral e teste em staging. Preserve mundo antigo e novo sem sobreposição até verificar dimensões, dados de jogador, spawn e teletransportes.
Recupere um mundo aparentemente desaparecido
Pare a instância e evite jogar ou construir no mundo novo. A atividade grava dados e pode confundir investigação. Faça backup da instalação inteira, depois procure pastas de mundo com timestamps e arquivos de região. Leia o início de latest.log para saber o caminho e nome usados durante startup.
Se encontrar mundo antigo, restaure numa cópia e altere `level-name` apenas nela. Inicie com versões compatíveis e verifique spawn, chunks conhecidos, dimensões, inventários e plugins. Não sobrescreva pasta ativa até ter uma recuperação válida.
Se houve atualização de versão, considere se os dados foram migrados. Paper avisa que chunks gravados por versão mais nova podem não abrir por versão antiga. Voltar ao JAR sem restaurar snapshot compatível pode provocar erro ou corrupção.
Planeje mundo novo ou rotação de temporada
Para iniciar mapa novo, escolha um novo nome conscientemente, mantenha o antigo em backup e anuncie temporada. Decida se jogadores podem acessar mundo legado para consulta e como itens, claims, economia e inventários serão tratados. Um mundo novo com mesmo banco de plugin pode herdar dados antigos inesperadamente.
Use estrutura organizada por temporada e instância. Não apague mundo anterior até confirmar retenção, exportação e política da comunidade. Se pretende voltar ao mapa, guarde Paper, datapacks, plugins e versões usadas com o snapshot.
Teste portais, Multiverse, spawn, mapa web e comandos. Plugins podem manter UUID de mundo ou paths próprios; renomear pasta sozinha não altera essas referências. Confirme documentações de addons antes da migração.
Faça backup e mudança reversível
Antes de mudar, desligue com comando normal e aguarde encerramento. Copie todos os mundos, bancos externos, configurações e plugin data para armazenamento diferente. Compare lista de arquivos e valide que cópia terminou. Mantenha o original intacto durante o teste.
Edite `level-name` numa configuração copiada, inicie em pasta e porta de staging e monitore log. Se encontrar dados inesperados, pare e volte ao snapshot. Só promova à produção quando confirmar mundo correto e dependências.
Registre nome, caminho, motivo, versões e responsável. Em painel, confira se a configuração aplicada sobrevive a reinicialização e se o gerenciador ainda aponta para a pasta certa.
Evite editar arquivos de mundo enquanto o servidor roda
Copiar, mover ou renomear região enquanto Paper está ativo pode produzir snapshot inconsistente ou concorrência de escrita. Pare o processo normalmente ou use método de backup suportado. Nunca execute duas instâncias apontando à mesma pasta de mundo.
Se mundo usa link simbólico ou volume montado, confirme que o caminho real permanece dentro do armazenamento pretendido e que permissões do serviço são adequadas. Desativar validações ou ignorar caminhos não deve ser primeiro passo para resolver um link quebrado.
O desaparecimento de construções muitas vezes é problema de instância ou nome de pasta, não perda definitiva. Logs, inventário de diretórios e cópia integral ajudam a localizar dados sem destruir a evidência.
Confira outros caminhos de mundo
Paper permite configurar `world-container` em `bukkit.yml` para mudar o diretório em que arquivos de mundo são armazenados. CLI arguments também podem sobrescrever propriedades, incluindo o nome do mundo. Portanto, verifique container, argumentos do startup e propriedades do painel ao lado de `level-name`.
Plugins como gerenciadores de múltiplos mundos podem criar mundos com gerador e pasta próprios. Leia seus comandos e configurações antes de mover o mundo. Um mundo principal e um mundo carregado por plugin podem compartilhar dimensões ou banco, mas não necessariamente o mesmo caminho.
Se servidor inicia com nome diferente do esperado, capture o comando real, o log de bootstrap e a saída do painel. Compare caminhos absolutos; letras de unidade, diretórios relativos e montagem de volume podem mudar o que o processo enxerga.
Valide integridade da cópia
Depois de copiar mundo, compare quantidade e tamanho de arquivos e mantenha registro de cópia. Tente abrir a restauração com a mesma versão e plugins. Inspecione um conjunto de coordenadas conhecidas em regiões afastadas para encontrar cópia incompleta ou dimensão faltando.
Não use mundo de backup como produção até testar consistência e dados de plugin. Se sistema externo como economia foi copiado em outro momento, jogador pode ver estado divergente. Defina uma janela comum de snapshot ou desligue todos os componentes que gravam antes.
Se o mundo tem symlink, volume, junction ou path fora da pasta, confirme que backup inclui o destino real. Evite clicar em renomear enquanto processo está ativo; o servidor precisa encerrar gravações antes da operação.
Fontes e referências
- Paper: server.properties level-name
- Paper: formato e configuração de mundos
- Paper: migração de dados de mundo
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.