Paper permite configurar um intervalo de autosave por mundo por meio de auto-save-interval. A referência explica que ele substitui ticks-per.autosave global em bukkit.yml; quando não há override, o intervalo usa o valor global. Isso permite políticas diferentes para mundos com atividade ou importância distintas, mas também aumenta a necessidade de inventário e teste.

Intervalo de autosave é política de gravação do estado atual, não retenção de versões. Ele não substitui cópias históricas e não garante que arquivos de plugins ou bancos externos estejam incluídos. Para planejar recuperação, combine salvamento, backups e teste de restauração.

Como o intervalo por mundo funciona

O valor indica a frequência de autosave para o mundo em ticks. Se o mundo tem uma configuração própria, o valor global pode ser ignorado para aquele caso. A relação precisa ser conferida na referência atual e no arquivo realmente usado. Uma configuração por mundo que diz default pode herdar o valor global, conforme a documentação.

O servidor busca 20 ticks por segundo, mas, sob lag, ticks atrasam em tempo real. Assim, um intervalo de ticks não é um agendamento de relógio civil. Use valores e métricas do Paper para a versão instalada e não traduza o intervalo em promessa exata de minutos sob carga severa.

Mundos temporários podem parecer menos importantes, mas ainda conter progresso de eventos, inventários ou construções. Um mundo com menor intervalo não torna os outros seguros automaticamente. Mapeie as dimensões e decide a perda tolerável de cada uma antes de definir políticas diferentes.

Faça inventário dos mundos e dados relacionados

Liste Overworld, Nether, End, mundos de lobby, mapas de evento, instâncias criadas por plugins e cópias de teste. Para cada um, anote caminho, finalidade, atividade média, plugins que escrevem dados e valor efetivo de autosave. Confirme nomes de mundo e pastas através de configuração, painel e log.

Dados de jogador e plugins podem ser gravados por ciclos próprios. Economia, claims, permissões, inventários customizados e estatísticas podem estar em arquivos locais ou bancos remotos. Inclua esses sistemas na estratégia de backup e consistência, e não suponha que o autosave do mundo cubra todo o estado do servidor.

Se o mundo é gerado por plugin ou não está no diretório esperado, localize sua configuração antes de alterar. Faça a auditoria em cópia e evite iniciar uma instância sobre o mesmo armazenamento enquanto a produção está ativa.

Defina o risco e frequência necessários

Comece perguntando quanto progresso cada mundo pode perder sem afetar a comunidade. Mundos criativos permanentes, arenas competitivas e eventos com prêmio podem merecer intervalos ou backups diferentes. A frequência do autosave precisa ser compatível com recursos de disco e a atividade de chunks, e a frequência do backup precisa atender recuperação de incidentes.

Intervalo curto tende a provocar mais ciclos de salvamento e pode afetar IO dependendo da carga; intervalo longo deixa mais tempo entre gravações. Nenhum valor serve para todos os hosts. Compare comportamento sob carga real e use profiling se houver pausas ou MSPT elevado associado ao salvamento.

Para mundos quase sempre vazios, não decida com base apenas na baixa atividade atual. Considere quando eventos ocorrem, quantos chunks são alterados e o custo de refazer progresso. Uma dimensão pouco usada pode guardar uma temporada inteira ou uma área valiosa da comunidade.

Configure herança sem perder controle

Confirme os arquivos documentados para Paper na versão instalada. A referência atual separa configuração padrão global e arquivo de mundo. Um mundo pode herdar padrões, usar override específico ou ter arquivo gerado por software de painel. Leia comentários e valores após o boot e valide avisos de configuração.

Faça cópia dos YAML, mantenha indentação e altere somente o escopo desejado. Se definir override, registre que o valor global deixa de reger aquele mundo. Padronize como a equipe nomeia e revisa valores; overrides esquecidos podem sobreviver a atualizações e produzir política diferente da pretendida.

Não modifique o intervalo no meio de atualização do JAR ou migração de mundo. Separe as mudanças para saber qual causou falha. Se Paper reorganizar arquivos durante a atualização, faça comparação e siga o guia de migração oficial antes de recolocar overrides antigos.

Teste salvamento e recuperação em staging

Copie mundo e dados de plugins para instância isolada. Altere um mundo e execute um cenário com mudanças de blocos, jogadores e entidades. Desligue corretamente e reinicie. Confira arquivos, construções, inventários, dimensões e integrações. Repita para cada tipo de mundo com política diferente.

Teste um backup anterior e faça restauração em outro diretório. Confirme que a cópia contém um ponto consistente e pode ser carregada. A verificação deve cobrir plugins que guardam dados fora do mundo. Mantenha o backup original intacto durante o teste e documente o tempo necessário para voltar à operação.

Monitore logs de autosave, IO, memória e ticks. Se existem pausas, execute spark enquanto o problema está ocorrendo e analise o relatório. Uma medição após o problema passou não vai mostrar o método ou gravação que causou o pico.

Promova a política e comunique a equipe

Agende a alteração, desligue o servidor, confirme backup e aplique os arquivos testados. Na subida, confirme que todos os mundos carregaram e que os caminhos são corretos. Observe pelo menos vários ciclos em períodos de atividade diferentes, incluindo pico se o uso da rede varia.

Documente para cada mundo o intervalo, se herda o global, a razão e a tolerância de perda. A equipe deve saber qual backup usar e como restaurar. Se a política muda depois de um incidente, explique os limites para os jogadores sem prometer recuperação de pontos que não estão retidos.

Reavalie após mudança de hardware, atualização de Paper ou crescimento da comunidade. Armazenamento mais rápido pode mudar o custo do salvamento; novas dimensões e plugins mudam cobertura. A revisão baseada em evidência mantém o autosave alinhado com a operação real.

Evite as armadilhas comuns

Não desative autosave para esconder lag, nem aumente o intervalo global sem conferir overrides. Não confunda sincronização do servidor com backup e não mantenha uma cópia única no mesmo disco. Evite copiar números de outra versão sem verificar documentação atual. Cada uma dessas ações pode criar risco sem resolver a causa.

Se o servidor usa armazenamento lento, investigue o provedor e perfis de IO. Se um único mundo domina a carga, ajuste ou corrija aquele mundo, em vez de alterar toda a rede. Se a prioridade é recuperação rápida, invista em backup confiável, retenção e ensaio. O intervalo de autosave faz parte do plano, mas não é o plano completo.

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.