Cómo limpiar un servidor Linux de forma segura sin afectar a los servicios

Nivel: Intermedio (sistemas de producción)
Tiempo estimado: ~30 minutos
Objetivo: Liberar espacio en disco en un servidor Linux eliminando paquetes que no se utilizan, núcleos antiguos, registros obsoletos y archivos almacenados en caché, sin interrumpir ningún servicio en ejecución.

Esta guía da por supuesto que se dispone de acceso SSH a un VPS de producción o similar. No la ejecutes a ciegas en sistemas críticos sin copias de seguridad.

Introducción

Con el tiempo, incluso un VPS poco utilizado acumula «lastre»: paquetes huérfanos, kernels obsoletos, gigabytes de registros sin rotar y restos de caché de paquetes. Si no se controla, un disco lleno provocará el fallo de tu servidor web, interrumpirá las operaciones de escritura en la base de datos y saturará tu cola de correo. Esta guía de limpieza de sistemas Linux te explica paso a paso cómo limpiar un servidor Linux de forma segura: comprobando primero el uso del disco, eliminando lo que sea seguro eliminar y verificando que tus servicios hayan sobrevivido al proceso. Todos los comandos aquí descritos pueden ejecutarse de forma segura en un servidor en funcionamiento sin tiempo de inactividad.

Qué vas a limpiar

Categoría	Ejemplos	Ahorro habitual
Paquetes y dependencias en desuso	Bibliotecas huérfanas, controladores sustituidos	100 MB - 2 GB
Kernels antiguos	Versiones anteriores del núcleo	200 MB por núcleo
Caché de paquetes	Archivos .deb / .rpm descargados	500 MB - 5 GB
Registros de Journal	Archivos de registro de systemd	100 MB - 10 GB
Archivos de registro rotados	/var/log/.gz, .1	Varía

Requisitos previos

Antes de empezar, asegúrate de que se cumplen las siguientes condiciones:

Sistema operativo: Ubuntu 24.04/26.04 LTS, Debian 13 o AlmaLinux 10
Acceso: acceso como «sudo» o como «root» al servidor a través de SSH
Conocimientos necesarios: Manejo con soltura del terminal de Linux y navegación básica por la línea de comandos
Copia de seguridad: Realiza siempre una instantánea o una copia de seguridad antes de eliminar paquetes de forma masiva en un servidor de producción. En INTROSERV, puedes solicitar una copia de seguridad completa directamente desde el Área de Clientes.

Info

Esta guía de limpieza del sistema Linux abarca tanto los sistemas basados en APT (Ubuntu, Debian) como los basados en DNF/YUM (AlmaLinux, RHEL). Los comandos que difieren entre las distintas familias se muestran por separado. Los comandos que son idénticos en todos los sistemas se muestran una sola vez.

No continúes si se da alguna de las siguientes circunstancias:

La partición/ está llena en más del 95 %: es posible que tu sistema ya esté fallando en las operaciones de escritura. Soluciona primero la causa inmediata (busca y elimina manualmente un único archivo de gran tamaño).
Los servicios ya están inactivos o se comportan de forma inesperada. Investiga la causa raíz antes de realizar la limpieza para evitar que dejen de funcionar los servicios de los que dependen los sistemas Linux.
No dispone de ninguna copia de seguridad ni instantánea. Realice una primero; en INTROSERV, esto lleva menos de 2 minutos desde el Área de Clientes.

Paso 1: Comprueba el uso del disco antes de empezar

Nivel de riesgo: BAJO — Solo se utilizan comandos de solo lectura. No se modifica nada.

Nunca limpies a ciegas. Primero, averigua qué es lo que realmente está ocupando espacio.

1.1 Comprueba el uso total del disco

Ejecuta «df» para comprobar el uso del disco a nivel del sistema de archivos:

df -h

Resultado esperado:

Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 34G 3.8G 90% / tmpfs 1.0G 0 1.0G 0% /dev/shm

Una partición / con un uso superior al 80 % es una señal de alerta. Por encima del 95 %, los servicios empezarán a fallar.

1.2 Identifica los elementos que más espacio ocupan

