A configuração flush-regions-on-save aparece na referência de mundo do Paper e controla se o servidor faz flush dos chunks para armazenamento quando eles são salvos. A documentação alerta que isso pode ter impacto de desempenho. Por isso, o ajuste envolve uma pergunta operacional: qual nível de persistência seu armazenamento garante, qual risco quer reduzir e quanto trabalho adicional a instância aguenta?

“Salvar” e “flush” podem significar etapas distintas entre aplicação, cache do sistema operacional, dispositivo e armazenamento remoto. A opção não substitui backups, cópias históricas ou teste de restauração. Antes de interpretar seu efeito, consulte a descrição da versão atual e entenda a infraestrutura onde o Paper está executando.

Entenda flush e persistência

O Paper escreve dados de chunks em arquivos de região. Um flush procura garantir que dados relacionados ao salvamento sejam empurrados até o sistema de armazenamento segundo os mecanismos disponíveis. O comportamento final depende do sistema operacional, sistema de arquivos, controladora, volume virtualizado e provedor de nuvem; o parâmetro não pode tornar confiável um disco defeituoso ou armazenamento remoto mal configurado.

Em sistemas virtualizados, a confirmação de gravação pode vir de uma camada intermediária. O operador precisa conhecer o contrato e as garantias do provedor. Não prometa recuperação só porque o flush está ativo. Um backup independente e restaurável continua sendo a defesa para corrupção lógica, exclusão e falha completa.

A documentação indica possível impacto de desempenho. Gravações mais estritas podem aumentar latência de IO ou causar espera dependendo do ambiente. O custo pode ser pequeno numa unidade rápida e significativo em volume congestionado, armazenamento de rede ou quando muitas regiões são atualizadas simultaneamente.

Decida qual risco está tentando tratar

Se a preocupação é perder os últimos minutos após queda de energia, ajuste a estratégia de backup, autosave, proteção física e expectativas do provedor. Se existe evidência de dados que não persistem após reinício inesperado, reúna logs, tipo de volume e sequência de eventos para investigar a infraestrutura. O flush pode fazer parte do teste, mas não deve ser aplicado como resposta reflexa.

Se o gargalo é disco durante operação, ativar uma opção com custo potencial pode agravar a experiência. Faça perfil durante o pico e examine latência de IO, filas e tempo de tick. Confirme se o problema se associa a gravação de chunks, plugins, banco externo ou snapshot da máquina virtual.

Defina a tolerância de perda e as obrigações do serviço. Um servidor casual e um mundo comunitário com compras ou anos de progresso têm perfis diferentes. Escolha políticas documentadas e explique as garantias reais, evitando prometer “zero perda” sem controle sobre toda a cadeia de armazenamento.

Teste no armazenamento representativo

Crie uma cópia isolada com Paper e volume comparável à produção. Não teste somente numa estação rápida se produção usa armazenamento remoto. Faça snapshot antes e selecione um workload repetível: exploração que modifica chunks, construção, autosave normal e desligamento. Mude a opção de forma controlada e compare latência, MSPT, logs e integridade dos dados após reiniciar.

Repita ciclos e teste uma restauração para validar que os arquivos de região podem ser abertos. Para simular falha de energia, não interrompa produção; use ambiente de teste e métodos do provedor, com conhecimento de riscos. Uma única inicialização bem-sucedida não revela se há efeito sobre pausas ou integridade em casos limite.

Confirme também como a configuração é aplicada: global, por mundo ou herdada, conforme a estrutura da versão. Teste o mundo principal, dimensões e mundos separados. Não altere simultaneamente o autosave, máximo de chunks por tick e política de backup se pretende atribuir o resultado a flush.

Configure com segurança

Desligue o servidor corretamente, copie os arquivos relevantes e preserve uma configuração reversível. Edite o arquivo de mundo documentado para sua versão, mantendo indentação e nomes. Se a mudança for em YAML, confira o log do próximo boot para erros e leia o arquivo regenerado.

Verifique se o painel, script ou plugin não sobrescreve o arquivo. Confirme a pasta ativa e o mundo ao qual o parâmetro se aplica. Documente o valor anterior, o novo e o motivo. Tenha procedimento para retornar à opção prévia se a latência piorar ou o comportamento não for o esperado.

Aplique em janela de baixa atividade e monitore até atravessar vários ciclos de salvamento. Observe tempos de tick, saturação de disco, atrasos no desligamento e mensagens de falha. Se houver aumento inaceitável de IO ou nenhum benefício, reverta e investigue o storage em vez de acumular opções.

Backups continuam necessários

Mantenha cópias externas com retenção, incluindo dimensões, configuração e bancos de plugins. Use uma estratégia consistente, compatível com o modo como os arquivos são escritos. Guarde pelo menos uma cópia fora do volume primário e monitore se os jobs concluem sem erro.

Faça ensaios de restauração num diretório separado, em uma instância de teste sem acesso aos dados de produção. Confira chunks conhecidos, inventários, teletransportes, dados de plugins e reinício. Registre duração e problemas, e mantenha o backup original intacto enquanto valida o resultado.

Flush e backup atendem questões diferentes. O primeiro influencia persistência da gravação corrente; o segundo cria um ponto recuperável no tempo. Backup também protege contra erros humanos e software que grava dados semanticamente incorretos. Uma política robusta precisa de ambos os controles de acordo com o risco real.

Comunique garantias e limites

Explique à equipe quais volumes hospedam o mundo, quais cópias existem, quanto tempo são retidas e como restaurar. Indique o resultado dos testes e os limites conhecidos da plataforma. Uma configuração isolada não é uma certificação de durabilidade e não substitui informação do provedor sobre snapshots, cache e replicação.

Quando pedir suporte, envie versão do Paper, sistema operacional, tipo de armazenamento, log e passo reproduzível. Remova dados de conta e credenciais antes de compartilhar. O autor do servidor pode ajudar a identificar o fluxo de gravação, enquanto o provedor precisa explicar as garantias da camada de storage.

Revise após trocar host, volume, sistema de arquivos ou versão de Paper. Esses fatores mudam o perfil de latência e as garantias práticas. Preserve sempre cópia recuperável antes de usar o servidor como ambiente de teste para opções de durabilidade.

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.