Cómo controlar el crecimiento del espacio en disco de un servidor Linux

Introducción

Controlar el crecimiento del espacio en disco de un servidor Linux no consiste en esperar a que aparezca una alerta crítica y borrar archivos deprisa. Consiste en conocer qué sistemas de archivos existen, cuánto crece cada uno, qué directorios explican ese crecimiento, qué margen operativo necesita cada servicio y cuánto tiempo queda antes de alcanzar un límite peligroso.

Un disco lleno puede provocar consecuencias mucho más graves que la imposibilidad de guardar un archivo. Una base de datos puede detener escrituras, un servicio puede dejar de arrancar, una aplicación puede perder sesiones, los logs pueden dejar de registrar incidencias, una actualización puede quedar incompleta y una copia de seguridad puede fallar precisamente cuando más se necesita.

El problema suele desarrollarse de forma gradual. Los registros aumentan cada día, las copias locales se acumulan, una base de datos conserva históricos, los contenedores generan capas, una aplicación sube documentos y los paquetes antiguos permanecen en caché. Mientras todavía queda espacio, la infraestructura parece estable. Cuando se supera el umbral, la incidencia parece repentina, aunque llevaba semanas anunciándose.

Este artículo presenta un método práctico para profesionales, autónomos, microempresas y PYMES que administran servidores Linux propios, VPS, aplicaciones web, WordPress, bases de datos o plataformas LMS. El objetivo es convertir el almacenamiento en una capacidad medible y planificable, evitando tanto el llenado inesperado como el sobredimensionamiento sin datos.

Índice

• Por qué un disco lleno puede detener un servidor
• Diferencia entre capacidad, rendimiento e integridad
• Crear un mapa de almacenamiento del servidor
• Medir el uso de los sistemas de archivos con df
• Comprobar el consumo de inodos
• Localizar qué directorios ocupan espacio con du
• Encontrar archivos grandes sin recorrer a ciegas
• Medir crecimiento y construir una línea base
• Calcular cuánto tiempo queda hasta el umbral
• Definir umbrales operativos útiles
• Controlar el crecimiento de logs y journal
• Detectar archivos borrados que siguen ocupando espacio
• Vigilar el crecimiento de bases de datos
• Controlar Docker, contenedores e imágenes
• Evitar que las copias locales llenen producción
• Gestionar temporales, cachés y paquetes
• Asignar el crecimiento a usuarios y aplicaciones
• Automatizar mediciones y alertas
• Cómo actuar cuando el espacio entra en zona crítica
• Decidir entre limpiar, archivar, optimizar o ampliar
• Aplicación en un servidor con WordPress o LMS
• Plan de implantación paso a paso
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Por qué un disco lleno puede detener un servidor

El almacenamiento no es un recurso pasivo. Los servicios escriben continuamente datos, índices, archivos temporales, sockets, sesiones, cachés y registros. Cuando desaparece el margen, el comportamiento del sistema puede degradarse de formas distintas.

Fallos de escritura

Las aplicaciones pueden recibir errores al guardar archivos, actualizar configuraciones o escribir datos. El usuario final puede ver mensajes genéricos mientras la causa real es la falta de espacio.

Bases de datos detenidas o inconsistentes

Una base de datos necesita espacio para tablas, índices, archivos temporales, logs de transacciones y operaciones de mantenimiento. Trabajar cerca del límite reduce su capacidad de recuperarse y aumenta el riesgo de interrupción.

Actualizaciones incompletas

La instalación de paquetes puede necesitar descargar archivos, desempaquetarlos y conservar temporalmente versiones anteriores. Un sistema sin margen puede quedar a medio actualizar.

Pérdida de observabilidad

Si los logs ya no pueden escribirse, la incidencia elimina parte de la evidencia necesaria para diagnosticarla.

Servicios que no reinician

Un proceso en ejecución puede continuar durante un tiempo, pero fallar al reiniciarse porque necesita crear archivos PID, sockets, temporales o datos de estado.

Copias de seguridad fallidas

Una copia local puede agotar el mismo disco que pretende proteger. También puede fallar por falta de espacio temporal durante compresión o empaquetado.