Utiliza el comando `du` para analizar los directorios. Empieza por la raíz y ve descendiendo:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Esto muestra los 20 directorios más grandes bajo /. Los culpables habituales son /var/log, /var/cache, /usr y /home.

Reduzca aún más la búsqueda:

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 Comprueba el uso de inodos

El espacio en disco no es el único límite. Los inodos controlan el número de archivos. Una partición puede tener espacio libre pero quedarse sin inodos, lo que también provocará que fallen las operaciones de escritura.

df -i

Resultado esperado:

Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2621440 210543 2410897 9% /

Si IUse% supera el 80 %, es probable que haya un directorio con decenas de miles de archivos pequeños; a menudo se trata de una cola de correo, un directorio de sesión o una caché de PHP. Utiliza du --inodes para localizarlo:

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Tip

Deberías comprobar el uso del disco que muestran los sistemas Linux antes de continuar. En los planes VPS KVM de INTROSERV, las cuotas de disco se aplican tanto a nivel de bloques como de inodos. Quedarse sin cualquiera de los dos provocará el mismo síntoma: las operaciones de escritura fallarán de forma silenciosa o los servicios informarán de que «no queda espacio en el dispositivo».

Paso 2: Elimina los paquetes y las dependencias que no utilices

Nivel de riesgo: MEDIO. La eliminación de paquetes es reversible a través del historial del gestor de paquetes, pero revisa la lista antes de confirmar.

Los paquetes que no se utilizan son los más seguros de eliminar. Ocupan espacio en el disco, no sirven a ningún proceso en ejecución y, en algunos casos, contienen vulnerabilidades CVE sin parchear.

2.1 Ubuntu / Debian - apt autoremove

apt autoremove elimina los paquetes que se instalaron como dependencias pero que ya no son necesarios para nada:

sudo apt autoremove --purge -y

La opción --purge también elimina los archivos de configuración restantes. Sin ella, el binario del paquete se elimina, pero los archivos de configuración permanecen en su lugar.

Resultado esperado:

The following packages will be REMOVED: libfoo1 libbar2 old-driver-utils ... 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

Info

apt autoremove es la forma más segura de eliminar paquetes en desuso que los gestores de dependencias de Linux reconocen como huérfanos. No elimina los paquetes que hayas instalado manualmente y que ya no utilices. Esos requieren una revisión manual con apt list --installed.

2.2 AlmaLinux / RHEL - dnf autoremove

sudo dnf autoremove -y

En sistemas antiguos de RHEL 7 / CentOS 7, utiliza ` yum autoremove`:

sudo yum autoremove -y

Warning

En los sistemas de la familia RHEL, «dnf autoremove» y «yum autoremove» son más agresivos que sus equivalentes de Debian. Pueden proponer la eliminación de paquetes que, según el gráfico de dependencias, parecen no utilizarse, pero que tu aplicación aún necesita. Revisa la lista de eliminación con cuidado antes de confirmar.

2.3 Limpiar la caché de paquetes

Tras las actualizaciones e instalaciones, los gestores de paquetes almacenan localmente los archivos comprimidos descargados. Se pueden eliminar sin problema una vez finalizada la instalación.

Ubuntu / Debian:

sudo apt clean

Esto elimina todos los archivos .deb almacenados en caché de /var/cache/apt/archives/. Para eliminar solo los paquetes que ya no están disponibles en el repositorio (versiones sustituidas):

sudo apt autoclean

AlmaLinux / RHEL:

sudo dnf clean all

Resultado esperado:

16 files removed

Tip

El comando«apt clean» siempre es seguro. Solo elimina la caché de descargas. Si más adelante necesitas reinstalar un paquete, se volverá a descargar del repositorio.

Paso 3: Eliminar kernels antiguos

Nivel de riesgo: ALTO. Si se elimina el núcleo incorrecto, el servidor no podrá arrancar tras el siguiente reinicio. Comprueba siempre el resultado de «uname -r» antes de continuar.

Cada actualización del kernel deja la versión anterior en su sitio como medida de seguridad. Una vez confirmada la estabilidad del servidor con el nuevo kernel, se pueden eliminar los kernels antiguos sin riesgo; cada uno suele liberar entre 200 y 400 MB.

