Primero revisa el uso del disco del sistema:

df -h

Si / o /var está lleno, revisa el tamaño del directorio de Docker:

sudo du -h --max-depth=1 /var/lib/docker | sort -h

Los grandes consumidores habituales suelen incluir estos:

/var/lib/docker/overlay2
/var/lib/docker/containers
/var/lib/docker/volumes
/var/lib/docker/buildkit

Luego observa la distribución del espacio desde la propia perspectiva de Docker:

docker system df
docker system df -v

docker system df muestra por separado imágenes, contenedores, volúmenes locales y caché de compilación, lo cual es más seguro que mirar solo du. du te dice qué directorio es grande; los comandos de Docker te dicen a qué objetos pertenece ese espacio.

La documentación oficial de Docker también lo dice claramente: Docker adopta una estrategia conservadora con los objetos no utilizados; las imágenes, contenedores, redes y volúmenes no se limpian automáticamente por defecto a menos que ejecutes prune explícitamente.

Primero revisa los contenedores detenidos:

docker ps -a

Si hay muchos contenedores temporales ya salidos, puedes limpiar los contenedores detenidos:

docker container prune

Luego revisa las imágenes:

docker images

Limpia solo las imágenes colgantes:

docker image prune

Limpia las imágenes antiguas no usadas por ningún contenedor:

docker image prune -a

Si no estás seguro de si una imagen aún se necesita para revertir, no añadas -a todavía. En producción, image prune -a puede borrar imágenes que actualmente no están referenciadas por ningún contenedor pero que pensabas conservar para revertir.

En máquinas que ejecutan docker build con frecuencia en el VPS, la caché de compilación puede ser más grande que las propias imágenes. Revisa:

docker builder du

Limpia la caché de compilación:

docker builder prune

Si confirmas que no necesitas ninguna caché antigua, entonces considera:

docker builder prune -a

Un enfoque más seguro es añadir un filtro de tiempo, por ejemplo limpiar solo la caché de más de 7 días:

docker builder prune --filter "until=168h"

Esto es más adecuado para un VPS en producción que borrar todo sin pensar, porque reduce el impacto de volver a descargar y recompilar en la próxima compilación.

Mucha gente solo vigila overlay2, pero lo que realmente llena el disco son los logs de contenedores. El driver de logs json-file predeterminado de Docker escribe stdout y stderr en archivos. Si la aplicación no deja de imprimir logs de error y no hay rotación de logs, un solo log de contenedor puede crecer a varios GB.

Revisa el tamaño de los archivos de log de contenedores:

sudo du -h /var/lib/docker/containers/*/*-json.log | sort -h

Para detener la hemorragia temporalmente, primero localiza el contenedor anómalo:

docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}"
docker logs --tail=100 容器名

No abras logs json enormes directamente en un editor. Más importante aún, corrige el origen de los logs: ¿la aplicación está en bucle de errores, las comprobaciones de salud son demasiado frecuentes, el proxy inverso reintenta constantemente?

La solución a largo plazo es configurar la rotación de logs para Docker. Edita:

sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.json

Escribe o combina la siguiente configuración:

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

Luego reinicia Docker:

sudo systemctl restart docker

Nota: esta configuración normalmente solo afecta a los contenedores recién creados. Los contenedores existentes pueden necesitar ser recreados para usar las nuevas opciones de logging. Si usas Docker Compose, se recomienda ejecutar:

docker compose down
docker compose up -d

Siempre que hayas confirmado que el archivo compose y la configuración de volúmenes son correctos.

/var/lib/docker/volumes puede ser grande, pero a menudo almacena bases de datos, archivos subidos, configuración y datos de colas. Este directorio no se puede confundir con la caché de imágenes.

Primero revisa el uso de volúmenes:

docker system df -v

Lista los volúmenes:

docker volume ls

Si quieres determinar si un volumen sigue siendo usado por un contenedor:

docker ps -a --filter volume=卷名

Docker proporciona:

docker volume prune

Pero este comando elimina volúmenes no usados por contenedores. El problema es: durante algún mantenimiento con parada, el contenedor de base de datos puede no existir temporalmente, pero el volumen sigue siendo tu único dato. En producción, no ejecutes volume prune sin copia de seguridad y sin confirmar el propósito.

Un orden más seguro es:

1. Primero haz copia de seguridad de los volúmenes importantes;
2. Confirma que el proyecto compose está abandonado;
3. Confirma que el nombre del volumen no es una base de datos, almacenamiento de objetos o directorio de subidas;
4. Luego elimina el volumen especificado por nombre.

docker volume rm 卷名

docker system prune es un comando de limpieza rápida que limpia contenedores detenidos, redes no usadas, imágenes colgantes y caché de compilación. Por defecto no limpia volúmenes.

La versión relativamente segura:

docker system prune

Con filtro de tiempo:

docker system prune --filter "until=168h"

La versión de alto riesgo:

docker system prune -a --volumes

Este comando no es adecuado como "limpieza universal" en un tutorial para principiantes. -a amplía el alcance de la limpieza de imágenes, y --volumes incluye también los volúmenes no usados en la limpieza. Para un VPS que ejecuta WordPress, Nextcloud, Gitea o una base de datos, una vez que el juicio sobre el volumen es erróneo, lo que se limpia pueden ser datos de negocio.

No se recomienda. overlay2 es el directorio de almacenamiento del sistema de archivos overlay de Docker, no un directorio de caché normal. Que crezca suele ser solo un resultado; la causa puede ser:

• La capa de escritura del contenedor escribe archivos temporales continuamente;
• La aplicación escribe caché y archivos subidos dentro del contenedor en lugar de en un volumen;
• Las imágenes y contenedores antiguos no se han limpiado;
• La caché de compilación se acumula a largo plazo;
• Los logs no tienen rotación.

Primero encuentra los contenedores con capas de escritura anómalas:

docker ps -s

Si el SIZE de un contenedor es muy grande, su capa de escritura está creciendo. Las causas comunes son que la aplicación escribe caché, archivos subidos y archivos exportados dentro del contenedor. La solución no es borrar overlay2, sino montar los directorios persistentes en un volumen o directorio del host y ajustar la configuración de la aplicación.

Se recomienda manejarlo en este orden:

1. df -h para confirmar qué partición está llena;
2. sudo du -h --max-depth=1 /var/lib/docker | sort -h para encontrar los directorios grandes de Docker;
3. docker system df -v para determinar la proporción de imágenes, contenedores, volúmenes y caché de compilación;
4. Primero limpia contenedores detenidos e imágenes colgantes;
5. Luego limpia la caché de compilación;
6. Revisa los logs json-file y configura la rotación;
7. Solo entonces maneja los volúmenes;
8. No borres overlay2 directamente.

Si tu VPS solo tiene un disco de sistema de 20GB o 30GB, deberías hacer tres cosas antes de desplegar Docker:

• Configurar max-size y max-file para los logs de Docker;
• Poner bases de datos, directorios de subidas y datos de negocio en volúmenes con nombres claros o en un disco de datos separado;
• Ejecutar regularmente comandos que solo limpien caché antigua, por ejemplo:

docker system prune --filter "until=168h"
docker builder prune --filter "until=168h"

También mantén la monitorización:

df -h
docker system df

Si ya te has encontrado con el disco lleno, no reinicies un montón de servicios primero. Cuando el disco está al 100%, las bases de datos, los servicios de logs y los gestores de paquetes pueden fallar al escribir. Primero libera una pequeña cantidad de espacio seguro y luego corrige las causas raíz una por una.

Que Docker llene el disco en un VPS parece que overlay2 es demasiado grande, pero a menudo en realidad son imágenes antiguas, contenedores detenidos, caché de compilación, logs json-file y gestión de volúmenes mezclados. La forma realmente segura de manejarlo no es borrar el directorio de Docker, sino primero clasificar con docker system df -v y luego limpiar de menor a mayor riesgo.

Recuerda esta línea base: las imágenes y la caché se pueden volver a descargar, los contenedores detenidos normalmente se pueden limpiar, los logs se pueden rotar, pero los volúmenes pueden contener tus datos de negocio. Confirma antes de limpiar y, después de limpiar, añade rotación de logs y reglas de mantenimiento periódico, para que no te interrumpa el mismo problema otra vez en unas semanas.