Atualizar Paper ou um plugin pode corrigir problemas, acompanhar uma versão nova do Minecraft e trazer recursos úteis. Também pode mudar formato, comportamento ou dependências. Uma cópia recuperável e um teste que reproduz o uso real tornam a manutenção previsível; sem isso, incompatibilidade aparece junto com os jogadores.

O processo abaixo usa um servidor de teste quando possível e organiza o rollback antes de instalar. Procedimentos variam por versão; consulte a documentação do Paper e de cada plugin. Evite atualizar vários componentes simultaneamente quando você precisa saber qual mudança alterou o resultado.

Inventarie a instalação atual

Registre a versão do Minecraft, Paper e Java, os plugins, bibliotecas, datapacks, pacotes de recursos e diretórios de mundo. Guarde o log de inicialização saudável. Uma lista ajuda a perceber dependências esquecidas, versões duplicadas ou um plugin que só tem build para determinada combinação.

Leia notas de versão dos componentes candidatos. Verifique compatibilidade, mudanças de configuração e dependências, sem presumir que o número maior é sempre apropriado. Baixe JAR de canal oficial do projeto e confira integridade quando o publicador oferecer hash ou assinatura.

Escolha janela e comunique

Planeje quando menos jogadores estiverem conectados, defina responsável e duração estimada e informe se o acesso ficará fechado. Se a comunidade depende de eventos ou horários de pico, evite surpreendê-la no meio de uma atividade. Não prometa hora exata se o teste ainda puder revelar problemas.

Tenha acesso ao painel, console, SFTP ou gerenciador de arquivos e uma cópia de segurança. Confira espaço disponível antes de duplicar um mundo grande. Combine quem autoriza reabrir e em que condições a equipe retorna à versão anterior.

Crie e valide backup consistente

Faça a cópia com o processo completamente parado ou use um sistema que garanta consistência durante a execução e cujo procedimento você conhece. Inclua mundos e dimensões, configurações, plugins e dados não reconstruíveis, como banco externo ou arquivos de permissões. Um arquivo compactado sem banco pode parecer completo e falhar na recuperação.

Confirme que o backup existe, tem tamanho esperado e pode ser extraído ou restaurado numa pasta de teste. Registre a data e um local fora do servidor quando a hospedagem recomendar. Backup nunca testado é só esperança; não prossiga até saber como recuperar o último estado funcional.

Atualize primeiro a cópia de homologação

Duplique os arquivos para uma instância isolada, com portas e endereço diferentes e integrações de produção desativadas, como pagamentos e webhooks. Atualize Paper e os componentes previstos. Não permita que a cópia use o mesmo diretório ou banco de dados da produção.

Inicie e acompanhe a sequência de carregamento. Resolva dependências ausentes, warnings relevantes e erros de migração com a documentação do autor. Faça login com contas de teste, acesse mundos e use comandos importantes. Exercite permissões, inventário, economia, proteções, teleporte e eventos conforme o projeto.

Atualize plugins com rotina controlada

Pare completamente antes de trocar JARs e não use reload quente como substituto para reinício. O comando de reload é conhecido por causar problemas com plugins; faça a atualização seguindo método recomendado pelo servidor e pelo autor. Remova versões duplicadas quando fizer sentido e deixe apenas o artefato correto no diretório.

Comece pelas dependências fundamentais quando os autores definirem uma ordem e então atualize os plugins dependentes. Se um plugin não carrega, copie o erro integral e identifique a primeira causa do log. Remover uma biblioteca pode quebrar outros plugins; mapeie as dependências antes. Registre cada arquivo trocado para o rollback não depender da memória.

Aplique a mudança na produção

Depois de a homologação passar, confirme a janela, pare completamente a produção e faça backup final. Substitua o JAR e os plugins planejados usando o painel. Faça somente as mudanças aprovadas; evite aproveitar a manutenção para editar configurações sem necessidade.

Inicie com a equipe acompanhando console e monitoração. Verifique a versão, erros críticos, mundos carregados, conexão, comandos e permissões. Uma checagem externa confirma que a rede aceita jogadores. Mantenha a janela aberta até completar as verificações, não apenas até o servidor aparecer online.

Defina critérios claros para rollback

Volte à cópia se o servidor não iniciar, uma migração inesperada ocorrer, dados importantes sumirem, sistemas essenciais falharem ou houver degradação que não possa ser contida. Pare antes de restaurar para evitar dois processos gravando no mesmo mundo. Registre o problema e a versão que falhou.

Um mundo salvo por versão nova pode não abrir numa versão anterior. Restaurar exige alinhar binário e dados; trocar somente o JAR nem sempre reverte formatos ou migrações. Não abra o mundo atualizado com versão antiga até verificar a compatibilidade e o caminho recomendado. Uma cópia anterior validada pode ser o retorno seguro.

Feche a manutenção com aprendizado

Quando tudo estiver estável, atualize inventário, notas e backup. Compare carga e funcionalidades com a linha de base. Descreva versão, sintomas e mitigação; isso ajuda a equipe a distinguir regressão de efeito de uma configuração antiga.

As orientações oficiais do Paper sobre atualização e diagnóstico recomendam backup e verificação. Para JARs, consulte o guia de instalação de plugins. Confirme os passos atuais antes da próxima janela.

Confira bancos e serviços externos

Quando plugins gravam dados em banco externo, faça uma cópia compatível e saiba se o plugin executa migração ao iniciar. Arquivo de mundo recuperado com banco de economia atualizado pode criar estado divergente. Alinhe backup de banco e arquivos, e documente qual conjunto pertence à mesma janela de recuperação.

Verifique também tarefas agendadas que escrevem no diretório durante a manutenção, como sincronização de arquivos, rotinas de backup e publicação de mapas. Suspenda o que pode reintroduzir uma versão antiga ou copiar configurações para a instância errada. Depois da atualização, reative uma rotina de cada vez e confira seus logs.

Confira a experiência do cliente

Uma atualização pode aceitar o jogador e ainda alterar comandos ou comportamentos visíveis. Teste versão do cliente aceita, mensagens, resource pack, teleporte, placares e permissões com uma conta sem privilégios. Depois percorra um mundo existente e execute ações que salvam dados, como abrir inventário e usar mecanismos essenciais; uma tela de login bem-sucedida não exercita essas rotas.

Se o servidor aceita clientes de versões variadas por meio de plugins de protocolo, confira a matriz suportada desses plugins e a ordem de atualização exigida pelos autores. Mantenha uma conta de equipe disponível para manutenção e teste também o caminho de entrada usado por jogadores Bedrock, se a rede oferecer cross-play.

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.