3.1 Comprueba qué núcleo se está ejecutando

Nunca elimines el kernel con el que estás arrancado actualmente:

uname -r

Resultado esperado:

5.15.0-105-generic

3.2 Mostrar todos los núcleos instalados

Ubuntu / Debian:

dpkg -l | grep linux-image | awk '{print $2}'

Resultado esperado:

linux-image-5.15.0-100-generic linux-image-5.15.0-105-generic linux-image-generic

El metapaquete no debe eliminarse, ya que realiza un seguimiento del kernel recomendado actualmente:

Ubuntu: linux-image-generic
Debian: linux-image-amd64
AlmaLinux: No se utiliza ningún metapaquete, sino que se basa en la opción ` installonly_limit ` de dnf.

Elimina únicamente los paquetes con versión específica que no correspondan a tu kernel actual.

AlmaLinux / RHEL:

rpm -q kernel

Resultado esperado:

kernel-5.14.0-284.11.1.el9_2.x86_64 kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Eliminar kernels antiguos

Ubuntu / Debian - método automático:

El comando «apt autoremove » del paso 2 ya se encarga de los núcleos antiguos en Ubuntu si está instalado «linux-image-generic ». También puedes seleccionarlos explícitamente. Sustituye la versión por la que quieras eliminar (no la que se está ejecutando actualmente):

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL:

El gestor de paquetes dnf conserva un número configurable de kernels antiguos. Establece el límite en /etc/dnf/dnf.conf:

sudo nano /etc/dnf/dnf.conf

Añade o actualiza la línea:

installonly_limit=2

A continuación, ejecuta:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Esto elimina todos los núcleos excepto los dos más recientes.

Warning

Comprueba que el comando `uname -r` coincida con uno de los núcleos que vas a conservar antes de eliminar los núcleos antiguos que los servidores Linux aún necesitan. Eliminar el núcleo activo no dañará el sistema en funcionamiento, pero no tendrás nada con lo que arrancar tras el siguiente reinicio.

Paso 4: Limpiar los registros del diario

Nivel de riesgo: BAJO - Solo elimina las entradas de registro archivadas. Los servicios en ejecución no se ven afectados.

systemd-journald recopila los registros de todos los servicios del sistema. Por defecto, puede crecer sin límite hasta alcanzar el límite de espacio en disco, o hasta que dicho límite se agote.

4.1 Comprueba el tamaño actual del diario

journalctl --disk-usage

Resultado esperado:

Archived and active journals take up 2.3G in the filesystem.

4.2 Recortar el diario

Para conservar solo los registros de los últimos 7 días:

sudo journalctl --vacuum-time=7d

Para conservar solo los últimos 500 MB:

sudo journalctl --vacuum-size=500M

Resultado esperado:

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Evitar que el diario siga creciendo

Crea un archivo de configuración de sustitución para limitar el tamaño del diario de forma permanente (en AlmaLinux 10, el archivo de configuración principal no se encuentra en /etc/ de forma predeterminada, por lo que este es el método estándar):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Aplicar el cambio:

sudo systemctl restart systemd-journald

Info

Durante la limpieza de los registros del diario, los sistemas Linux no afectan a los registros de las aplicaciones en /var/log/; estos son gestionados por logrotate. El diario solo abarca los servicios nativos de systemd que escriben directamente en él (como sshd, nginx cuando se utiliza la unidad de systemd, cron, etc.).

Paso 5: Limpiar los archivos de registro rotados y antiguos

Nivel de riesgo: MEDIO — Solo se eliminan los archivos comprimidos. No toques los archivos que no tengan la extensión .gz o un sufijo numérico.

Los registros de aplicaciones en /var/log/ son gestionados por logrotate. Normalmente, logrotate conserva un número determinado de copias rotadas y las comprime automáticamente. Si logrotate estaba mal configurado o no se estaba ejecutando, es posible que encuentres grandes acumulaciones de archivos .gz, .1 y .2.

5.1 Buscar archivos de registro de gran tamaño

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

