Disco al 100% en produccion: diagnostico, limpieza y prevencion sin reiniciar

Introducción

Un servidor en producción no te avisa cuando se queda sin disco. Te lo hace saber cuando los servicios empiezan a caer, los logs dejan de escribirse y el df -h devuelve una línea roja que no esperabas. Hoy te muestro cómo se sale de un colapso real hasta el 100% en el disco principal sin reiniciar, sin espacio libre incremental y sin perder datos.

Lo Hecho

Intento de limpieza estándar: Se intentó borrar con sudo rm -r -f, pero la limpieza masiva falló de entrada por la excesiva cantidad de archivos implicados. No proseguí por esa vía y cambié de estrategia.

Diagnóstico de almacenamiento: Corrí df -h y confirmé el colapso total del disco principal. Confirmó el colapso real y descartó falsos positivos.

Estrategia de evasión de límites: Para no quedar trabado por ARG_MAX, pasé a find con -delete, que elimina archivo a archivo sin depender de expansiones del shell ni de memoria intermedia.

Auditoría de espacio: Usé una búsqueda de solo lectura para localizar lo que estaba consumiendo más espacio sin escribir nada nuevo en disco.

La Solución

Dos comandos operativos permiten descomprimir la situación sin pedir disco extra:

sudo find /var/log/tomcat9/ -type f -name "*.log" -delete

sudo find / -type f -size +1G -exec ls -lh {} + 2>/dev/null

Con eso se liberan logs masivos y se localizan otros archivos grandes en una sola pasada.

Consideraciones

• No borres ciegamente: cuando identifiques archivos pesados, eliminá solo temporales, *core dumps* o registros (.log, .gz). Nunca toques directorios del sistema ni bases de datos activas.
• Espacio e inodos: df -h muestra capacidad; df -i muestra inodos. Un disco puede estar al límite por cualquiera de los dos motivos, así que revisá ambos antes de limpiar.
• Prevención: configurá logrotate para evitar que los logs crezcan sin control y que este incidente se repita.

Conclusión

Un disco al 100% no se arregla con limpieza agresiva. Se arregla con diagnóstico de solo lectura, borrado selectivo y una política de rotación que controle el crecimiento de registros. Esa combinación es lo que mantiene el servidor en pie sin reinicios ni riesgos innecesarios.