El objetivo no es mantener el disco por debajo de un porcentaje arbitrario, sino conservar el margen necesario para que cada servicio pueda escribir, actualizarse, recuperarse y crecer de forma previsible.

Diferencia entre capacidad, rendimiento e integridad

Controlar el espacio libre no sustituye otras revisiones del almacenamiento.

Un disco puede disponer de mucho espacio y responder lentamente. También puede rendir bien y estar próximo a fallar. Este artículo se centra en la capacidad y el crecimiento. La monitorización general puede complementarse con cómo monitorizar recursos del servidor sin complicarte.

Crear un mapa de almacenamiento del servidor

Antes de medir tendencias hay que saber qué se está midiendo. Un servidor puede utilizar varios discos, particiones, volúmenes lógicos, sistemas de archivos, montajes de red y almacenamiento asociado a contenedores.

Información mínima por sistema de archivos

• dispositivo o volumen;
• punto de montaje;
• tipo de sistema de archivos;
• capacidad total;
• uso actual;
• servicios que lo utilizan;
• datos principales;
• crecimiento esperado;
• umbral operativo;
• procedimiento de ampliación;
• responsable;
• copia y recuperación.

Comandos de reconocimiento

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
findmnt
sudo blkid
cat /etc/fstab

lsblk muestra la relación entre dispositivos, particiones y montajes. findmnt ayuda a identificar la procedencia y opciones de cada sistema de archivos. /etc/fstab muestra los montajes previstos al arrancar, aunque no necesariamente todos los montajes temporales o gestionados por otras herramientas.

No confundir disco físico con espacio disponible

Un disco físico puede contener varias particiones. Un volumen lógico puede abarcar más de un dispositivo. Un montaje de red puede consumir capacidad en otro servidor. La alerta debe asociarse al sistema de archivos que realmente soporta el dato.

La organización de aplicaciones y datos influye directamente en esta visibilidad. Una estructura bien separada facilita atribuir el crecimiento, como se desarrolla en cómo diseñar una estructura de directorios para aplicaciones empresariales.

Medir el uso de los sistemas de archivos con df

El comando básico para conocer capacidad utilizada y disponible es:

df -h

La opción -h muestra unidades legibles. Para incluir el tipo de sistema de archivos:

df -hT

Una revisión útil debe observar:

• el punto de montaje;
• el espacio total;
• el espacio utilizado;
• el espacio disponible;
• el porcentaje de ocupación;
• si el sistema de archivos esperado está realmente montado.

Excluir sistemas virtuales

En algunos entornos puede resultar más limpio limitar la salida a sistemas relevantes:

df -hT -x tmpfs -x devtmpfs -x squashfs

Medir un punto concreto

df -h /var/lib/mysql
df -h /srv/aplicaciones

El comando muestra el sistema de archivos que contiene la ruta, no el tamaño del directorio. Esta distinción es importante: df responde cuánto espacio queda en el volumen; du explica qué archivos visibles están ocupándolo.

Reservas del sistema de archivos

Algunos sistemas de archivos reservan una parte de la capacidad para administración o funcionamiento interno. Por eso la suma aparente de tamaños puede no coincidir exactamente con el total. No conviene modificar reservas sin comprender su finalidad y el tipo de volumen.

Comprobar el consumo de inodos

Un servidor puede quedarse sin capacidad para crear archivos aunque todavía muestre gigabytes libres. Ocurre cuando se agotan los inodos disponibles.

Para revisar su uso:

df -i

El problema suele aparecer cuando una aplicación crea enormes cantidades de archivos pequeños:

• sesiones;
• cachés;
• miniaturas;
• colas de correo;
• archivos temporales;
• logs fragmentados;
• objetos generados por una aplicación;
• directorios de dependencias o compilación.

Localizar directorios con muchos archivos

Una aproximación inicial puede realizarse contando entradas por directorio:

sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
| sort | uniq -c | sort -nr | head -30

Este comando puede consumir recursos en volúmenes grandes. Debe ejecutarse con criterio, preferiblemente fuera de periodos críticos y limitando el alcance al sistema de archivos sospechoso.

El control de capacidad debe incluir siempre dos preguntas: cuánto espacio queda y cuántos objetos nuevos puede crear todavía el sistema.

Localizar qué directorios ocupan espacio con du

