De dónde viene el crecimiento del disco de un servidor VPN y cómo limitarlo

El túnel deja de aceptar conexiones, el servicio se reinicia dos veces y después no aparece nada en su registro. Ese silencio es la pista, porque el registro es lo que llenó el disco y el demonio no tiene dónde escribir el error que espera. Cualquier servicio de larga duración puede llegar a ese estado, y borrar un directorio llamado logs rara vez lo arregla. La solución duradera es saber qué almacén creció, quién es dueño de su retención y si el escritor realmente liberó el espacio.

Encuentre el almacén que creció y la tasa a la que creció

Empiece por dos cifras fáciles de olvidar: bloques libres e inodos libres. Un sistema de archivos puede informar de mucho espacio y aun así rechazar una escritura porque no le quedan inodos, lo que ocurre cuando un servicio crea un archivo por sesión. Pida ambas lecturas en el mismo volumen, porque las respuestas pueden contradecirse la misma tarde. Hágalo mientras el host está sano, para que las cifras describan el funcionamiento normal y no una caída.

df -h /var
df -i /var

Después atribuya el crecimiento a un dueño. La cifra de uso del propio journal solo cubre el journal, y nunca verá a un demonio que escribe en una ruta de su archivo de configuración.

journalctl --disk-usage

El crecimiento a lo largo del tiempo dice más que cualquier lectura única. Un nivel de depuración que quedó activado, un bucle de reintentos que registra cada intento o un archivo de captura que nadie detuvo: cada uno puede parecer normal en un momento y alarmante una hora después. Tome una lectura, espere un periodo de mucha actividad, tome otra y divida por el intervalo. Una tasa que puede enunciar convierte la capacidad en una decisión en lugar de un incendio.

Qué hace la rotación con un archivo abierto

Un archivo de registro es un nombre que apunta a un inodo, y el espacio solo vuelve cuando se cierra el último descriptor abierto. Renombre el archivo y el escritor sigue llenando el mismo inodo; bórrelo y el escritor sigue llenando un inodo sin ningún nombre. Ese estado es la razón de que «borré el archivo y el disco siguió lleno» describa descriptores de archivo y no un sistema de archivos roto. Reiniciar al escritor, o elegir un modo de rotación que vuelva a abrir el archivo, es lo que realmente devuelve los bloques.

lsof +L1 | head

La política pertenece al componente que escribe el archivo. El journal impone sus propios límites de almacenamiento desde su archivo de configuración, mientras que un servicio basado en archivos suele apoyarse en logrotate, ya sea con una regla de creación y una señal de reapertura o con un modo de truncado en el lugar cuando el escritor no puede reabrir. Confirme la decisión sin cambiar nada primero:

logrotate -d /etc/logrotate.conf

Dónde corresponde el límite y qué tamaño debería tener

Ponga el límite donde está configurado el escritor, no en el punto de montaje. Una cuota sobre todo el volumen protege al host pero no dice qué servicio falla primero, y un script de limpieza global tiende a borrar las pruebas que necesitará el siguiente incidente. Un límite del journal, un número de rotaciones con un tamaño máximo y la retención de la aplicación acotan cada uno a un productor. Juntos acotan el total; por separado, cada uno es una conjetura.

Dimensione ese límite a partir de la retención que puede defender, no del espacio libre disponible. Si una revisión necesita una semana de intentos de conexión, el journal tiene que guardar una semana a la tasa más alta esperada, y esa tasa es la cifra medida antes.

El registro de depuración es un modo temporal con una hora de inicio registrada, no un plan de almacenamiento. Mantenga la cuestión de privacidad dentro de la misma decisión, porque los registros de conexión llevan direcciones e identificadores. Una retención más larga también es una elección de tratamiento de datos y debería tomarla alguien que conozca ambas restricciones.

Verifique el límite tras un reinicio

Un cambio de retención que dura hasta el próximo reinicio no es un cambio. Reinicie al escritor, confirme que se aplica el nuevo límite y compruebe que la rotación sigue funcionando después. Para el journal, un reinicio y una lectura de uso responden a ambas preguntas:

systemctl restart systemd-journald
journalctl --disk-usage

En un servicio basado en archivos, ejecute la tarea de rotación una vez a mano y confirme que el archivo se reemplazó y el descriptor se reabrió. Un escritor que conserva el descriptor antiguo pasa una comprobación superficial y falla la próxima vez que el volumen se llena. Vigile el espacio libre durante la prueba, porque un archivo que se redujo mientras el espacio no volvía significa que el inodo antiguo sigue retenido.

Compare la próxima lectura con esta

Vuelva al cabo de una semana y compare la tasa de crecimiento con la registrada. Una tasa coincidente significa que el límite aguanta y la carga es estable; una tasa duplicada significa que algo cambió, y la pregunta útil es qué. Lea primero el contenido del registro en busca de fallos repetidos, porque un bucle de reintentos es a la vez síntoma y causa de volumen. Después revise si hay algo habilitado de nuevo, incluidos niveles de depuración activados durante un incidente y nunca desactivados.

Mantenga las copias de seguridad fuera del mismo volumen, o acepte que un disco lleno se lleve la copia con él. Una copia escrita en el host que protege no es un plan de recuperación, y su retención necesita su propia respuesta.

Anote qué se retiene, dónde, durante cuánto tiempo y quién lo elimina. Esa frase es el entregable, y es la única parte de este trabajo que sobrevive al próximo reinicio.