Un lunes a la mañana abrís la web de tu negocio y aparece un error. Probás con el correo y tampoco funciona. Entrás a tu VPS y, al intentar subir un archivo, te dice que no hay espacio disponible. Si tu sitio en midominio.com.ar se comporta raro y todo apunta a un disco lleno, quedate tranquilo: es uno de los problemas más comunes en un servidor virtual y se resuelve en menos de una hora si sabés por dónde empezar.

En esta guía de nivel intermedio vas a aprender a encontrar qué está ocupando el espacio, a liberarlo sin borrar nada importante y a dejar armado un sistema para que no vuelva a pasar. Solo necesitás acceso por SSH y ganas de seguir los pasos con calma.

Por qué se llena el disco de un VPS

A diferencia de un hosting compartido, en un VPS vos administrás el sistema completo, y eso incluye la limpieza. Con el tiempo se van acumulando cosas sin que nadie las note. Las causas más frecuentes son:

• Logs que nunca se rotan: los registros de Apache, Nginx, PHP y el sistema crecen todos los días.
• Copias de seguridad viejas: ese respaldo «por las dudas» que hiciste hace ocho meses sigue ahí.
• Paquetes y actualizaciones descargadas: el gestor de paquetes guarda copias que ya no sirven.
• Archivos temporales y cachés: sesiones, miniaturas y datos de aplicaciones.
• Uploads y bases de datos: lo normal de un negocio que crece; acá lo que corresponde es ampliar el plan.

Pensá en el disco como el depósito de un comercio de barrio en Argentina: si nadie ordena y descarta lo viejo, un día ya no entra mercadería nueva. La diferencia es que en el servidor el «depósito lleno» se nota como errores en la web y en el correo.

Paso 1: conectate por SSH y hacé un diagnóstico rápido

Abrí la terminal (en Windows podés usar PowerShell) y conectate con tu usuario y la IP de tu VPS:

ssh usuario@IP-de-tu-servidor

Una vez adentro, ejecutá este comando para ver cuánto espacio hay en cada partición:

df -h

Vas a ver una tabla. Fijate en la columna Use% de la línea que dice / (la partición principal). Si marca 90% o más, estás en zona de riesgo; si marca 100%, ya estás en el problema. Anotá el número: al final lo vas a comparar para confirmar cuánto espacio recuperaste.

Paso 2: encontrá qué carpetas pesan más

Ahora hay que descubrir quién se come el espacio. Este comando lista las carpetas principales ordenadas por tamaño:

sudo du -h –max-depth=1 / 2>/dev/null | sort -hr | head -15

Puede tardar un minuto. El resultado te muestra las quince carpetas más pesadas. Lo habitual es que las sospechosas sean /var (logs, cachés, bases de datos), /home (archivos de tus sitios y respaldos) o /usr (programas instalados).

Elegí la más grande y repetí el comando apuntando a ella. Por ejemplo, si /var es la culpable:

sudo du -h –max-depth=1 /var | sort -hr | head -10

Seguí «bajando» de carpeta en carpeta hasta encontrar el archivo o directorio concreto que ocupa muchos gigas. Es como seguir un rastro: en dos o tres saltos casi siempre aparece el responsable.

Paso 3: domá los logs

Si el rastro te llevó a /var/log, encontraste al sospechoso número uno. Mirá cuáles son los archivos más grandes:

sudo ls -lhS /var/log | head -10

Para el registro del sistema (journal) podés limitar su tamaño de forma segura:

sudo journalctl –vacuum-size=200M

Esto conserva los últimos 200 MB de registros y borra lo anterior. Para un log de aplicación que ya no necesitás, no lo elimines con rm mientras el servicio lo está usando; vaciarlo es más seguro:

sudo truncate -s 0 /var/log/nombre-del-archivo.log

Así el archivo sigue existiendo (el servicio no se confunde) pero queda en cero bytes. Guardate una copia comprimida antes si creés que vas a necesitar revisar algo más adelante.

Paso 4: limpiá paquetes y descargas viejas

El gestor de paquetes acumula instaladores. En sistemas Debian y Ubuntu, corré estos dos comandos:

1. sudo apt clean elimina los paquetes descargados que ya no hacen falta.
2. sudo apt autoremove quita dependencias que quedaron huérfanas.

En sistemas de la familia AlmaLinux o Rocky el equivalente es sudo dnf clean all. Además, si usás Ubuntu, revisá los kernels antiguos: autoremove suele encargarse, pero confirmá que no queden versiones viejas ocupando cientos de megas.

Paso 5: revisá respaldos y archivos que quedaron olvidados

Acá es donde mucha gente recupera varios gigas de golpe. Buscá archivos grandes en todo el sistema con este comando:

sudo find / -type f -size +500M 2>/dev/null

Te lista todo lo que pese más de 500 MB. Fijate especialmente en archivos con extensión .zip, .tar.gz, .sql o .bak: casi siempre son copias antiguas. Antes de borrar, hacete tres preguntas:

• ¿Sé qué es este archivo y quién lo creó?
• ¿Existe una copia más reciente y confiable en otro lugar?
• ¿Lo puedo descargar a mi computadora antes de eliminarlo?

Si las tres respuestas son afirmativas, descargalo a tu equipo o a un almacenamiento externo y recién ahí borralo del servidor. Un respaldo que vive en el mismo disco que la web no te protege demasiado, así que mudarlo afuera es una mejora en sí misma.

Paso 6: revisá los «inodos», el problema invisible

A veces df -h te muestra espacio libre pero igual el servidor dice «no space left on device». Eso pasa cuando se agotan los inodos, que son los «casilleros» que el sistema usa para registrar cada archivo. Miles y miles de archivos diminutos (sesiones, cachés, correos en cola) pueden llenarlos. Comprobalo con:

df -i

Si la columna IUse% está cerca del 100%, buscá la carpeta con más archivos:

sudo find /var -xdev -type f | cut -d/ -f2-3 | sort | uniq -c | sort -nr | head

Las carpetas de sesiones de PHP o de caché de una aplicación suelen ser las responsables. Vaciar los archivos temporales viejos de esa carpeta resuelve el problema.

Paso 7: verificá que todo funcione

Volvé a ejecutar df -h y compará con el número que anotaste al principio. Lo ideal es dejar el disco por debajo del 80% de uso, con margen para crecer. Después reiniciá los servicios que pudieron quedar trabados por la falta de espacio:

sudo systemctl restart apache2 (o nginx, según lo que uses) y sudo systemctl restart mysql.

Entrá a tu web en midominio.com.ar, mandá un correo de prueba y confirmá que el panel te deja subir archivos otra vez. Si algo sigue fallando, revisá el log de errores del servicio: ahora que hay espacio, va a registrar la causa real.

Paso 8: armá la prevención para no repetirlo

Resolver la urgencia está bien, pero lo profesional es que no vuelva a pasar. Tres hábitos alcanzan:

• Configurá logrotate: es la herramienta que comprime y descarta logs viejos automáticamente. Revisá los archivos dentro de /etc/logrotate.d/ y ajustá cuántas semanas guardar.
• Programá una revisión mensual: anotá en tu calendario ejecutar df -h el primer lunes de cada mes. Son treinta segundos.
• Mové los respaldos afuera: configurá que las copias se envíen a otro lugar y que solo se conserven las últimas cuatro o cinco.

Si además querés que el propio servidor te avise, un pequeño script con cron que envíe un correo cuando el uso supere el 85% te ahorra sorpresas. Es un buen proyecto para tu próxima tarde tranquila.

Errores comunes que conviene evitar

Cuando el disco está lleno y hay apuro, es fácil cometer errores. Evitá estos:

• Borrar carpetas del sistema porque «parecen grandes». Si no sabés para qué sirve, no la toques.
• Usar rm -rf sin verificar la ruta. Un espacio de más o un asterisco mal puesto puede borrar todo. Revisá el comando dos veces.
• Eliminar bases de datos directamente desde el sistema de archivos. Usá siempre el gestor de MySQL o MariaDB.
• Olvidarte de reiniciar los servicios después de liberar espacio.

Y una regla de oro: antes de cualquier limpieza grande, asegurate de tener un respaldo reciente y verificado de tus sitios y bases de datos.

¿Y si todo es contenido legítimo?

Puede pasar que hayas limpiado logs, cachés y respaldos y el disco siga casi lleno. En ese caso, no es un problema de orden sino de crecimiento: tu negocio tiene más fotos, más clientes y más datos, y eso es una gran noticia. La solución es ampliar el espacio de tu plan de VPS para acompañar ese crecimiento, en lugar de estar apagando incendios cada mes.

Un ejemplo para que veas cómo se lee el resultado

Supongamos que df -h te muestra la partición principal al 97%. Al correr du sobre la raíz, la carpeta /var pesa 38 GB de un total de 50 GB. Bajás un nivel y ves que /var/log ocupa 31 GB. Entrás ahí y descubrís un solo archivo de error de 29 GB. Con truncate lo vaciás, el uso baja al 38% y tu sitio vuelve a responder. Casi siempre la historia es así de concreta: un único culpable enorme escondido dos o tres carpetas más abajo.

Ese archivo no crecía porque sí: probablemente había un error repetido miles de veces por minuto. Una vez que hayas liberado espacio, mirá las últimas líneas del log antes de vaciarlo para entender qué lo generaba y corregirlo de raíz.

Conclusión

Un disco lleno asusta, pero ahora ya tenés el mapa completo: diagnosticar con df, rastrear con du, domar los logs, limpiar paquetes, revisar respaldos viejos, controlar los inodos y dejar la prevención lista. Con esta rutina tu VPS va a quedar ordenado, tu sitio en .com.ar va a seguir online y vos vas a dormir más tranquilo. Guardá esta guía, hacé la primera revisión hoy mismo y, si algo no te cierra, animate a consultarnos: para eso estamos.