du calcula el espacio utilizado por archivos y directorios visibles. Para revisar el primer nivel de un punto de montaje:

sudo du -xhd1 /var 2>/dev/null | sort -h

Las opciones significan:

• -x: no cruzar a otros sistemas de archivos;
• -h: mostrar tamaños legibles;
• -d1: limitar la profundidad a un nivel.

Después puede profundizarse únicamente en el directorio que explica el consumo:

sudo du -xhd1 /var/lib 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h
sudo du -xhd1 /srv 2>/dev/null | sort -h

Evitar recorrer todo el servidor como primera reacción

Ejecutar du desde / puede tardar, generar carga y mezclar montajes. Es más eficiente seguir un árbol de diagnóstico:

1. Identificar con df el sistema de archivos que crece.
2. Localizar su punto de montaje.
3. Analizar el primer nivel con du -xhd1.
4. Descender solo por la rama de mayor crecimiento.
5. Relacionar el directorio con el servicio responsable.

Tamaño aparente y espacio real

Los archivos dispersos, enlaces duros, compresión y características del sistema de archivos pueden producir diferencias entre tamaño aparente y bloques realmente utilizados. Para comparar:

du -sh directorio
du -sh --apparent-size directorio

Encontrar archivos grandes sin recorrer a ciegas

Cuando un directorio concentra el crecimiento, puede ser útil localizar archivos de gran tamaño.

sudo find /var -xdev -type f -size +1G \
-printf '%s %p\n' 2>/dev/null \
| sort -nr | head -30

Para mostrar tamaños más legibles puede utilizarse:

sudo find /var -xdev -type f -size +500M \
-exec du -h {} + 2>/dev/null \
| sort -h | tail -30

El archivo grande no siempre es el problema

Un archivo de base de datos, una imagen de máquina virtual o un volumen de contenedor puede ser grande por diseño. Borrarlo sin identificar su propietario puede destruir el servicio.

Antes de eliminar cualquier archivo hay que responder:

• ¿qué proceso lo utiliza?;
• ¿es dato, log, caché, copia o temporal?;
• ¿existe una política de retención?;
• ¿puede regenerarse?;
• ¿está incluido en una copia válida?;
• ¿debe archivarse en otra ubicación?;
• ¿la eliminación debe hacerse desde la aplicación?;

En servidores críticos, la limpieza debe ser una consecuencia del diagnóstico, no el método de diagnóstico.

Medir crecimiento y construir una línea base

Una fotografía aislada permite conocer el estado actual, pero no anticipa cuándo se alcanzará el límite. Para gestionar capacidad hay que conservar histórico.

Qué registrar

• fecha y hora;
• sistema de archivos;
• capacidad total;
• espacio utilizado;
• espacio disponible;
• porcentaje de ocupación;
• inodos utilizados;
• directorios principales;
• evento empresarial relevante;
• cambio técnico realizado.

Frecuencia

Un servidor estable puede registrar capacidad diariamente. Un sistema en crecimiento, durante una campaña o cerca de un umbral necesita mediciones más frecuentes. La frecuencia debe permitir detectar la aceleración antes de que desaparezca el margen de actuación.

Línea base por directorio

Además del total del volumen, conviene medir los directorios que representan funciones distintas:

• /var/lib/mysql o la ubicación de la base de datos;
• /var/log;
• /srv o datos de aplicaciones;
• subidas de usuarios;
• repositorios de contenidos;
• copias locales;
• almacenamiento de contenedores;
• correo o colas.

Registrar contexto

Una subida de 30 GB puede ser normal si coincide con la importación de contenidos de un curso. Sin contexto, la métrica no permite distinguir crecimiento legítimo de una fuga.

Calcular cuánto tiempo queda hasta el umbral

Una proyección sencilla puede expresarse así:

Tiempo hasta el umbral =
(espacio del umbral - espacio utilizado actual) / crecimiento por periodo

Ejemplo

Un volumen de 500 GB tiene un umbral operativo de 425 GB. Actualmente utiliza 350 GB y crece 15 GB al mes.

Margen hasta el umbral = 425 - 350 = 75 GB
Tiempo estimado = 75 / 15 = 5 meses

