A propriedade region-file-compression em server.properties define como os arquivos de região do mundo são comprimidos. A referência atual do Paper lista opções como deflate, lz4, none e gzip (Paper-only no caso de GZIP). Cada opção troca uso de disco por custo de CPU e tempo de leitura ou gravação. A melhor escolha depende do armazenamento e dos padrões de acesso.

Não mude o método para corrigir lag sem medir. A compressão pode reduzir tamanho, mas aumentar processamento; desativá-la pode elevar muito o espaço usado. Ferramentas externas de backup e edição também podem não entender todos os formatos.

Entenda o equilíbrio entre CPU e armazenamento

Na leitura, o servidor precisa descomprimir dados; na gravação, precisa codificá-los. Um formato mais rápido pode reduzir tempo de CPU e produzir arquivos maiores, enquanto um formato mais compacto pode exigir mais processamento. O efeito percebido varia conforme CPU, disco, cache, número de chunks e tamanho dos mundos.

O modo none pode aumentar significativamente o espaço de disco, segundo a documentação, embora faça sentido em algumas situações com compressão no sistema de arquivos. O sistema de arquivos pode então comprimir os dados de outra forma, mas a combinação precisa ser testada, pois pode duplicar trabalho ou afetar backup e replicação.

Não compare apenas tamanho total. Meça tempo de carregamento, tempo de save, CPU, latência de disco, crescimento de backup e uso de rede. Um formato pode economizar espaço primário mas aumentar custo total de CPU e armazenamento de snapshots.

Confirme opções e compatibilidade por versão

Consulte a referência Paper da versão instalada. O suporte a formatos pode variar entre Vanilla, Paper e forks. Uma ferramenta de edição de mundo ou sistema de backup talvez não reconheça compressão específica. Confirme compatibilidade com o fornecedor antes de migrar um mundo ativo.

Inventarie todos os consumidores de arquivos de região: backups, restauração, mapa web, conversores, análise de chunks e provedores de sincronização. Faça teste de leitura e restauração com um arquivo produzido no novo formato. A ferramenta que copia bytes sem interpretar o conteúdo pode funcionar, mas isso não garante que a restauração consiga abrir o mundo.

Não misture atualização de compressão com upgrade de Minecraft ou conversão de mundo. Se uma falha acontece, será mais difícil saber se veio de data version, formato regional, ferramenta ou plugin.

Meça a causa do problema

Use spark enquanto o problema de carregamento ou salvamento ocorre. Se CPU está alta em rotinas de compressão e storage tem folga, teste formato mais rápido em staging. Se disco está saturado, um formato maior pode piorar escrita e snapshots. Se geração de chunks domina, a opção não corrige o trabalho de worldgen.

Observe também se o problema aparece ao entrar em mapa antigo, durante autosave, em reinício ou em backup. Uma fila de leitura no disco pode parecer lag; um plugin que sincroniza dados de região pode ter custo diferente. Capture logs e compare operação de cópia isolada.

Considere o tipo de volume e cache. SSD, HDD, rede ou volume virtual têm latências distintas. Resultados de um servidor de teste em RAM disk não são uma previsão confiável para produção em storage remoto.

Planeje uma migração em cópia

Antes de editar, desligue Paper normalmente e faça backup externo de todos os mundos, dimensões, configurações e bancos relacionados. Valide a integridade do arquivo e guarde cópia original. Configure uma instância de staging com novo formato e teste carregar, salvar, desligar, reiniciar e fazer backup.

Se o Paper converte ou interpreta o formato ao gravar, a primeira gravação pode alterar dados. Compare região de teste e avalie se a ferramenta consegue ler depois. Não abra a produção em duas instâncias nem altere `server.properties` enquanto uma está ativa.

Faça inventário de tamanho antes e depois, tempo de início, CPU e disco. Teste restauração completa numa pasta diferente e confirme chunks, construções, inventários, Nether, End e plugins. Mantenha original até o retorno estar validado.

Altere gradualmente e monitore

Quando teste passa, aplique em janela de manutenção com backup recente e plano de rollback. Confirme o valor na configuração ativa, reinicie e observe vários ciclos de autosave e operações de jogador. Monitore espaço, logs, duração de start e resposta de mapa web.

Faça benchmark sob carga semelhante à produção. Se usa múltiplos mundos ou discos, teste cada tipo. Uma configuração global não necessariamente produz os mesmos efeitos em todos os volumes e versões.

Se erro ocorre, pare o servidor, preserve logs e restaure conjunto consistente de formato e backup. Trocar de volta a propriedade pode não reverter arquivos já gravados; restaure os dados da cópia anterior se necessário. Essa diferença torna o backup pré-migração essencial.

Considere espaço e retenção de backups

Arquivos menos comprimidos crescem no disco primário, nos snapshots e durante restauração temporária. Garanta espaço para pelo menos uma cópia de trabalho além da produção e monitore quota. Um volume cheio pode impedir salvamento e provocar falha operacional.

Compactação do backup pode aplicar outra compressão sobre dados já comprimidos, oferecendo pouco ganho e consumindo CPU. Meça processo de backup separadamente. Defina retenção e limpeza para não deixar a migração consumir todo o armazenamento.

Use cópias em outro volume e ensaio de restauração. Segurança do mundo depende de backup consistente mais capacidade para recuperar, não apenas do nível de compressão configurado.

Registre a decisão técnica

Anote versão do Paper, formato anterior e novo, host, volume, tamanho, benchmark e resultado de compatibilidade das ferramentas. Compartilhe a decisão com equipe e mantenha plano de retorno. Refaça teste quando mudar hardware, método de backup ou software que lê regiões.

Se não há gargalo mensurável ou necessidade de espaço, manter padrão atual pode ser a melhor escolha. Ajuste somente para um objetivo que possa ser medido, com cópia integral e validação de recuperação.

Valide backups e ferramentas de mundo

Teste cada utilitário que vai ler ou copiar os arquivos após a migração. O software pode listar diretórios sem interpretar dados, mas falhar ao abrir região comprimida com algoritmo desconhecido. Verifique logs de backup, restaure ao menos um mundo e compare uma coordenada conhecida.

Se uma plataforma de mapa web precisa ler mundo offline, faça teste de renderização e atualização. Se usa transferência incremental ou deduplicação, confira se alteração de compressão muda volume e tempo de upload. Planeje espaço temporário para cópias antigas e novas.

Procure suporte explícito ao formato selecionado em documentação do autor. Não force parser antigo a ler dados desconhecidos; uma ferramenta pode ignorar arquivo e criar relatório incompleto.

Planeje janela e capacidade de armazenamento

Uma mudança que regrava regiões pode demandar espaço extra para snapshot e arquivos temporários. Calcule folga antes de iniciar. Interrompa se volume fica perto do limite, pois falta de espaço durante gravação pode causar falha mais grave que o problema original.

Comunique tempo de manutenção e duração de pré-processamento. Teste com uma região grande e dimensões distintas para estimar intervalo, reconhecendo variação. Mantenha equipe disponível para rollback e restauração.

Faça housekeeping de backups somente depois de nova cópia e recuperação serem validadas. Nunca elimine versão anterior para liberar espaço antes de confirmar que o novo formato funciona com seus consumidores.

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.