El disco que se llena solo: caches, imágenes y logs
Un servidor que funcionaba se queda sin espacio y todo empieza a fallar a la vez, de formas que no parecen relacionadas. Qué ocupa el disco en un servidor con muchos contenedores y cómo se mantiene solo.
El disco lleno es una de las fallas más desagradables porque no se presenta como tal: la base deja de aceptar escrituras, una aplicación devuelve errores raros, un despliegue falla creando el contenedor, los registros se cortan. Cuatro síntomas distintos, una sola causa.
Y en un servidor con muchos contenedores, el espacio desaparece sin que nadie guarde nada.
Quién se come el disco
| Qué | Por qué crece | Cuánto puede llegar a ser |
|---|---|---|
| Imágenes viejas | Cada reconstrucción deja la anterior sin etiqueta | Decenas de gigabytes en pocos meses |
| Caché de construcción | Guarda capas intermedias de cada build | Más que las imágenes mismas |
| Registros de contenedores | Sin límite configurado, crecen para siempre | Un servicio verboso llena un disco solo |
| Volúmenes huérfanos | Quedan cuando un servicio cambia de nombre | Todo lo que tenía la base anterior |
| Caché de gestores de paquetes y directorios temporales | Cada instalación y cada proceso deja restos | Varios gigabytes acumulados |
Hay un detalle que confunde al diagnosticar: borrar un archivo que un proceso todavía tiene abierto no libera el espacio hasta que ese proceso lo cierre. El tamaño del directorio baja y el disco sigue igual de lleno.
Poner límites en vez de limpiar a mano
Lo que se configura una vez
- Rotación de registros por contenedor: tamaño máximo y cantidad de archivos. Es la medida que más espacio ahorra y la que más se olvida.
- Techo para la caché de construcción, para que se mantenga sola en vez de crecer sin fin.
- Rotación de los registros del sistema y de las aplicaciones, con retención acotada.
- Limpieza periódica de imágenes sin etiqueta, contenedores detenidos y volúmenes sin uso, con una tarea programada y no a mano.
Avisar con margen
La diferencia entre un mantenimiento tranquilo y un incidente es cuándo llega el aviso.
Antes de seguir, predecí
Además del porcentaje conviene mirar la tendencia: un crecimiento sostenido indica algo que se está acumulando, y es mejor encontrarlo por la pendiente que por el umbral.
Cuando ya pasó
El orden para recuperar espacio rápido
- Ver qué partición se llenó. No siempre es la raíz: puede ser la de datos o la de registros.
- Ubicar los directorios más grandes, de arriba hacia abajo, en vez de adivinar.
- Empezar por lo seguro: caché de construcción e imágenes sin etiqueta. No tocan datos.
- Después, registros viejos, comprobando que el proceso los haya soltado.
- Al final, y con cuidado, volúmenes, sólo después de confirmar a qué servicio pertenecen.
Más a fondo · nivel seniorLos inodos también se acaban
Un caso que desconcierta: el disco muestra espacio libre y el sistema dice que no puede crear archivos. Es que se agotaron los inodos, por millones de archivos diminutos —cachés de paquetes, sesiones, directorios temporales—. Se diagnostica con la vista de inodos del comando de espacio, y se resuelve borrando cantidad de archivos, no tamaño. Si no se sabe que existe, se pierden horas buscando espacio que sí hay.
Encontrarlo en el log
Buscá en el log
Un despliegue falló de madrugada y el disco decía 94 % ocupado, no 100 %. ¿Qué línea explica por qué falló igual?
debug 2info 5warn 3error 212 de 12
Lo que se llenó no fueron los bloques sino los inodos, y ésa es la razón por la que el porcentaje de espacio no servía para diagnosticar. Miles de archivos chiquitos —capas de imágenes viejas y archivos de registro rotados— agotan la tabla de inodos con el disco todavía a 94 %. Por eso el error es «no queda espacio» y df dice que sí queda: hay que mirar df -i, no df -h.
Que no vuelva a pasar
Cierre
Autoevaluación
¿Lo entendiste?
Práctica