La intervención no debe planificarse para el quinto mes. Hay que restar el tiempo necesario para decidir, presupuestar, comprar, ampliar, migrar y comprobar.

Escenarios

No extrapolar una fuga como crecimiento normal

Si el consumo se acelera bruscamente, primero hay que identificar la causa. Comprar más disco puede ocultar temporalmente un error que seguirá creciendo.

La planificación general del almacenamiento se desarrolla en cómo dimensionar almacenamiento empresarial sin quedarse corto ni gastar de más. Aquí el foco está en medir la evolución real del servidor Linux.

Definir umbrales operativos útiles

No existe un porcentaje universal válido para todos los volúmenes. El umbral depende de la criticidad, la variabilidad, el tamaño absoluto, el tipo de dato y el tiempo necesario para ampliar.

Porcentaje y espacio absoluto

El 10 % libre en un volumen de 100 GB son 10 GB. En uno de 20 TB son 2 TB. Una alerta basada solo en porcentaje puede resultar demasiado tardía en el primer caso o demasiado temprana en el segundo.

Cuatro niveles prácticos

• Informativo: se registra una tendencia relevante.
• Planificación: debe decidirse limpieza, archivo o ampliación.
• Intervención: el margen puede agotarse antes de completar una actuación normal.
• Crítico: existe riesgo inmediato para escrituras, actualizaciones o recuperación.

Umbrales por tiempo restante

Una alerta que indica “quedan 45 días al ritmo actual” suele ser más útil para planificación que una alerta fija al 80 %. Puede combinarse:

• porcentaje utilizado;
• GB libres;
• crecimiento semanal;
• días hasta el umbral;
• cambio anormal respecto a la línea base;
• consumo de inodos.

Margen para operaciones extraordinarias

El umbral debe reservar espacio para actualizaciones, reconstrucción de índices, restauraciones, importaciones, compresión y tareas de mantenimiento. El volumen no debe considerarse disponible al cien por cien para datos ordinarios.

Controlar el crecimiento de logs y journal

Los registros son una causa frecuente de crecimiento inesperado, especialmente cuando un servicio entra en bucle y escribe miles de mensajes repetidos.

Medir logs tradicionales

sudo du -xhd1 /var/log | sort -h
sudo find /var/log -xdev -type f -size +100M -ls

Revisar systemd journal

journalctl --disk-usage

Para ver la configuración efectiva pueden revisarse los parámetros de journald y sus archivos adicionales:

systemd-analyze cat-config systemd/journald.conf

Rotación

logrotate permite rotar, comprimir y retirar logs tradicionales. Conviene comprobar:

• qué archivos cubre;
• con qué frecuencia;
• cuántas rotaciones conserva;
• si comprime;
• si el servicio reabre correctamente el log;
• si existen archivos no incluidos;
• si la rotación se ejecuta realmente.

sudo logrotate -d /etc/logrotate.conf
systemctl status logrotate.timer

No borrar el síntoma antes de corregir la causa

Si una aplicación genera 20 GB diarios de errores, reducir la retención evita el llenado inmediato, pero no resuelve el fallo. Debe identificarse por qué el servicio escribe tanto y qué evento inició el cambio.

Detectar archivos borrados que siguen ocupando espacio

A veces df muestra un uso elevado, pero du no encuentra archivos suficientes para explicarlo. Una causa habitual es que un proceso mantenga abierto un archivo que ya fue eliminado del directorio.

En Linux, el espacio no se libera hasta que el último proceso cierra el descriptor.

Detectar archivos eliminados abiertos

sudo lsof +L1

La salida puede mostrar procesos, descriptores y tamaños asociados a archivos marcados como eliminados.

Actuación

No debe terminarse un proceso crítico sin valorar el impacto. Las opciones pueden incluir:

• hacer que el servicio reabra sus logs;
• recargar la configuración;
• reiniciar únicamente el proceso afectado;
• programar una intervención si el servicio no admite recarga;
• corregir la rotación para que no vuelva a ocurrir.

Este caso demuestra por qué borrar un archivo no garantiza que el espacio quede disponible y por qué df y du deben interpretarse conjuntamente.

Vigilar el crecimiento de bases de datos

