Una de las alertas más comunes para un administrador Linux, SysAdmin, DevOps o Production Support es:

Filesystem space usage critical: 95%

Cuando esto sucede en producción, la primera pregunta es:

¿Qué está consumiendo todo el espacio en disco?

Linux proporciona herramientas como df, du, find, sort y lsof que permiten identificar rápidamente dónde se está utilizando el espacio.

En esta guía veremos un procedimiento práctico para investigar un filesystem lleno y localizar los archivos y directorios responsables.

---

Escenario: recibimos una alerta de espacio

Supongamos que nuestro sistema de monitoreo genera la siguiente alerta:

CRITICAL ALERT

Filesystem: /var
Usage: 95%
Available: 2.1 GB
Host: linux-prod-01

El objetivo será identificar qué está consumiendo /var.

Nuestro flujo de troubleshooting será:

ALERTA
  │
  ▼
df -h
  │
  ▼
Identificar filesystem
  │
  ▼
du
  │
  ▼
Identificar directorio
  │
  ▼
find
  │
  ▼
Identificar archivos grandes
  │
  ▼
lsof
  │
  ▼
Buscar archivos eliminados pero abiertos
  │
  ▼
Tomar acción

---

Paso 1: revisar el espacio con df

Nuestro primer comando será:

df -h

Ejemplo:

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-root     20G   11G  9.0G  56% /
/dev/mapper/rootvg-var      50G   47G  3.0G  94% /var
/dev/mapper/rootvg-home     20G  8.0G   12G  40% /home

Podemos ver inmediatamente el problema:

/var → 94%

La opción:

-h

significa human-readable, por lo que muestra tamaños como:

KB
MB
GB
TB

en lugar de solamente bytes.

---

Paso 2: revisar únicamente el filesystem afectado

Si la alerta corresponde a /var, podemos ejecutar:

df -h /var

Por ejemplo:

Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-var    50G   47G  3.0G  94% /var

También es útil revisar los inodos:

df -i /var

¿Por qué?

Porque un filesystem puede quedarse sin capacidad por dos razones diferentes:

Problema 1
──────────
Espacio en disco agotado

df -h


Problema 2
──────────
Inodos agotados

df -i

Un servidor con millones de archivos pequeños puede quedarse sin inodos aunque todavía tenga espacio disponible.

---

Paso 3: identificar qué directorio consume el espacio

Ahora sabemos que /var está lleno.

Necesitamos descubrir qué directorio dentro de /var es responsable.

Podemos ejecutar:

du -xsh /var/* 2>/dev/null

Ejemplo:

120M    /var/cache
850M    /var/lib
42G     /var/log
25M     /var/tmp

Aquí tenemos un sospechoso claro:

/var/log → 42 GB

Las opciones utilizadas son:

du
│
├── -x → permanecer en el mismo filesystem
├── -s → mostrar solamente el total
└── -h → human-readable

El uso de:

2>/dev/null

oculta mensajes de error relacionados, por ejemplo, con permisos insuficientes.

---

Paso 4: ordenar los directorios por tamaño

Podemos mejorar el comando anterior:

du -xsh /var/* 2>/dev/null | sort -h

Esto ordenará los resultados.

Si queremos ver primero los directorios más grandes:

du -xsh /var/* 2>/dev/null | sort -hr

Resultado:

42G     /var/log
850M    /var/lib
120M    /var/cache
25M     /var/tmp

Ahora sabemos exactamente dónde continuar.

---

Paso 5: profundizar en el directorio problemático

Podemos repetir el procedimiento:

du -xsh /var/log/* 2>/dev/null | sort -hr

Por ejemplo:

35G     /var/log/myapplication
3.2G    /var/log/messages
1.5G    /var/log/audit
900M    /var/log/httpd

Nuestro siguiente sospechoso es:

/var/log/myapplication

Continuamos:

du -xsh /var/log/myapplication/* 2>/dev/null | sort -hr

Esta técnica permite avanzar progresivamente:

/var
 │
 └── log
      │
      └── myapplication
            │
            └── logs

hasta encontrar dónde está concentrado el espacio.

---

Paso 6: encontrar los archivos más grandes

Una vez identificado el directorio, podemos utilizar find.

Por ejemplo:

find /var/log/myapplication -xdev -type f -printf '%s %p\n' 2>/dev/null \
| sort -nr \
| head -20

Esto devuelve los 20 archivos más grandes.

Sin embargo, los tamaños aparecerán en bytes.

Podemos hacerlos más legibles utilizando:

find /var/log/myapplication -xdev -type f -printf '%s %p\n' 2>/dev/null \
| sort -nr \
| head -20 \
| numfmt --field=1 --to=iec

Ejemplo:

18G /var/log/myapplication/server.log
9.2G /var/log/myapplication/debug.log
4.5G /var/log/myapplication/access.log
2.1G /var/log/myapplication/error.log

Ahora el problema es evidente.

---

Paso 7: buscar archivos mayores a cierto tamaño

También podemos pedirle a find que busque archivos superiores a un tamaño determinado.

Por ejemplo, archivos mayores a 1 GB:

find /var -xdev -type f -size +1G -print

Archivos mayores a 500 MB:

find /var -xdev -type f -size +500M -print

Archivos mayores a 100 MB:

find /var -xdev -type f -size +100M -print

Esto es extremadamente útil durante una emergencia.

---

Paso 8: encontrar los 20 archivos más grandes del filesystem

Podemos hacerlo directamente:

find /var -xdev -type f -printf '%s %p\n' 2>/dev/null \
| sort -nr \
| head -20 \
| numfmt --field=1 --to=iec

Conceptualmente:

find
 │
 │ encuentra archivos
 ▼
sort -nr
 │
 │ ordena por tamaño
 ▼
head -20
 │
 │ toma los primeros 20
 ▼
numfmt
 │
 │ convierte bytes
 ▼
RESULTADO

Este es uno de los comandos más útiles de toda la investigación.

---

Paso 9: buscar archivos grandes modificados recientemente

Supongamos que ayer /var estaba al 60% y hoy está al 95%.

Entonces probablemente existe algún archivo que creció recientemente.

Podemos buscar archivos mayores a 500 MB modificados durante las últimas 24 horas:

find /var -xdev -type f -size +500M -mtime -1 -ls 2>/dev/null

Para los últimos dos días:

find /var -xdev -type f -size +500M -mtime -2 -ls 2>/dev/null

Esto puede ayudar a descubrir rápidamente:

• Logs creciendo.
• Dumps.
• Backups.
• Archivos temporales.
• Exportaciones.
• Core dumps.
• Archivos generados por aplicaciones.

---

Paso 10: buscar archivos eliminados que continúan abiertos

Este es uno de los problemas más interesantes en Linux.

Supongamos que ejecutamos:

du -xsh /var

y obtenemos:

25G

pero:

df -h /var

muestra:

47G utilizados

¿Por qué existe una diferencia tan grande?

Una posible explicación son archivos eliminados que todavía permanecen abiertos por algún proceso.

En Linux, eliminar un archivo no necesariamente libera inmediatamente el espacio si un proceso todavía mantiene abierto su file descriptor.

Podemos investigar con:

lsof +L1

O filtrar por filesystem:

lsof +L1 | grep '/var'

También es común utilizar:

lsof | grep deleted

Ejemplo:

java  18452 appuser  15w REG  253,2 21474836480 /var/log/app/server.log (deleted)

Aquí tenemos un proceso Java:

PID = 18452

que mantiene abierto un archivo eliminado de aproximadamente:

20 GB

Este espacio puede continuar contabilizándose en df aunque el archivo ya no aparezca normalmente en el directorio.

---

¿Por qué ocurre esto?

Imaginemos:

Aplicación
    │
    ▼
server.log
    │
    │ 20 GB
    ▼
Filesystem

Alguien ejecuta:

rm server.log

Pero la aplicación continúa manteniendo abierto el archivo:

Aplicación
    │
    ▼
server.log (deleted)
    │
    │ todavía abierto
    ▼
Filesystem

El archivo desapareció del directorio, pero el espacio puede continuar ocupado hasta que el proceso cierre el descriptor.

Por eso:

df -h

y:

du

pueden mostrar resultados diferentes.

---

IMPORTANTE: no reinicies ni mates procesos sin investigar

Si encontramos:

java 18452

no debemos ejecutar inmediatamente:

kill -9 18452

En producción, esto podría provocar una interrupción del servicio.

Primero debemos determinar:

• Qué aplicación utiliza el proceso.
• Si pertenece a producción.
• Qué servicio depende de él.
• Si existe redundancia.
• Si puede reiniciarse de forma segura.
• Si requiere aprobación.
• Si existe un procedimiento operativo.

---

Paso 11: revisar archivos de logs

Los logs son una causa muy frecuente de problemas de espacio.

Podemos buscar archivos .log grandes:

find /var -xdev -type f -name "*.log" -size +500M -ls 2>/dev/null

También podemos revisar:

du -xsh /var/log/* 2>/dev/null | sort -hr

Si un log está creciendo continuamente debemos investigar por qué está creciendo, no solamente eliminarlo.

Las posibles causas incluyen:

Debug habilitado
        │
        ▼
Demasiados mensajes
        │
        ▼
Log crece rápidamente
        │
        ▼
Filesystem lleno

La solución real podría ser:

• Corregir el error de aplicación.
• Reducir el nivel de logging.
• Configurar rotación.
• Ajustar retención.
• Comprimir logs antiguos.

---

Paso 12: revisar Logrotate

En muchas distribuciones Linux encontramos configuraciones en:

/etc/logrotate.conf

y:

/etc/logrotate.d/

Podemos revisar:

cat /etc/logrotate.conf

o:

ls -l /etc/logrotate.d/

Una mala configuración de rotación puede permitir que un archivo crezca indefinidamente.

---

Paso 13: buscar core dumps

Los core dumps también pueden ocupar enormes cantidades de espacio.

Podemos buscarlos:

find / -xdev -type f -name "core*" -size +100M -ls 2>/dev/null

Dependiendo de la configuración del servidor, también puede ser necesario revisar:

coredumpctl list

En servidores de aplicaciones, un dump puede tener varios gigabytes.

---

Paso 14: buscar archivos antiguos

En algunos casos el filesystem contiene información que nunca fue eliminada.

Por ejemplo, archivos con más de 90 días:

find /var/log -xdev -type f -mtime +90 -ls 2>/dev/null

Podemos combinar edad y tamaño:

find /var/log -xdev -type f -mtime +90 -size +100M -ls 2>/dev/null

Esto identifica archivos:

más antiguos de 90 días
            +
mayores de 100 MB

Pero identificarlos no significa que podamos eliminarlos automáticamente.

---

Paso 15: liberar espacio de forma segura

Una vez encontrado el problema, debemos decidir qué acción realizar.

Algunas posibilidades son:

• Comprimir logs antiguos.
• Eliminar archivos temporales aprobados.
• Mover archivos a otro filesystem.
• Corregir una aplicación que genera demasiados logs.
• Configurar logrotate.
• Reducir políticas de retención.
• Limpiar dumps antiguos.
• Extender el filesystem si el crecimiento es legítimo.

Antes de eliminar cualquier archivo debemos saber:

qué aplicación lo utiliza y si existe alguna política de retención.

---

No hagas esto directamente en producción

Un comando como:

find /var/log -type f -mtime +30 -delete

puede parecer conveniente.

Pero puede ser extremadamente peligroso.

Podríamos eliminar:

• Logs necesarios para auditoría.
• Información requerida por seguridad.
• Evidencia para troubleshooting.
• Archivos requeridos por una aplicación.
• Información sujeta a políticas de retención.

Primero:

IDENTIFICAR
     ↓
ANALIZAR
     ↓
VALIDAR
     ↓
RESPALDAR si es necesario
     ↓
ELIMINAR

---

Procedimiento rápido para Production Support

Cuando llega una alerta de filesystem, podemos seguir esta secuencia.

1. Verificar filesystem

df -h

2. Verificar inodos

df -i

3. Identificar directorios grandes

du -xsh /var/* 2>/dev/null | sort -hr

4. Profundizar

du -xsh /var/log/* 2>/dev/null | sort -hr

5. Encontrar los 20 archivos más grandes

find /var -xdev -type f -printf '%s %p\n' 2>/dev/null \
| sort -nr \
| head -20 \
| numfmt --field=1 --to=iec

6. Buscar archivos grandes recientes

find /var -xdev -type f -size +500M -mtime -1 -ls 2>/dev/null

7. Buscar archivos eliminados pero abiertos

lsof +L1 | grep '/var'

8. Investigar antes de eliminar

¿Quién creó el archivo?
¿La aplicación todavía lo utiliza?
¿Existe política de retención?
¿Puede comprimirse?
¿Puede moverse?
¿Puede eliminarse?

---

Cheat Sheet: problemas de espacio en Linux

Objetivo	Comando
Ver filesystems	df -h
Revisar /var	df -h /var
Revisar inodos	df -i /var
Directorios más grandes	du -xsh /var/* | sort -hr
Archivos >1 GB	find /var -xdev -type f -size +1G
Archivos >500 MB	find /var -xdev -type f -size +500M
Archivos recientes grandes	find /var -xdev -type f -size +500M -mtime -1 -ls
Top 20 archivos	find /var -xdev -type f -printf '%s %p\n' | sort -nr | head -20
Archivos eliminados abiertos	lsof +L1
Logs grandes	find /var -xdev -type f -name "*.log" -size +500M
Archivos >90 días	find /var -xdev -type f -mtime +90

---

El comando que todo administrador Linux debería recordar

Si necesito investigar rápidamente un filesystem como /var, normalmente comenzaría con:

du -xsh /var/* 2>/dev/null | sort -hr

Después buscaría los archivos más grandes:

find /var -xdev -type f -printf '%s %p\n' 2>/dev/null \
| sort -nr \
| head -20 \
| numfmt --field=1 --to=iec

Y si los números de df y du no parecen coincidir:

lsof +L1

Esta combinación permite resolver una gran cantidad de incidentes relacionados con espacio.

---

Conclusión

Cuando recibimos una alerta indicando que un filesystem Linux está llegando al límite, el objetivo no debería ser simplemente eliminar archivos hasta que desaparezca la alerta.

El procedimiento correcto es encontrar la causa.

Un buen troubleshooting sigue una secuencia:

df
 ↓
¿Qué filesystem está lleno?

du
 ↓
¿Qué directorio consume el espacio?

find
 ↓
¿Qué archivos son responsables?

lsof
 ↓
¿Existen archivos eliminados pero abiertos?

ANÁLISIS
 ↓
¿Por qué crecieron?

ACCIÓN
 ↓
Eliminar / Comprimir / Rotar / Mover / Extender

PREVENCIÓN
 ↓
Evitar que vuelva a ocurrir

Comandos como df, du, find, sort, head, lsof y logrotate forman parte de las herramientas esenciales de cualquier administrador Linux.

La diferencia entre solucionar temporalmente una alerta y realizar un buen trabajo de Production Support está en una pregunta:

¿Liberamos espacio o encontramos la causa que estaba consumiendo el espacio?

En producción, casi siempre necesitamos hacer ambas cosas.