De onde vén o crecemento do disco dun servidor VPN e como limitar

O túnel deixa de aceptar conexións, o servizo reiníciase dúas veces e despois non aparece nada no seu rexistro. Ese silencio é a pista, porque o rexistro é o que encheu o disco e o demo non ten onde escribir o erro que agarda. Calquera servizo de longa duración pode chegar a ese estado, e borrar un directorio chamado logs raramente o arranxa. A solución duradeira é saber que almacén medrou, quen é o dono da súa retención e se o escritor realmente liberou o espazo.

Atope o almacén que medrou e a taxa á que medrou

Comece por dúas cifras fáciles de esquecer: bloques libres e inodes libres. Un sistema de ficheiros pode informar de moito espazo e aínda así rexeitar unha escritura porque non lle quedan inodes, o que ocorre cando un servizo crea un ficheiro por sesión. Pida ambas lecturas no mesmo volume, porque as respostas poden discordar a mesma tarde. Fágao mentres o host está san, para que as cifras describan o funcionamento normal e non unha caída.

df -h /var
df -i /var

Despois atribúa o crecemento a un propietario. A cifra de uso do propio journal só cobre o journal, e nunca verá un demo que escribe nunha ruta do seu ficheiro de configuración.

journalctl --disk-usage

O crecemento ao longo do tempo di máis que calquera lectura única. Un nivel de depuración que quedou activado, un bucle de reintentos que rexistra cada intento ou un ficheiro de captura que ninguén detivo: cada un pode parecer normal nun momento e alarmante unha hora despois. Tome unha lectura, espere un período de moita actividade, tome outra e divida polo intervalo. Unha taxa que pode enunciar converte a capacidade nunha decisión en lugar dun incendio.

Que fai a rotación cun ficheiro aberto

Un ficheiro de rexistro é un nome que apunta a un inode, e o espazo só volve cando se pecha o último descritor aberto. Renomee o ficheiro e o escritor segue enchendo o mesmo inode; bórreo e o escritor segue enchendo un inode sen ningún nome. Ese estado é a razón de que «borrei o ficheiro e o disco seguiu cheo» describa descritores de ficheiro e non un sistema de ficheiros roto. Reiniciar o escritor, ou escoller un modo de rotación que volva abrir o ficheiro, é o que realmente devolve os bloques.

lsof +L1 | head

A política pertence ao compoñente que escribe o ficheiro. O journal impón os seus propios límites de almacenamento desde o seu ficheiro de configuración, mentres que un servizo baseado en ficheiros adoita apoiarse en logrotate, xa sexa cunha regra de creación e un sinal de reapertura ou cun modo de truncamento no lugar cando o escritor non pode reabrir. Confirme a decisión sen cambiar nada primeiro:

logrotate -d /etc/logrotate.conf

Onde corresponde o límite e que tamaño debería ter

Pon o límite onde está configurado o escritor, non no punto de montaxe. Unha cota sobre todo o volume protexe o host pero non di que servizo falla primeiro, e un script de limpeza global tende a borrar as probas que necesitará o seguinte incidente. Un límite do journal, un número de rotacións cun tamaño máximo e a retención da aplicación acoutan cada un a un produtor. Xuntos acoutan o total; por separado, cada un é unha conxectura.

Dimensione ese límite a partir da retención que pode defender, non do espazo libre dispoñible. Se unha revisión necesita unha semana de intentos de conexión, o journal ten que gardar unha semana á taxa máis alta esperada, e esa taxa é a cifra medida antes.

O rexistro de depuración é un modo temporal cunha hora de inicio rexistrada, non un plan de almacenamento. Manteña a cuestión de privacidade dentro da mesma decisión, porque os rexistros de conexión levan enderezos e identificadores. Unha retención máis longa tamén é unha elección de tratamento de datos e debería tomala alguén que coñeza as dúas restricións.

Verifique o límite tras un reinicio

Un cambio de retención que dura ata o próximo reinicio non é un cambio. Reinicie o escritor, confirme que se aplica o novo límite e comprobe que a rotación segue funcionando despois. Para o journal, un reinicio e unha lectura de uso responden ás dúas preguntas:

systemctl restart systemd-journald
journalctl --disk-usage

Nun servizo baseado en ficheiros, execute a tarefa de rotación unha vez a man e confirme que o ficheiro se substituíu e o descritor se reabriu. Un escritor que conserva o descritor antigo pasa unha comprobación superficial e falla a próxima vez que o volume se enche. Vixie o espazo libre durante a proba, porque un ficheiro que se reduciu mentres o espazo non volvía significa que o inode antigo segue retido.

Compare a próxima lectura con esta

Volva ao cabo dunha semana e compare a taxa de crecemento coa rexistrada. Unha taxa coincidente significa que o límite aguanta e a carga é estable; unha taxa duplicada significa que algo cambiou, e a pregunta útil é que. Lea primeiro o contido do rexistro na busca de fallos repetidos, porque un bucle de reintentos é á vez síntoma e causa de volume. Despois revise se hai algo habilitado de novo, incluídos niveis de depuración activados durante un incidente e nunca desactivados.

Manteña as copias de seguridade fóra do mesmo volume, ou acepte que un disco cheo se leve a copia con el. Unha copia escrita no host que protexe non é un plan de recuperación, e a súa retención necesita a súa propia resposta.

Anote que se retén, onde, durante canto tempo e quen o elimina. Ese enunciado é o entregable, e é a única parte deste traballo que sobrevive ao próximo reinicio.