Una base de datos no debe gestionarse como una carpeta cualquiera. Sus archivos representan tablas, índices, transacciones, temporales y mecanismos internos del motor.

Qué puede crecer

• datos principales;
• índices;
• logs binarios o de transacciones;
• tablas temporales;
• históricos;
• auditoría;
• sesiones;
• colas;
• copias o volcados locales.

Medir desde el motor

El tamaño de los archivos debe contrastarse con consultas propias de MariaDB, MySQL, PostgreSQL u otro motor. El sistema de archivos muestra cuánto ocupa, pero el motor explica qué bases, tablas e índices son responsables.

Retención

Los logs de transacciones, históricos y tablas de actividad necesitan políticas explícitas. No deben conservarse indefinidamente por defecto ni borrarse manualmente sin conocer su función en replicación o recuperación.

Mantenimiento necesita margen

Optimizar tablas, reconstruir índices o restaurar una base puede requerir espacio adicional. Un volumen cercano al límite puede impedir precisamente la operación necesaria para reducirlo.

Separación

Cuando la criticidad lo justifica, separar datos, logs y copias en volúmenes distintos limita el impacto mutuo y hace más visibles las tendencias.

Controlar Docker, contenedores e imágenes

Los entornos de contenedores pueden acumular imágenes, capas, volúmenes, cachés de construcción y logs.

Resumen de uso

docker system df
docker system df -v

Elementos que suelen crecer

• imágenes antiguas;
• contenedores detenidos;
• volúmenes sin identificar;
• caché de builds;
• logs JSON;
• datos persistentes dentro de ubicaciones no documentadas.

Prune no es una política

Los comandos de limpieza pueden eliminar recursos no utilizados según Docker, pero antes hay que conocer qué volúmenes contienen datos, qué imágenes son necesarias para volver atrás y qué contenedores pertenecen a entornos detenidos temporalmente.

La limpieza automática sin inventario puede destruir capacidad de recuperación o datos que no estaban correctamente asociados.

Limitar logs

Los logs de contenedores deben usar rotación y límites adecuados. Una aplicación ruidosa puede llenar el volumen del motor aunque el contenedor aparente funcionar.

Datos persistentes fuera de la capa efímera

Los datos empresariales deben estar en volúmenes o montajes explícitos, documentados y respaldados. Esto facilita medirlos y evita confundirlos con capas desechables.

Evitar que las copias locales llenen producción

Las copias son necesarias, pero una estrategia mal diseñada puede convertirse en una de las principales causas de saturación.

Riesgos habituales

• volcados diarios sin retención;
• copias completas cuando bastaría una política incremental;
• copias comprimidas y originales temporales coexistiendo;
• errores que impiden borrar versiones antiguas;
• destino montado de forma incorrecta y escritura accidental en el disco local;
• snapshots tratados como copias permanentes;
• varias herramientas copiando los mismos datos.

Comprobar que el destino está montado

Una tarea puede estar configurada para escribir en /mnt/backup. Si el almacenamiento remoto no está montado, ese directorio sigue existiendo y la copia puede escribirse en el sistema raíz.

La tarea debe validar explícitamente el montaje antes de iniciar:

mountpoint -q /mnt/backup || exit 1

Retención comprobable

La política debe indicar cuántas copias diarias, semanales y mensuales se conservan, cuánto ocupan y qué proceso elimina las caducadas. La eliminación debe registrar resultado y alertar si falla.

Separar copia y producción

Una copia almacenada únicamente en el mismo servidor no protege frente a pérdida del equipo, ransomware, corrupción o error administrativo. La estrategia puede ampliarse con cómo hacer backups automáticos del servidor y cómo implementar copias 3-2-1.

Gestionar temporales, cachés y paquetes

Los archivos temporales y cachés suelen ser regenerables, pero no por ello deben borrarse indiscriminadamente.

Directorios temporales

/tmp y /var/tmp tienen comportamientos y expectativas diferentes. Algunas aplicaciones mantienen temporales durante procesos largos. La limpieza debe respetar antigüedad, propiedad y uso.

systemd-tmpfiles

En sistemas con systemd puede revisarse la política efectiva:

systemd-tmpfiles --cat-config

Caché de paquetes

En Debian y Ubuntu puede revisarse:

sudo du -sh /var/cache/apt/archives
apt-get -s clean

La opción de simulación ayuda a comprobar la intención antes de ejecutar una limpieza real. La caché puede ser útil para reinstalaciones o entornos sin conectividad estable, por lo que su política debe adaptarse al contexto.

Cachés de aplicaciones

Una caché puede reducir carga y latencia. Si se elimina sin comprenderla, el sistema puede sufrir un pico de reconstrucción. Lo correcto es definir tamaño máximo, caducidad y método de regeneración.

Archivos de compilación y despliegue

Las releases antiguas, dependencias descargadas y artefactos de construcción deben tener una retención explícita. Conservar una o varias versiones para reversión es distinto de acumular todas indefinidamente.

Asignar el crecimiento a usuarios y aplicaciones

La capacidad se gestiona mejor cuando cada conjunto de datos tiene propietario y finalidad.

Cuotas

Los sistemas de cuotas pueden limitar el espacio por usuario, grupo o proyecto cuando el sistema de archivos y la arquitectura lo permiten. Son especialmente útiles en entornos compartidos, pero requieren planificación y monitorización para no convertir un límite en una interrupción inesperada.

Separación por servicio

Si varias aplicaciones escriben en un único directorio sin estructura, resulta difícil atribuir el crecimiento. Conviene separar:

• datos de aplicación;
• subidas de usuarios;
• logs;
• temporales;
• cachés;
• exportaciones;
• copias;
• releases.

Propietario funcional

El administrador puede detectar que un repositorio crece, pero el responsable del servicio debe decidir cuánto histórico necesita, qué puede archivarse y qué valor empresarial conserva el dato.

Coste visible

Relacionar GB con aplicación y proceso permite comparar el coste de ampliar frente a mejorar retención, compresión, archivo o diseño.

Automatizar mediciones y alertas

La revisión manual ayuda a investigar, pero no sustituye una vigilancia continua.

Qué monitorizar

• porcentaje de ocupación por sistema de archivos;
• GB disponibles;
• inodos;
• crecimiento diario y semanal;
• cambio brusco;
• directorios críticos;
• estado de montajes externos;
• resultado de rotaciones;
• resultado de retención de copias;
• archivos eliminados abiertos;
• capacidad estimada en días.

Ejemplo de captura sencilla

date --iso-8601=seconds
findmnt -rn -o TARGET,SOURCE,FSTYPE

df -P -x tmpfs -x devtmpfs

df -Pi -x tmpfs -x devtmpfs

La salida puede enviarse a un sistema de métricas, una base ligera o un archivo histórico. Lo importante es que la recogida sea consistente y no dependa de recordar una revisión manual.

Alertas accionables

Una alerta útil debería indicar:

• servidor;
• sistema de archivos;
• uso actual;
• espacio libre;
• crecimiento reciente;
• tiempo estimado hasta el umbral;
• principales directorios responsables;
• procedimiento de actuación;
• persona responsable.

Evitar ruido

Una alerta que se activa y desactiva continuamente alrededor de un porcentaje termina ignorándose. Deben utilizarse histéresis, duración mínima, niveles y contexto.

La filosofía general de detección anticipada se desarrolla en cómo detectar cuellos de botella tecnológicos antes de que aparezcan.

Cómo actuar cuando el espacio entra en zona crítica

Cuando el margen es pequeño, la prioridad es estabilizar sin destruir información ni empeorar la incidencia.

1. Confirmar el sistema de archivos afectado

df -hT
df -i

2. Comprobar montajes

Verificar que no se está escribiendo en una ruta local porque un volumen esperado no se montó.

findmnt
mountpoint /ruta/esperada

3. Identificar la rama responsable

sudo du -xhd1 /punto/de/montaje | sort -h

4. Revisar archivos eliminados abiertos

sudo lsof +L1

5. Proteger servicios críticos

Evitar actualizaciones, importaciones o tareas que consuman espacio adicional. Si es necesario, pausar de forma controlada procesos no esenciales.

6. Liberar solo espacio seguro

Priorizar elementos regenerables y comprendidos: cachés conocidas, paquetes descargados, temporales caducados o rotaciones antiguas según política. No borrar bases de datos, volúmenes, archivos de aplicación ni logs activos sin validar.

