A configuração ticks-per.autosave em bukkit.yml controla o intervalo de salvamento automático dos mundos, medido em ticks. A referência do Paper também informa que uma configuração de mundo, chamada auto-save-interval, pode substituir o intervalo global. Essa relação é essencial: editar o número global não muda um mundo que tem override próprio.

Autosave ajuda a persistir o estado do mundo durante a operação, mas não é backup. Ele não guarda necessariamente arquivos externos, configurações, dados de plugins e cópias históricas. Se um jogador apaga uma construção por engano e o autosave grava a mudança, só uma cópia de backup anterior permite voltar atrás.

Entenda ticks e intervalo

O servidor tenta manter 20 ticks por segundo. Um valor de 6.000 ticks corresponde a cerca de cinco minutos se a instância realmente sustentar essa frequência. Em lag severo, tempo de parede e número de ticks não avançam da mesma maneira. O intervalo deve ser lido com esse contexto, e não como um cronômetro exato que sempre dispara a cada cinco minutos de relógio.

Reduzir o número pede tentativas de salvamento mais frequentes; aumentá-lo as espaça. O custo depende de quantos chunks estão ativos, da atividade do mundo e da configuração de gravação. Um valor muito frequente pode aumentar trabalho de IO, enquanto um intervalo longo pode ampliar o estado que se perde se houver falha entre salvamentos. Não escolha um extremo sem medir e definir tolerância de perda.

Não use -1 para desligar o autosave por conveniência sem compreender a consequência e dispor de um processo alternativo testado. A documentação descreve esse valor como desativação. Um desligamento não planejado, queda de energia ou encerramento de processo pode deixar alterações recentes fora do disco.

Confira quem controla o mundo

Leia bukkit.yml da instância correta e procure configurações Paper por mundo. Os arquivos padrão podem estar em config/paper-world-defaults.yml, enquanto os específicos ficam associados aos próprios mundos. Confirme a estrutura atual na documentação, pois caminhos podem mudar entre versões.

Se existe auto-save-interval específico, ele pode substituir o valor em ticks-per.autosave. Registre qual mundo herda o padrão e qual possui override. Faça a revisão para Overworld, Nether, End e mapas adicionais, além de mundos temporários que podem conter progresso importante.

Após editar, reinicie conforme necessário e examine o log por problemas de YAML ou configurações inválidas. Compare o arquivo antes e depois do boot: painéis e plugins de hospedagem podem gerar configurações. Em staging, execute uma alteração e observe se há diferença no comportamento e nas métricas.

Separe autosave de backup

Autosave atualiza o estado corrente do mundo; backup preserva uma cópia recuperável em outro ponto no tempo. Um backup adequado deve incluir os mundos e dimensões, configuração relevante, dados de plugins e bancos externos que sustentam permissões, economia, inventários ou outras funções. Garanta consistência: cópia a quente deve usar ferramenta ou rotina compatível com a forma como o servidor grava dados.

Tenha retenção diária e mais longa de acordo com o custo de refazer progresso. Mantenha pelo menos uma cópia fora do armazenamento principal e teste a restauração em diretório isolado. Um arquivo que concluiu upload não está validado até ser restaurado e aberto em uma instância de teste.

Se um mundo salva a cada poucos minutos, isso ainda não protege contra corrupção, erro humano ou alteração feita por plugin. E se a cópia mais nova foi tirada depois do incidente, ela pode reproduzir a perda. Documente qual ponto de restauração atende a cada cenário e quem pode iniciar recuperação.

Meça antes de mudar o intervalo

Registre carga no momento das gravações, número aproximado de chunks ativos, MSPT, atividade de disco e mensagens no log. Use profiling durante o problema, seguindo a orientação atual do Paper. Se a lentidão ocorre quando muitos chunks são salvos, avalie o subsistema de IO antes de simplesmente aumentar o intervalo.

Teste em staging com cópia representativa e mesmo tipo de armazenamento. Mude uma configuração por vez. Compare períodos semelhantes de jogador e mundo; salvamento de áreas distintas pode produzir resultados diferentes. Observe também se o servidor tem atrasos de salvar jogadores, dados de plugins ou arquivos de configuração, que não são equivalentes ao autosave de chunks.

Defina uma meta de recuperação em vez de escolher valor por popularidade. Se a comunidade não pode perder mais de alguns minutos, uma rotina de backup frequente e consistente pode ser tão importante quanto autosave, mas mede risco diferente. Alinhe frequência, durabilidade e custo de disco com a capacidade operacional.

Implemente com uma reversão clara

Antes de editar, desligue corretamente ou siga o procedimento recomendado para a configuração. Faça cópia dos arquivos e anote os valores atuais por mundo. Se a mudança exigir reinício, informe a equipe e confirme o processo encerrado antes de alterar. Evite editar YAML em produção enquanto vários operadores mudam outras opções sem registro.

Promova a mudança para uma janela de menor atividade. Após o boot, confirme os arquivos, logs e disponibilidade dos mundos. Observe o próximo ciclo de salvamento e os indicadores de desempenho. Se há erro ou piora, restaure as cópias e verifique os dados antes de permitir que jogadores voltem.

Guarde o motivo, responsável, horário e resultado. Um valor alterado após um pico deve ser revisto quando a causa for resolvida. Sem registro, a equipe não sabe se o intervalo é intencional ou uma tentativa temporária e pode substituir um parâmetro que tinha outra finalidade.

Planeje recuperação e continuidade

Use rotinas de backup com nomes, data e versão da instalação. Preserve backups anteriores a atualizações de Minecraft ou Paper, porque formatos do mundo podem avançar e dificultar voltar apenas trocando o JAR. Faça ensaio de recuperação em uma instância sem acesso de jogadores e sem banco de produção.

Se uma falha acontece, pare gravações concorrentes, preserve logs, faça cópia integral e determine se o último salvamento deixou dados inconsistentes. Restaure em outra pasta e valide construções, jogadores, dimensões e plugins antes de promover. Não sobrescreva a única cópia durante o diagnóstico.

A configuração de autosave é parte da operação do mundo, mas seu valor correto depende de risco, IO, quantidade de chunks e estratégia de backup. Consulte a referência do Paper para cada versão e mantenha evidência de testes no seu ambiente.

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.