CoreProtect registra ações para que uma equipe consiga investigar mudanças e, quando necessário, reverter algumas delas. Esse histórico ocupa armazenamento e cresce com a atividade do servidor. Definir retenção é um equilíbrio: manter tudo indefinidamente custa espaço e manutenção; apagar cedo demais reduz a evidência e as opções de recuperação.
Antes de alterar qualquer purga, confira a configuração e documentação da versão instalada. O CoreProtect pode usar diferentes bancos e tem opções de purga automática. A limpeza do histórico não é backup do mundo nem substitui plano de recuperação.
Defina para que o histórico será usado
Comece pela política operacional: quanto tempo sua equipe costuma levar para receber uma denúncia? A comunidade pode precisar investigar semanas depois, enquanto alguns projetos menores revisam incidentes em poucos dias. Considere também obrigações internas, regras de privacidade e os dados que o plugin registra conforme configuração.
Inclua na decisão quem pode consultar o histórico, que tipos de mudança são úteis e como incidentes pendentes serão preservados. Se há denúncias em aberto, uma retenção automática pode remover justamente as ações necessárias. Estabeleça um processo para sinalizar um caso antes da data de expiração.
Descubra tipo e tamanho do banco atual
Leia o config.yml do CoreProtect e registre o tipo de banco, versão do plugin e opções de armazenamento. Instalações novas e atualizações podem ter defaults diferentes; banco antigo pode continuar no formato SQLite ou MySQL mesmo depois de atualizar a ferramenta. A documentação atual descreve DuckDB como default em novas instalações recentes, mas isso não migra automaticamente dados antigos.
Não altere database-type esperando que os dados migrem. Selecionar outro backend escolhe outro conjunto de dados. Migração entre formatos exige procedimento próprio, cópia, destino vazio e validação. Confirme o tamanho ocupado pela base e o espaço disponível antes de iniciar qualquer operação.
Estime crescimento com dados reais
Compare o tamanho da base em datas conhecidas após períodos com atividade diferente. Um servidor com exploração, eventos e alta rotação de jogadores pode gerar logs em ritmos diversos. Use uma amostra de semanas comuns e de pico para estimar tendência, sem assumir que o banco cresce numa taxa fixa em todos os meses.
Considere outras necessidades de armazenamento também: mundos, backups, crash reports, logs de console e arquivos temporários de consulta. Limpar histórico pode não liberar o espaço que causa alerta se o mundo ou snapshots forem a maior parcela. Planeje monitoramento do volume e alerta antes de a hospedagem ficar sem disco.
Escolha uma janela de retenção
Use uma política simples e comunicável: por exemplo, manter um período operacional que cubra a revisão normal de denúncias, com uma rotina para preservar casos excepcionais. Não transforme um exemplo num valor universal. O prazo precisa fazer sentido para o calendário do servidor, capacidade de equipe, espaço e regras aplicáveis aos dados.
Escreva o que a retenção significa em linguagem clara para os moderadores. Defina quando uma investigação se torna exceção e quem pode autorizar preservar histórico adicional. Isso evita que um membro faça uma purga no meio de uma denúncia e que outro mantenha dados sem prazo definido.
Entenda purga automática e manual
A purga automática pode remover registros antigos de forma recorrente conforme configuração. Leia a unidade e o modo aceito na sua versão. Uma purga manual pode ser útil para manutenção pontual, mas exige filtros e conferência cuidadosos. Antes de ativar rotina, teste em uma cópia ou consulte documentação sobre o comportamento do banco usado.
Programe uma janela quando o servidor e o banco estiverem em operação estável. Monitore CPU, I/O, memória e espaço temporário conforme o backend; algumas estratégias apagam em lotes e podem competir com outras tarefas. Não inicie purga, rollback e migração simultaneamente. A documentação da migração indica condições de parada e lock que precisam ser respeitadas.
Faça backup antes de limpar
Tenha backup consistente da base e do arquivo de configuração. Pare o servidor quando o método de cópia exigir exclusividade; para serviço externo, siga a estratégia de snapshot e consistência do banco. Verifique se a cópia pode ser restaurada e se inclui o prefixo de tabelas quando aplicável.
Confirme a base selecionada e o ambiente. Um comando no servidor de homologação não deve apontar para histórico de produção, e vice-versa. Registre dataset, hora, tipo de backend e operador que autorizou. A purga remove histórico; o backup é a proteção para recuperação, sujeito à própria política de retenção.
Execute com controles e verifique
Revise os argumentos do comando e os limites antes de confirmar. Se a ferramenta oferece etapa de consulta, use-a para estimar o período que será afetado. Não compartilhe prints contendo dados pessoais de jogadores em canal público. Inicie a operação e acompanhe logs até concluir, sem reiniciar o plugin a meio do processo.
Depois, compare logs e espaço antes e depois. Uma purga nem sempre encolhe imediatamente o arquivo físico: o mecanismo pode liberar espaço interno para reutilização sem reduzir o tamanho visível do arquivo. Confirme contagem ou consulta de registros e monitore o serviço. Não conclua que falhou apenas porque o tamanho no explorador não mudou.
Proteja a investigação e a equipe
Conceda permissões de consulta, rollback e administração separadamente quando possível. Uma pessoa que precisa investigar não necessariamente precisa poder apagar histórico. Use contas individuais e registre o responsável por mudanças de política. Restrinja acesso às cópias, pois o histórico pode revelar padrões de atividade dos jogadores.
Revise permissões depois de mudanças na equipe e remova privilégios temporários. Mantenha um canal controlado para preservar dados associados a incidentes. Quando a retenção encerrar, descarte cópias temporárias segundo o procedimento, em vez de criar arquivos indefinidos sem dono.
Separe retenção de migração de banco
Se o volume pede um backend diferente, trate como projeto separado da purga. Confirme compatibilidade de versão, suporte do build, requisitos do destino, prefixo e compatibilidade da migração. Não altere o tipo esperando que CoreProtect copie os dados automaticamente. Faça a manutenção numa janela quieta, pare outras operações e valide histórico no destino.
Use a referência oficial de configuração CoreProtect, incluindo tipos de banco e arquivos por mundo. Confira a página de purga automática e o guia de comandos da versão atual antes de executar qualquer limpeza. Registre prazo, teste e resultado para a equipe saber exatamente que histórico permanece disponível.
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.