7. Corregir la causa

La liberación de emergencia compra tiempo. Después deben corregirse retención, rotación, fuga, montaje, consulta, proceso o arquitectura responsable.

8. Registrar la incidencia

Debe quedar constancia de causa, espacio liberado, archivos afectados, decisiones, riesgos y medidas preventivas.

Decidir entre limpiar, archivar, optimizar o ampliar

No todo crecimiento es un problema. Una empresa con más clientes, cursos, documentos o históricos puede necesitar realmente más capacidad.

Preguntas de decisión

• ¿El dato tiene valor o es un residuo técnico?
• ¿Existe obligación de conservarlo?
• ¿Con qué frecuencia se consulta?
• ¿Puede regenerarse?
• ¿Puede moverse sin afectar al servicio?
• ¿El crecimiento continuará?
• ¿La ampliación puede hacerse sin parada?
• ¿Existe copia y vuelta atrás?

La solución correcta puede combinar varias medidas: corregir un log anómalo, archivar históricos y ampliar capacidad para el crecimiento legítimo restante.

Aplicación en un servidor con WordPress o LMS

Un servidor que comercializa y entrega formación online combina varios tipos de crecimiento.

Contenido subido

Imágenes, documentos, paquetes formativos y vídeos pueden crecer rápidamente. Los originales no deberían existir únicamente en producción. Conviene definir límites, formatos y repositorio maestro.

Miniaturas y derivados

WordPress puede generar múltiples tamaños por imagen. Plugins y temas pueden añadir derivados. Antes de borrar, debe conocerse qué tamaños utiliza realmente el sitio y cómo se regenerarían.

Base de datos

Revisiones, sesiones, logs de actividad, colas, datos de analítica, intentos de acceso y tablas de plugins pueden crecer sin relación directa con el número de artículos.

Copias dentro del árbol web

Guardar ZIP, volcados SQL o copias completas dentro del directorio público aumenta consumo y puede exponer información sensible. Las copias deben tener destino, permisos y retención controlados.

Logs de PHP, nginx y aplicación

Un error repetido puede generar gigabytes en poco tiempo. Deben vigilarse volumen y frecuencia, no solo conservar los registros.

Cachés

Las cachés de página, objetos, transcodificación o contenido pueden ser grandes. Deben tener límites y un procedimiento de limpieza que no dependa de borrar directorios al azar.

Campañas y matrículas

Antes de una campaña conviene proyectar nuevos usuarios, entregas de contenido, correos, sesiones, registros y copias. La capacidad debe probarse antes de aumentar tráfico.

Ejemplo de cuadro de capacidad

Plan de implantación paso a paso

Paso 1. Inventariar sistemas de archivos

Registrar dispositivos, montajes, capacidad, tipo, servicio y responsable.

Paso 2. Clasificar datos

Distinguir aplicaciones, bases, logs, copias, temporales, cachés y contenidos.

Paso 3. Tomar una línea base

Guardar uso, inodos y tamaño de directorios principales.

Paso 4. Automatizar la captura

Recoger datos diariamente o con la frecuencia adecuada.

Paso 5. Definir umbrales

Combinar porcentaje, espacio absoluto y tiempo estimado restante.

Paso 6. Revisar políticas de retención

Logs, journal, copias, históricos, releases, cachés e imágenes.

Paso 7. Validar montajes y destinos

Impedir que tareas escriban localmente cuando falta un almacenamiento externo.

Paso 8. Asignar responsables

Relacionar cada área de crecimiento con un servicio y propietario.

Paso 9. Preparar la ampliación

Documentar pasos, tiempo, costes, copia, migración y vuelta atrás.

Paso 10. Probar alertas

Confirmar que llegan, tienen contexto y activan una respuesta concreta.

Paso 11. Revisar después de cambios

Nuevas aplicaciones, plugins, cursos, bases o políticas pueden alterar la tendencia.

Paso 12. Auditar trimestralmente

Comparar crecimiento real con previsión, retirar residuos y actualizar capacidad.

Errores frecuentes

Esperar a que el disco esté casi lleno

Reduce opciones y convierte una planificación en emergencia.

Mirar solo el porcentaje

