Disco lleno en Ubuntu: diferencias entre df, du e inodos
Publicado el 2026-10-26 por frfrand
Diagnóstico de espacio y de archivos pequeños en un VPS Linux
El servidor dice «No space left on device» pero borraste un archivo grande y el error sigue. A veces faltan bytes; otras, inodos. df y du miran el almacenamiento desde puntos distintos y ayudan a entenderlo.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa df, du e inodos en la práctica
df -h informa uso de sistemas de archivos; du resume espacio ocupado por directorios; df -i revela uso de inodos, que pueden agotarse por muchísimos archivos pequeños. También puede haber archivos borrados que siguen abiertos por un proceso.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
df -h
df -i
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h
sudo lsof +L1 | head
journalctl --disk-usageLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Identifica exactamente qué sistema de archivos está lleno con
df -h. - Revisa inodos con
df -ipara detectar demasiados archivos pequeños. - Explora carpetas del mismo sistema de archivos con
du -xsin cruzar montajes. - Inspecciona logs, copias de seguridad antiguas y contenedores; no borres directorios del sistema a ciegas.
- Si borraste un archivo enorme y el espacio no vuelve, comprueba si algún proceso todavía lo mantiene abierto.
Después de cada paso, verifica un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encuentras un mensaje inesperado, guárdalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Un servicio de generación de facturas crea miles de PDF temporales y nunca los limpia. El disco se agota aunque PostgreSQL ocupa poco. La solución pasa por una política de retención y alertas, no solo por aumentar el volumen.
Al final, prueba el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
Nunca ejecutes comandos destructivos de limpieza copiados sin revisar las rutas. Borrar archivos internos de PostgreSQL o Docker directamente puede corromper datos.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
En ArduMaker monitorea el disco del VPS y separa directorios temporales, bases y respaldos. Un proceso sin límite de archivos puede afectar a todos los proyectos compartidos.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documenta primero el procedimiento manual y sus comprobaciones. Después considera un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sepas recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mira logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entienda el error, después cambie una cosa concreta y compruebe su efecto. Esa disciplina le ahorra muchas horas de soporte.