VPS · Problemas

VPS sin espacio en disco: cómo diagnosticarlo y liberar espacio

Si tu VPS se quedó sin espacio, primero mide con df y du qué lo ocupa, y después borra solo lo que se regenera solo: la caché de apt y de npm, los registros del sistema, las versiones viejas de herramientas y las compilaciones antiguas. Nunca toques bases de datos ni copias de seguridad. Lo sabemos de primera mano: el 23 de octubre de 2026 el disco de nuestro servidor llegó al 99 % y varias webs estuvieron unas 17 horas sin responder.

Actualizado el 2026-11-10 · Por Rómulo Felizola · Read in English

Paso 1: confirma que es el disco (y no los inodos)

df -h /
df -i /

df -h muestra el espacio y df -i los inodos (el número de archivos). Un servidor puede estar «lleno» con espacio libre si se agotan los inodos, y la solución es distinta: millones de archivos pequeños, normalmente cachés o sesiones.

Paso 2: encuentra qué ocupa el espacio

du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20
find / -xdev -type f -size +500M 2>/dev/null

El primer comando lista las carpetas más grandes y el segundo, los archivos de más de 500 MB. Baja un nivel cada vez hasta dar con el culpable.

Paso 3: borra lo que se regenera solo

apt-get clean
journalctl --vacuum-size=100M --vacuum-time=30d
npm cache clean --force
docker system df   # solo si usas Docker

Esto es lo que encontramos nosotros el 23 de octubre, y se liberaron unos 23 GB: la caché de npm (unos 8 GB), instaladores y versiones antiguas de los ejecutores de GitHub Actions (una copia por proyecto, diez en total), servidores viejos de VS Code, navegadores antiguos de Playwright, fotos originales ya publicadas y copias de seguridad viejas. El disco bajó del 99 % al 52 %.

La regla: borra solo lo que sabes que se vuelve a generar. Si dudas de una carpeta, no la borres: renómbrala, espera un día y comprueba que todo funciona.

Paso 4: que no vuelva a pasar

Un script de limpieza semanal con un temporizador de systemd. El nuestro corre los domingos y se limita a lo que se regenera solo: caché de apt, registros del sistema, instaladores de los ejecutores y versiones antiguas de herramientas.
Una vigilancia cada 15 minutos que lanza esa limpieza si el disco pasa del 85 %. Nos habría ahorrado la caída de 17 horas.
Registros con tamaño máximo (journalctl --vacuum-size) y rotación de los registros de nginx.
Copias de seguridad fuera del servidor: una copia en el mismo disco ocupa el mismo espacio que quieres liberar.

Cuándo toca cambiar de plan

Si después de limpiar lo que queda son datos tuyos (bases de datos, archivos subidos, fotos), no es un problema de limpieza sino de tamaño. Nuestro disco era de unos 50 GB y, tras limpiar, subimos al KVM 2, que tiene 100 GB. Según Hostinger, los planes existentes se mejoran desde la cuenta con el botón «Mejorar». Antes de decidir mira qué plan KVM elegir.

El plan al que subimos nosotros (100 GB):VPS KVM 2 en Hostinger

Preguntas frecuentes

¿Es seguro borrar los registros de /var/log?

Los registros antiguos sí, pero no borres la carpeta entera ni los archivos que un servicio tiene abiertos. Usa journalctl --vacuum-size para el sistema y logrotate para nginx.

¿Por qué mis webs dejan de funcionar cuando se llena el disco?

Porque las aplicaciones y las bases de datos necesitan escribir (sesiones, registros, archivos temporales). Sin espacio fallan las escrituras y suelen caerse; nginx puede responder con errores 5xx. Mira también el error 502 de nginx.

¿Cuánto espacio libre debo dejar?

Nuestra alarma salta al 85 %. Por debajo de un 15 % libre no tienes margen para una compilación grande ni para una actualización.