Ignora tamaño absoluto, tendencia y tiempo de ampliación.

No revisar inodos

El sistema puede dejar de crear archivos con espacio libre aparente.

Usar du sobre todo el servidor sin localizar el volumen

Genera carga, cruza montajes y ralentiza el diagnóstico.

Borrar archivos grandes sin identificar su propietario

Puede destruir datos o dejar servicios inconsistentes.

Confundir df y du

Miden aspectos distintos y sus diferencias aportan información.

Ignorar archivos eliminados abiertos

El espacio puede seguir ocupado hasta reiniciar o recargar el proceso.

Guardar copias en el mismo volumen sin límites

La protección termina compitiendo con producción.

Ejecutar limpiezas automáticas agresivas

Una regla genérica puede eliminar datos aún necesarios.

Comprar más disco sin corregir una fuga

Solo retrasa el siguiente llenado.

No reservar margen para mantenimiento

Las operaciones de recuperación y actualización pueden necesitar espacio adicional.

No registrar contexto

Sin relacionar cambios técnicos y empresariales, una tendencia es difícil de interpretar.

No comprobar que los montajes externos existen

Las copias pueden terminar llenando la raíz local.

Confundir snapshots con capacidad infinita

Los snapshots también consumen espacio y necesitan retención.

Lista de comprobación

• ¿Están inventariados todos los sistemas de archivos?
• ¿Se conoce qué servicio utiliza cada volumen?
• ¿Se miden porcentaje y GB libres?
• ¿Se controla el consumo de inodos?
• ¿Existe una línea base histórica?
• ¿Se mide crecimiento diario, semanal o mensual?
• ¿Se calculan días o meses hasta el umbral?
• ¿Los umbrales consideran el tiempo de ampliación?
• ¿Se conserva margen para mantenimiento?
• ¿Se conocen los directorios principales?
• ¿Los logs tienen rotación y límites?
• ¿Se controla el espacio de journal?
• ¿Se detectan archivos eliminados abiertos?
• ¿Las bases de datos tienen políticas de retención?
• ¿Los logs de transacciones están controlados?
• ¿Docker tiene inventario de imágenes, volúmenes y logs?
• ¿Las copias locales tienen retención?
• ¿Las tareas verifican que el destino está montado?
• ¿Temporales y cachés tienen políticas?
• ¿Las releases antiguas se retiran de forma controlada?
• ¿Cada conjunto de datos tiene propietario?
• ¿Las alertas incluyen contexto y responsable?
• ¿Existe procedimiento para zona crítica?
• ¿La ampliación está documentada?
• ¿Se revisan tendencias después de cambios?

Preguntas frecuentes

Conclusión

Controlar el crecimiento del espacio en disco de un servidor Linux exige pasar de la reacción puntual a la gestión continua de capacidad.

El primer paso es construir un mapa de almacenamiento: dispositivos, volúmenes, montajes, sistemas de archivos, servicios y responsables. Después deben medirse capacidad, espacio absoluto, porcentaje e inodos.

La cifra realmente útil no es solo cuánto espacio queda, sino a qué velocidad se consume y cuánto tiempo existe para actuar antes de alcanzar un umbral operativo.

df permite conocer el estado del sistema de archivos. du ayuda a localizar directorios. find identifica archivos relevantes y lsof +L1 descubre espacio ocupado por archivos eliminados que siguen abiertos. Ningún comando aislado sustituye la interpretación.

Logs, bases de datos, contenedores, copias, temporales, cachés y contenidos necesitan políticas de crecimiento y retención. La limpieza debe dirigirse a datos comprendidos; nunca debe basarse en borrar lo más grande sin conocer su función.

Cuando el crecimiento es legítimo, la ampliación debe planificarse con margen para compra, migración, pruebas y recuperación. Cuando el crecimiento es anómalo, primero debe corregirse la causa.

Para una microempresa, no hace falta una plataforma compleja. Un histórico diario, alertas bien diseñadas, revisión mensual y responsables claros permiten anticipar la mayoría de los llenados antes de que afecten a ventas, aplicaciones, bases de datos o plataformas LMS.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en Linux, administración de sistemas, almacenamiento, seguridad, copias y continuidad operativa.