O, más sencillamente:

sudo du -h /var/log | sort -rh | head -20

5.2 Eliminar archivos de registro comprimidos antiguos

Los registros rotados comprimidos (.gz) se pueden eliminar sin problema. Son archivos de registros que ya se han cerrado.

En primer lugar, previsualiza lo que se va a eliminar: ejecuta el comando sin el parámetro -delete para ver la lista:

sudo find /var/log -name "*.gz" -mtime +30

Si el resultado parece correcto, ejecuta la eliminación propiamente dicha:

sudo find /var/log -name "*.gz" -mtime +30 -delete

Esto elimina los archivos comprimidos de registro (.gz) con más de 30 días de antigüedad.

Warning

No elimines los archivos de registro en los que se está escribiendo activamente, es decir, aquellos que no tengan un sufijo de rotación ni la extensión .gz. Eliminar /var/log/nginx/access.log mientras nginx está en ejecución no impide que nginx siga escribiendo en el inodo ahora eliminado. El espacio no se libera hasta que se reinicia nginx. En su lugar, trúncalo de forma segura: sudo truncate -s 0 /var/log/nginx/access.log.

5.3 Comprueba que logrotate esté configurado correctamente

Comprueba qué servicios tienen configuraciones de logrotate:

ls /etc/logrotate.d/

Ejecuta logrotate manualmente en modo de depuración para confirmar que funciona sin errores:

sudo logrotate -d /etc/logrotate.conf

La opción -d es una simulación: no se cambia nada, pero verás exactamente lo que ocurriría. Si falta algún servicio en /etc/logrotate.d/, crea una configuración para él. Consulta la guía de rotación de registros para obtener instrucciones completas sobre la configuración de logrotate.

Paso 6: Borrar archivos temporales

Nivel de riesgo: MEDIO — Las sesiones de PHP y las cachés de las aplicaciones afectan a los usuarios activos. Realiza una vista previa antes de eliminarlas.

6.1 Limpiar /tmp

La mayoría de las distribuciones limpian/tmp al reiniciar el sistema. Si su servidor lleva meses en funcionamiento, es posible que se hayan acumulado archivos temporales de gran tamaño:

du -sh /tmp

Para eliminar los archivos con más de 7 días de antigüedad, comprueba primero el contenido:

sudo find /tmp -type f -mtime +7

Si la lista parece segura, ejecuta el comando de eliminación:

sudo find /tmp -type f -mtime +7 -delete

6.2 Limpiar las cachés de las aplicaciones

Muchas aplicaciones crean sus propias cachés. Comprueba estas ubicaciones habituales (nota: verifica que estos directorios existan en tu sistema; en un sistema limpio es posible que no estén presentes y que aparezca el error «No existe tal archivo o directorio»):

# PHP session files (often forgotten, if installed)
sudo du -sh /var/lib/php/sessions/

# Pip / Python package caches (if running as root and installed)
sudo du -sh /root/.cache/pip/

# npm cache (if node is installed system-wide)
sudo du -sh /root/.npm/

Estos directorios se pueden purgar con total seguridad si la aplicación no los está utilizando activamente.

Tip

Antes de limpiar la caché de una aplicación, confirma que el servicio no se encuentre en medio de una transacción. Si se limpia un directorio de sesión de PHP mientras hay usuarios conectados, se cerrará la sesión de todos ellos.

Paso 7: Comprueba que los servicios siguen en ejecución

Nivel de riesgo: BAJO — Verificación de solo lectura. Ejecútala después de cada paso, no solo al final.

Después de cada ronda de limpieza, comprueba que tus servicios siguen funcionando. Hazlo antes de cerrar tu sesión SSH.

7.1 Comprueba el estado de los servicios críticos

Comprueba únicamente los servicios que estén realmente instalados en tu servidor (en un sistema limpio, al comprobar nginx o mysql aparecerá el mensaje «Unit not found»).

Ubuntu / Debian:

systemctl status nginx systemctl status mysql systemctl status ssh

AlmaLinux / RHEL:

systemctl status nginx systemctl status mysqld systemctl status sshd

