Llevo con el mismo servidor desde hace 5 años. Hace 2 lo trasladé de OVH a Hetzner, y aunque ahí ya tengo algo más de margen, sobrevivo con 80GB para no pagar un dineral cada mes. El problema es que, entre que voy metiendo proyectos y que ahora todo el mundo (yo incluido) anda metiendo IA en todos lados, se me ha vuelto imposible seguir escalando el servidor sin que el espacio se me cuadriplique de la nada.
Así que me puse a bucear por el sistema entero para ver de dónde podía sacar gigas sin tener que ampliar el plan. Os dejo aquí los sitios donde estuve mirando, por si os pasa lo mismo.
Yo estoy en Ubuntu Server, así que los comandos son para esa distro. Si tenéis otra, buscad el equivalente, que no todos los sistemas se comportan igual.
⚠️ Antes de nada, un disclaimer como una catedral: no copiéis comandos de internet (ni los míos) sin saber qué hacen. Leedlos, entendedlos, comprobad qué van a borrar exactamente, y sobre todo, haced siempre una copia de seguridad de todo antes de tocar nada. Un servidor no es un juguete, y un rm mal dado no avisa dos veces.
¿Qué cosas me han servido para liberar espacio?
Limpiar sitios web antiguos
Si tenéis un panel tipo CloudPanel o Plesk, lo primero y más tonto: id borrando proyectos que ya no usáis o que ni siquiera están conectados al público. Aunque no reciban tráfico, siguen ahí ocupando espacio, generando logs y acumulando backups por nada.
Si vuestro panel os deja ver el tamaño de cada sitio, genial, no tenéis ni que buscar. Pero si vais por acceso root y tenéis los sitios enjaulados, probablemente estén todos colgando de los directorios home. Así que esto os puede servir:
sudo du -sh /home/* | sort -hAquí du -sh calcula el tamaño de cada carpeta dentro de /home en formato legible (esas «h» de humano, vamos, para no tener que hacer la conversión de bytes a gigas a mano), y sort -h lo ordena de menor a mayor tamaño para que lo más gordo te aparezca al final, que es lo primero que quieres mirar.
Obviamente cambiad la ruta según dónde despliegue vuestro panel los sitios, que cada uno tiene sus manías.
Mismo truco, pero en la raíz del servidor
Con lo anterior detecté que los sitios web solo ocupaban la mitad de lo que el panel me decía que tenía ocupado. Así que, ¿dónde estaba la otra mitad? Pues nada, a mirar en la raíz directamente:
cd / && du -sh * | sort -hMismo comando de antes pero aplicado a toda la raíz del sistema, así que te devuelve una lista de todas las carpetas del nivel más alto ordenadas por tamaño. Aquí ya empiezas a ver carpetas de sistema o cosas que tenías instaladas y ni te acordabas.
Si queréis algo más agresivo, un top 20 de las carpetas y archivos más pesados de todo el servidor:
sudo du -ahx / | sort -rh | head -n 20Ojo con este último, que te puede repetir la misma carpeta un par de veces si tiene subcarpetas igual de gordas, así que no os fieis a ciegas del resultado sin mirar un poco el contexto. Pueden quedarse fuera carpetas que ocupen más.
La carpeta /var/log/
Los logs se pueden volver locos en según qué fechas. Un fallo puntual, un ataque, o simplemente mucho tráfico, y de repente tienes gigas de logs de la nada. Lo bueno es que la mayoría se autolimpian solos (algunos a la semana, otros al mes), pero siempre hay alguno que se queda ahí acumulando polvo sin que nadie lo borre.
Antes de tocar nada, haz copias de seguridad de los logs por si luego necesitáis revisar algo importante.
Yo me encontré con la carpeta /var/log/journal/ bastante crecida. Esa carpeta contiene los registros del sistema que gestiona systemd-journald, y por defecto Ubuntu (y otras distros) los guarda de forma indefinida, así que si nadie los limita, pueden llegar a comerse varios gigas tranquilamente.
Se puede limpiar de forma totalmente segura con journalctl, de dos maneras:
- Limpiar por tamaño (la que yo recomendaría): deja solo los registros más recientes hasta llegar al tamaño que le digas, por ejemplo 200MB:
sudo journalctl --vacuum-size=200M- Limpiar por tiempo: borra todo lo que sea más antiguo del periodo que marques, por ejemplo 2 semanas:
sudo journalctl --vacuum-time=2weeksDocker y sus movidas (en mi caso, carpeta /var/lib/docker/)
Tengo un proyecto montado en Docker que en su día me pareció más cómodo y que, con el tiempo, me ha dado más dolores de cabeza que otra cosa. Algún día lo migro, porque entre lo que me cuesta montar o ajustar cosas dentro de Docker y lo poco que me aporta para una mini app, cada vez tengo más ganas de quitármelo de encima. Pero eso, con calma, que no es tarea de un rato.
Mientras tanto, me encontré con que /var/lib/docker/ me estaba ocupando 20GB. Y sí, es totalmente normal que crezca tanto: Docker va acumulando imágenes antiguas, contenedores parados, volúmenes huérfanos y redes que ya no usa nadie, y todo eso se queda ahí ocupando sitio en el disco aunque no lo veas.
La buena noticia es que Docker trae su propio comando mágico para limpiar todo eso de un tirón:
docker system prune -a --volumes¿Qué hace exactamente?
- Borra todos los contenedores parados.
- Borra todas las redes que no esté usando ningún contenedor.
- Con
-aborra también todas las imágenes que no tengan un contenedor activo asociado (no solo las colgadas o «dangling», sino todas). - Con
--volumesborra los volúmenes que ya no estén vinculados a ningún contenedor actual.
⚠️ Este último punto es el que más cuidado hay que tener: si guardáis bases de datos en volúmenes sin un contenedor asociado en marcha, esto os las borra sin preguntar. Aseguraos de tener encendido todo lo que os importe antes de lanzarlo.
A mí, a pesar de hacer limpiezas de build cada vez que actualizo la app, este comando me liberó casi 9GB de un plumazo.
No os olvidéis de vuestros WordPress que siguen funcionando
Aquí hay varios sitios donde meter la nariz:
- Copias de seguridad locales de plugins: UpdraftPlus, All-in-One WP Migration, Duplicator… todos ellos suelen guardar los backups dentro de la propia carpeta del sitio (por ejemplo
/home/tusitio/htdocs/tusitio/wp-content/ai1wm-backups/). Si no los vais borrando, se acumulan sin límite. - Imágenes duplicadas en Medios / Media Library: WordPress genera entre 5 y 10 tamaños distintos por cada imagen que subís, más si hacéis muchas cosas. Echad un ojo a
wp-content/uploads/, que ahí se nota más de lo que parece. - Plugins de caché: WP Rocket, LiteSpeed Cache, W3 Total Cache… guardan páginas estáticas para servir rápido. Si hay un error o un pico de tráfico raro, esa carpeta de caché puede acabar pesando gigas sin que os deis cuenta.
Bases de datos (MySQL/MariaDB)
Con varios sitios corriendo, las bases de datos también crecen solas por cosas que no se ven a simple vista:
- Revisiones de entradas: cada vez que guardáis un borrador en WordPress, se crea una fila nueva en la base de datos. Multiplicadlo por todos los posts que tengáis y por todas las veces que le dais a guardar.
- Tablas huérfanas: si desinstaláis un plugin, su tabla en la base de datos normalmente se queda ahí para siempre, nadie la borra por vosotros.
- La tabla
action_scheduler: las acciones marcadas como completadas se van limpiando solas, pero las que fallan (failed), no. Le echaría un vistazo al tamaño de esta tabla, porque he visto sitios con bastante tráfico donde ocupaba casi 3GB ella solita.
Las carpetas node_modules de vuestros proyectos
No es buena idea dejarlas por ahí sueltas. Puede que seáis unos cracks y las tengáis bien alejadas de cualquier acceso, pero también puede que alguien listo os haga un path traversal, se las encuentre, y ese sea vuestro fallo.
Además de lo de seguridad, están el tema del espacio: si tenéis copias de seguridad de vuestras apps de Node, o versiones antiguas que ya no usáis, cada carpeta node_modules puede pesar tranquilamente entre 300MB y 4GB solo por la cantidad de dependencias pequeñitas que arrastra. Y más si empezáis a instalar cosas por instalar.
Y así gané 12 GB
Al final, entre logs, Docker, backups de plugins y bases de datos con basura acumulada, me salió bastante más espacio del que esperaba, sin tener que ampliar ni un GB del plan. Si os animáis a hacer limpieza, espero que consigáis limpiar sin cargaros la casa. ¡Ánimo!