Espacio en disco: a dónde va
Cómo encontrar qué ha llenado el disco, por qué es peligroso un archivo eliminado pero abierto, qué es seguro limpiar y por qué el anillo de uso del panel puede mostrar algo incorrecto.
Actualizado 23 de agosto de 2026
Quedarte sin espacio es una caída que se disfraza de cualquier cosa: la base de datos no escribe, el sitio devuelve un error, los contenedores se reinician. El disco de un VDS va de 40 GB en el plan básico a 250 GB en el más alto, y casi siempre se llena con las mismas cosas.
Primeros comandos
df -h
df -i
sudo du -x -h -d1 / | sort -h | tail -15
No te saltes df -i: puede que tengas espacio, pero te quedes sin inodos — entonces verás “disco lleno” con gigabytes libres. El culpable suele ser millones de archivos pequeños de caché.
Después baja al directorio más grande:
sudo du -x -h -d1 /var | sort -h | tail
sudo du -x -h -d1 /var/lib | sort -h | tail
El flag -x mantiene el conteo dentro de un solo sistema de archivos y no se mete en directorios montados.
Causas habituales
| Qué | Cómo comprobarlo | Qué hacer |
|---|---|---|
| Logs de contenedores | du -sh /var/lib/docker/containers/*/*-json.log | Limita el tamaño, consulta logs |
| Imágenes y caché de compilación | docker system df | docker image prune, docker builder prune |
| Journal del sistema | journalctl --disk-usage | journalctl --vacuum-size=200M |
Kernels antiguos en /boot | df -h /boot | apt autoremove --purge |
| Caché de paquetes | du -sh /var/cache/apt | apt clean |
| Copias que se quedaron ahí | du -sh /backup | Muévelas fuera del servidor, consulta otra ubicación |
| Archivos subidos por usuarios | du -sh /var/www/uploads | Almacenamiento externo o un disco más grande |
Un archivo borrado que sigue ocupando espacio
Un rompecabezas clásico: du muestra 5 GB, df muestra 30 GB usados. Eso significa que el archivo se borró, pero un proceso todavía lo tiene abierto, y el espacio no se liberará hasta reiniciar.
sudo lsof +L1 | head -20
La salida mostrará procesos y tamaños. La solución es reiniciar al culpable:
sudo systemctl restart <service>
docker compose restart <service>
Nunca liberes espacio con
rmsobre un archivo de log que está en uso. Lo correcto es truncarlo:sudo truncate -s 0 /var/log/big.log. Si lo borras, el espacio seguirá ocupado y además perderás el log.
El anillo de uso en el panel
En la pestaña “Overview” hay un anillo de uso de disco. Se calcula a través del agente invitado qemu-guest-agent. Si el agente se elimina o no está en ejecución, los datos no se actualizarán — el panel mostrará el comando de instalación. Para comprobarlo dentro de la máquina:
systemctl status qemu-guest-agent
Las lecturas del agente y df -h deberían coincidir. Una discrepancia suele significar que parte del espacio lo ocupa una partición montada por separado — consulta particiones y sistemas de archivos.
Prevención
Configura una tarea programada con limpieza y una alerta:
#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
journalctl --vacuum-size=200M
apt clean
docker image prune -f
echo "Disk is ${USED}% full" | mail -s "VDS: low disk space" you@example.com
fi
Un umbral del 85% te da margen para reaccionar. No puedes esperar al 100%: cuando el disco está lleno, algunos servicios ni siquiera podrán escribir un log sobre lo que pasó.
Si no queda nada de espacio
- Libera un par de gigabytes con medidas rápidas:
journalctl --vacuum-size=100M,apt clean,docker builder prune -f. - Encuentra la causa real con los comandos de arriba — si no, todo se repetirá en una semana.
- Si los datos de verdad han crecido, necesitas ampliar el disco pasando a un plan superior. Reducir no está disponible: el disco no se puede encoger.