Cada uno debería mostrar «Active: active (running)». Si alguno aparece como «failed » o «inactive», comprueba sus registros:

journalctl -u nginx --since "10 minutes ago"

7.2 Confirma que ha mejorado el uso del disco

df -h

Compara la columna «% de uso» con lo que observaste en el paso 1. El cambio debería reflejar el espacio que has liberado.

7.3 Prueba tu aplicación

Si ejecutas un servidor web, envía una solicitud de prueba:

curl -I http://localhost

Resultado esperado:

HTTP/1.1 200 OK Server: nginx/1.24.0

Un código de estado 200 OK confirma que nginx está gestionando el tráfico con normalidad.

Solución de problemas

`df` no muestra ninguna mejora tras eliminar paquetes

La eliminación de paquetes libera espacio de forma inmediata. Si `df ` no cambia, significa que los archivos siguen abiertos. Busca los archivos abiertos pero eliminados:

sudo lsof | grep deleted

Reinicia el servicio que mantiene el archivo abierto y se recuperará el espacio.

`apt autoremove` quiere eliminar algo que parece importante

Lee la lista con atención. Si ves el nombre de un paquete que reconoces como dependencia de un servicio en ejecución, pulsa N e investiga. Ejecuta `apt-cache rdepends <paquete> ` para ver qué depende de él.

`journalctl --vacuum-time` no produce ningún cambio

Es posible que el diario ya sea más pequeño que el objetivo. Compruébalo con `journalctl --disk-usage`. Confirma también que el diario sea persistente: comprueba que exista `/var/log/journal/`. Si solo existe `/run/log/journal/`, el diario se almacena en la RAM y se borra automáticamente al reiniciar el sistema.

El servicio falla tras ejecutar `apt autoremove`

Ejecuta `systemctl status <servicio> ` y comprueba el error. Si se ha eliminado una biblioteca compartida, reinstala el paquete que la proporciona:

sudo apt install --fix-broken

Se agotan los inodos a pesar de haber espacio libre en disco

Busca el directorio con más archivos:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Causas habituales: colas de correo en /var/spool/mail, sesiones de PHP en /var/lib/php/sessions o una tarea cron fuera de control que crea archivos temporales.

Revertir los cambios

La mayoría de las operaciones de limpieza no son reversibles: los archivos eliminados se pierden. Por ello, el paso de la copia de seguridad de los «Requisitos previos» es obligatorio.

En el caso concreto de la eliminación de paquetes, puedes reinstalar lo que se haya eliminado:

Ubuntu / Debian:

sudo apt install <package-name>

AlmaLinux / RHEL:

sudo dnf install <package-name>

Para ver el historial de lo que se ha eliminado en la sesión actual:

Ubuntu / Debian:

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL:

sudo dnf history list sudo dnf history undo last

El comando«dnf history undo last» reinstala los paquetes eliminados en la última transacción, lo que resulta una herramienta de recuperación muy útil si la función «autoremove» ha ido más allá de lo previsto.

Conclusión

La limpieza de un servidor Linux sin tiempo de inactividad se reduce a tres cosas: medir primero, eliminar solo lo que el sistema confirme que no se utiliza y verificar los servicios tras cada paso. Ejecuta df -h y du antes de tocar nada. Utiliza «apt autoremove » o «yum autoremove» para los paquetes en desuso, «journalctl --vacuum-time» para limpiar los registros del diario y «find /var/log -name "*.gz"» para los archivos rotados antiguos. Elimina los kernels antiguos solo después de confirmar que uname -r coincide con el que vas a conservar. Y comprueba siempre systemctl status antes de cerrar la terminal.

En el caso de un VPS de INTROSERV, mantener el uso de / por debajo del 80 % es un objetivo práctico: deja margen para picos de registros y actualizaciones de paquetes sin necesidad de una intervención de emergencia. Si el espacio en disco es un problema recurrente, plantéate cambiar el tamaño del almacenamiento de tu VPS directamente desde el Área de Clientes de INTROSERV.

Versión del documento: 1.0
Última actualización: mayo de 2026
Responsable: Equipo de documentación técnica