¿Es seguro ejecutar 'docker system prune -a'?

Elimina contenedores detenidos, redes sin uso, caché de compilación y todas las imágenes que no usa ningún contenedor en marcha. Tus datos sobreviven mientras no añadas --volumes. Con ese flag también borra los volúmenes sin uso, y el volumen de un contenedor de base de datos detenido cuenta como sin uso. No lo pongas si no estás seguro.

Borré un log enorme pero df sigue mostrando el disco lleno. ¿Por qué?

Un proceso en ejecución todavía tiene el archivo abierto, así que el kernel no libera el espacio. Encuéntralo con 'lsof +L1' y reinicia ese servicio. La próxima vez vacía un log activo con 'truncate -s 0 archivo' en lugar de borrarlo.

¿Cuánto espacio libre conviene dejar?

Al menos un 10–15 %. Las bases de datos, las actualizaciones de paquetes y los pulls de Docker necesitan espacio temporal, y un disco al 100 % puede corromper una base de datos en plena escritura.

¿Puedo ampliar el disco sin reinstalar?

Sí. Pasar a un plan mayor amplía el disco en el sitio y conserva tus datos: Nano tiene 15 GB, Micro 25 GB, Small 35 GB y Medium 45 GB. El servidor se reinicia una vez.

¿Qué suele llenar un VPS pequeño?

Según nuestra experiencia: imágenes y caché de compilación de Docker, journals de systemd, logs de aplicaciones que nadie rota y dumps de bases de datos o archivos de copia olvidados en /root.

Cómo liberar espacio en disco en un VPS sin romper nada

¿Disco lleno en tu VPS? Encuentra qué ocupa espacio con du y ncdu y limpia la caché de apt, los journals, los restos de Docker y los logs sin perder datos.

«No space left on device» nunca aparece en buen momento. La base de datos deja de aceptar escrituras, apt no puede terminar una actualización y Docker se niega a descargar justo la imagen que necesitas ahora. La buena noticia: en un VPS pequeño el culpable casi siempre es uno de cinco, y puedes encontrarlo en dos minutos.

1. ¿Cómo de grave es?

df -h /
df -i /

La primera línea muestra el espacio usado. La segunda, los inodos: si llegan al 100 % mientras el espacio parece suficiente, tienes millones de archivos diminutos (sesiones, una cola de correo, un directorio de caché). Otro problema, mismo síntoma.

2. Encuentra lo que ocupa

Recorre el árbol desde la raíz y ordena por tamaño:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x se queda en un solo sistema de archivos y no se mete en /proc. Luego profundiza en lo que sea más grande. Para explorar de forma interactiva, ncdu es mucho más cómodo:

apt install -y ncdu
ncdu -x /

Flechas para moverte, d para borrar. Cuidado con esto último.

3. Las victorias rápidas

Esto es seguro en cualquier servidor Ubuntu o Debian:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove también elimina kernels antiguos. El journal de systemd es el que más sorprende: sin límite puede crecer hasta varios gigabytes. Para limitarlo de forma permanente, pon SystemMaxUse=200M en /etc/systemd/journald.conf y ejecuta systemctl restart systemd-journald.

4. Restos de Docker

Si usas Docker, mira aquí primero. Las imágenes viejas y la caché de compilación se acumulan con cada despliegue:

docker system df
docker image prune -a
docker builder prune

docker image prune -a borra las imágenes que no usa ningún contenedor en marcha. Suele ser lo que quieres, aunque el próximo despliegue las descargará de nuevo.

El peligroso es docker system prune -a --volumes. Los volúmenes guardan tus datos, y un volumen de un contenedor detenido cuenta como sin uso. Así se pierden bases de datos. No lo copies de una respuesta de un foro.

Los logs de los contenedores son el otro devorador oculto. Limítalos en /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Reinicia Docker después. El límite solo se aplica a los contenedores creados a partir de ese momento, así que recrea los más ruidosos con docker compose up -d --force-recreate.

5. Logs y archivos olvidados

Busca archivos grandes en todo el disco:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Los hallazgos típicos: un backup.tar.gz de hace seis meses en /root, un dump de base de datos que alguien pensaba descargar, un log de aplicación que nunca rota.

A un log en el que un servicio sigue escribiendo no le hagas rm: vacíalo.

truncate -s 0 /var/log/myapp/app.log

Si ya lo borraste y el espacio no volvió, un proceso lo mantiene abierto:

lsof +L1

Reinicia el servicio que aparece ahí y el espacio regresa.

Cuando limpiar no basta

A veces los datos son simplemente reales: una base de datos que crece, subidas de usuarios, un archivo de modelo. Entonces la solución honesta es más disco. Cambiar de plan amplía el disco en el sitio y lo conserva todo: Nano tiene 15 GB, Micro 25 GB, Small 35 GB y Medium 45 GB. El servidor se reinicia una vez. Los detalles están en la documentación de planes.

Otra cosa ocupa espacio en silencio: un archivo de swap. Si seguiste nuestra guía de swap, esos 1–2 GB están ahí a propósito. Y si Docker es el principal consumidor, la instalación de Docker y el despliegue de un stack de Compose muestran cómo mantener las imágenes bajo control.

El hábito que evita todo esto: limita el journal y los logs de Docker el primer día. Dos líneas de configuración y el «disco lleno» casi deja de pasar.