💾 Disco lleno: diagnosticar con df, du y journal

Un disco al 100% tumba bases de datos, logs y despliegues. El diagnóstico rápido evita borrar a ciegas.

Más allá del comando suelto, lo importante es el contexto: cuándo aplicarlo, cómo validar el resultado y qué efectos secundarios puede tener en producción.

A continuación verás el porqué, ejemplos concretos con explicación, un flujo paso a paso, errores típicos y buenas prácticas para usarlo con confianza.

💡 Orden de ataque

• Ver particiones llenas
• Encontrar directorios pesados
• Limpiar logs/rotados con criterio
• Tener un procedimiento repetible reduce el tiempo de incidente
• Documentar el enfoque ayuda al resto del equipo a operar igual de bien

🚀 Comandos y ejemplos

Uso por partición:

df -h

Adapta este ejemplo a tus paths y nombres reales antes de usarlo en producción.

Top directorios:

sudo du -xh /var --max-depth=2 | sort -h | tail

Adapta este ejemplo a tus paths y nombres reales antes de usarlo en producción.

Ficheros grandes:

sudo find /var -type f -size +200M -ls

Adapta este ejemplo a tus paths y nombres reales antes de usarlo en producción.

Inodos agotados:

df -i

A veces hay espacio en GB pero no en inodos (muchos ficheros pequeños).

Mayor peso bajo /var:

sudo du -xh /var/log /var/lib /var/cache --max-depth=1 | sort -h

Separa logs, datos de servicios y cachés antes de borrar.

🔧 Ejemplo práctico paso a paso

1. Mide GB e inodos

df -h
df -i

Decide la rama: sin espacio en bloques vs sin inodos.

2. Encuentra el mount y el directorio culpable

sudo du -xh /var --max-depth=2 | sort -h | tail

Ejemplo: /var/lib/docker o /var/log se comen el disco. No borres a ciegas en /var/lib/mysql.

3. Lista ficheros grandes o demasiados pequeños

Grandes: find /var -type f -size +500M -ls. Muchos pequeños: mira colas, spools, sesiones, caches de app.

4. Limpia con el procedimiento del servicio

Logs: journalctl –vacuum-size o rotación. Docker: prune consciente. Luego df -h otra vez y documenta qué liberó espacio.

⚠️ Errores frecuentes

Truncar el binario de la BD o el datadir. Liberar espacio borrando ficheros de PostgreSQL/MySQL es corrupción. Usa herramientas del motor o amplía disco.

Borrar logs abiertos a lo loco. Si un proceso mantiene el fichero abierto, df puede no liberar hasta reiniciar el servicio. Mejor rotación (logrotate) o truncate controlado + restart si aplica.

No configurar alerta al 80%. Llegar al 100% es el peor momento para aprender du. Alerta antes.

💡 Buenas prácticas

1. No borres directorios de bases de datos sin backup.
2. Revisa rotación de logs antes de truncar.
3. Deja margen (alerta al 80%, no al 100%).
4. Prefiere cambios reversibles y con rollback claro.
5. Corrrelaciona siempre con logs y, si puedes, con una métrica simple.
6. Si el procedimiento se repite, conviértelo en script versionado.

📝 Conclusión

df + du + find te dicen en minutos dónde se fue el espacio.

Si practicas este flujo con calma en staging, en producción te saldrá casi automático. Guarda tus variantes locales (paths, unidades, convenciones del equipo) junto a estos ejemplos.