De onde vem o crescimento do disco de um servidor VPN e como limitá-lo

O túnel deixa de aceitar ligações, o serviço reinicia duas vezes e depois não aparece nada no seu registo. Esse silêncio é a pista, porque foi o registo que encheu o disco e o daemon não tem onde escrever o erro que está à espera. Qualquer serviço de longa duração pode chegar a esse estado, e apagar um diretório chamado logs raramente o resolve. A solução duradoura é saber qual armazenamento cresceu, quem detém a sua política de retenção e se o escritor libertou realmente o espaço.

Encontre o armazenamento que cresceu e a taxa a que cresceu

Comece por dois números fáceis de esquecer: blocos livres e inodes livres. Um sistema de ficheiros pode relatar muito espaço e ainda assim recusar uma escrita por não ter inodes, o que acontece quando um serviço cria um ficheiro por sessão. Peça ambas as leituras no mesmo volume, porque as respostas podem discordar na mesma tarde. Faça-o enquanto o anfitrião está saudável, para que os números descrevam o funcionamento normal e não uma falha.

df -h /var
df -i /var

Depois atribua o crescimento a um proprietário. O valor de utilização do próprio journal abrange apenas o journal e nunca verá um daemon a escrever num caminho do seu ficheiro de configuração.

journalctl --disk-usage

O crescimento ao longo do tempo diz mais do que qualquer leitura isolada. Um nível de depuração deixado ligado, um ciclo de novas tentativas que registra cada tentativa ou um ficheiro de captura que ninguém parou: cada um pode parecer normal num momento e alarmante uma hora depois. Faça uma leitura, espere por um período movimentado, faça outra e divida pelo intervalo. Uma taxa que consegue enunciar transforma a capacidade numa decisão em vez de um incêndio.

O que a rotação faz a um ficheiro aberto

Um ficheiro de registo é um nome que aponta para um inode, e o espaço só regressa quando o último descritor aberto é fechado. Renomeie o ficheiro e o escritor continua a encher o mesmo inode; apague-o e o escritor continua a encher um inode sem qualquer nome. Esse estado é a razão pela qual «apaguei o ficheiro e o disco ficou cheio» descreve descritores de ficheiro e não um sistema de ficheiros avariado. Reiniciar o escritor, ou escolher um modo de rotação que reabra o ficheiro, é o que realmente devolve os blocos.

lsof +L1 | head

A política pertence ao componente que escreve o ficheiro. O journal impõe os seus próprios limites de armazenamento a partir do seu ficheiro de configuração, enquanto um serviço baseado em ficheiros normalmente depende do logrotate, com uma regra de criação e um sinal de reabertura ou com um modo de truncagem no local quando o escritor não consegue reabrir. Confirme a decisão sem alterar nada primeiro:

logrotate -d /etc/logrotate.conf

Onde pertence o limite e quão grande deve ser

Coloque o limite onde o escritor está configurado, não no ponto de montagem. Uma quota sobre todo o volume protege o anfitrião mas não diz qual serviço falha primeiro, e um script de limpeza global tende a apagar as provas de que o próximo incidente precisará. Um limite do journal, um número de rotações com um tamanho máximo e a retenção da aplicação limitam cada um um produtor. Juntos limitam o total; separadamente, cada um é uma suposição.

Dimensione esse limite a partir da retenção que consegue defender, não do espaço livre disponível. Se uma revisão precisa de uma semana de tentativas de ligação, o journal tem de guardar uma semana à taxa mais alta esperada, e essa taxa é o número medido antes.

O registo de depuração é um modo temporário com uma hora de início registada, não um plano de armazenamento. Mantenha a questão da privacidade dentro da mesma decisão, porque os registos de ligações transportam endereços e identificadores. Uma retenção mais longa é também uma escolha de tratamento de dados e deve ser tomada por alguém que conheça ambas as restrições.

Verifique o limite após um reinício

Uma alteração de retenção que dura até ao próximo reinício não é uma alteração. Reinicie o escritor, confirme que o novo limite se aplica e verifique que a rotação continua a funcionar depois. Para o journal, um reinício e uma leitura de utilização respondem às duas perguntas:

systemctl restart systemd-journald
journalctl --disk-usage

Num serviço baseado em ficheiros, execute a tarefa de rotação uma vez à mão e confirme que o ficheiro foi substituído e o descritor reaberto. Um escritor que mantém o descritor antigo passa numa verificação superficial e falha na vez seguinte em que o volume enche. Vigie o espaço livre durante o teste, porque um ficheiro que encolheu enquanto o espaço não voltava significa que o inode antigo continua retido.

Compare a próxima leitura com esta

Volte ao fim de uma semana e compare a taxa de crescimento com a registada. Uma taxa coincidente significa que o limite se mantém e a carga é estável; uma taxa duplicada significa que algo mudou, e a pergunta útil é o quê. Leia primeiro o conteúdo do registo à procura de falhas repetidas, porque um ciclo de novas tentativas é sintoma e causa de volume ao mesmo tempo. Depois verifique se algo foi ativado recentemente, incluindo níveis de depuração ligados durante um incidente e nunca desligados.

Mantenha as cópias de segurança fora do mesmo volume, ou aceite que um disco cheio leva a cópia consigo. Uma cópia escrita no anfitrião que protege não é um plano de recuperação, e a sua retenção precisa da sua própria resposta.

Anote o que é retido, onde, durante quanto tempo e quem o remove. Essa frase é o resultado, e é a única parte deste trabalho que sobrevive ao próximo reinício.