El mantenimiento del sistema en Linux no consiste solo en actualizar paquetes de vez en cuando. Actualizar es importante, pero un sistema sano también necesita espacio libre, servicios controlados, logs revisados, copias de seguridad probadas, usuarios bien gestionados y una política clara sobre cuándo reiniciar.
Linux puede funcionar durante meses sin intervención, pero eso no significa que esté bien mantenido. Puede acumular paquetes antiguos, kernels que ya no se usan, logs enormes, servicios fallando en segundo plano, tareas programadas rotas o configuraciones que nadie recuerda haber cambiado.
Una buena rutina de mantenimiento del sistema evita que esos detalles pequeños se conviertan en cortes de servicio, pérdida de datos, problemas de seguridad o una máquina lenta y difícil de diagnosticar.
👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis
👉 También te dejo por aquí una guía de comandos Linux por categorías
Qué significa hacer mantenimiento del sistema en Linux
Mantener un sistema Linux significa revisar de forma periódica su estado, corregir desviaciones y dejarlo preparado para seguir funcionando con seguridad.
En la práctica, el mantenimiento del sistema incluye tareas como:
- Instalar actualizaciones de seguridad y correcciones importantes.
- Retirar paquetes, kernels o dependencias que ya no se usan.
- Vigilar el espacio en disco.
- Revisar logs y errores recurrentes.
- Comprobar servicios activos y unidades fallidas.
- Verificar copias de seguridad y restauraciones.
- Revisar usuarios, permisos y accesos.
- Comprobar tareas programadas con cron o systemd timers.
- Observar consumo de memoria, CPU, red y carga del sistema.
- Decidir cuándo reiniciar y cómo hacerlo sin romper servicios.
- Documentar cambios de configuración relevantes.
Un buen mantenimiento del sistema no busca tocarlo todo cada día. Busca saber qué mirar, cuándo mirarlo y cómo actuar sin improvisar.
Antes de empezar: identifica tu distribución
Muchos comandos son comunes en casi todas las distribuciones Linux, pero la gestión de paquetes cambia según la familia del sistema.
En Debian, Ubuntu y derivadas se usa normalmente:
apt update
apt upgradeEn Fedora, Rocky Linux, AlmaLinux o RHEL moderno:
dnf check-update
dnf upgradeEn Arch Linux y derivadas:
pacman -SyuSi no tienes claro qué distribución estás usando, puedes comprobarlo con:
cat /etc/os-releaseTambién conviene saber si estás en un equipo personal, un servidor físico, una máquina virtual, un contenedor o un VPS. La política de reinicios, backups y servicios puede cambiar bastante según el tipo de sistema.
Actualizaciones: seguridad antes que novedad
Las actualizaciones corrigen vulnerabilidades, errores y problemas de compatibilidad. En servidores, suelen ser una de las tareas más importantes del mantenimiento del sistema en Linux.
En Debian y Ubuntu:
sudo apt update
apt list --upgradable
sudo apt upgradeapt update actualiza la lista de paquetes disponibles. apt upgrade instala las nuevas versiones sin eliminar paquetes de forma agresiva. Si el sistema propone eliminar componentes importantes, conviene leer bien antes de aceptar.
En Fedora o sistemas con dnf:
dnf check-update
dnf upgradeEn Arch:
pacman -SyuNo actualices a ciegas un servidor crítico justo antes de irte. Hazlo en una ventana razonable, revisa los mensajes del gestor de paquetes y confirma después que los servicios siguen funcionando.
Para ver si un reinicio es recomendable en Debian o Ubuntu, algunas instalaciones crean este archivo:
test -f /var/run/reboot-required && cat /var/run/reboot-requiredSi se actualizan el kernel, systemd, libc u otros componentes base, muchas veces el reinicio es la forma más limpia de cargar todo correctamente.
Limpieza de paquetes y dependencias antiguas
Con el tiempo se acumulan paquetes que ya no son necesarios. En Debian y Ubuntu puedes revisar y limpiar con:
apt autoremove
apt autocleanautoremove elimina dependencias que quedaron instaladas y ya no son requeridas. autoclean limpia paquetes descargados que ya no hacen falta.
En sistemas con dnf:
dnf autoremove
dnf clean packagesEn Arch, puedes buscar paquetes huérfanos con:
pacman -QtdqY eliminarlos solo si entiendes qué son:
pacman -Rns $(pacman -Qtdq)Este último comando puede fallar si no hay paquetes huérfanos. En Arch, además, es buena idea revisar la documentación de tu distribución antes de automatizar limpiezas.
Importante: no elimines paquetes solo porque no reconoces su nombre. Algunos paquetes con nombres poco evidentes pueden ser dependencias importantes del escritorio, del servidor web, del sistema de red o de herramientas que sí usas.
Espacio en disco: detectar antes del 100%
Un disco lleno puede tumbar servicios, impedir inicios de sesión, romper bases de datos o bloquear actualizaciones. Por eso el espacio en disco debe revisarse con frecuencia.
Vista general:
df -hPara ver qué directorios ocupan más dentro de una ruta:
sudo du -h --max-depth=1 /var | sort -h
sudo du -h --max-depth=1 /home | sort -hDirectorios que suelen crecer:
- /var/log: logs del sistema y de servicios.
- /var/cache: cachés de paquetes y aplicaciones.
- /home: archivos de usuarios.
- /tmp: archivos temporales.
- /var/lib/docker: imágenes, volúmenes y contenedores si usas Docker.
- /var/lib/mysql o /var/lib/postgresql: bases de datos.
Si necesitas buscar archivos grandes:
sudo find / -xdev -type f -size +1G -ls-xdev evita cruzar a otros sistemas de archivos montados. Es útil para no mezclar resultados de discos externos, volúmenes o montajes de red.
No borres archivos grandes sin saber qué son. Si un log ocupa demasiado, normalmente conviene revisar logrotate o el servicio que lo genera, no vaciar archivos al azar.
Logs: leer el historial del sistema
Los logs muestran errores que el sistema puede estar tolerando en silencio. En distribuciones con systemd, journalctl es una herramienta central.
Ver errores del arranque actual:
journalctl -p err -bVer logs recientes:
journalctl -xeVer logs de un servicio:
journalctl -u nginx
journalctl -u sshVer cuánto ocupa el journal:
journalctl --disk-usageAdemás del journal, muchos servicios escriben en /var/log. Para evitar que los logs crezcan sin control existe logrotate, que rota, comprime y elimina logs antiguos según reglas.
Puedes revisar su configuración en:
ls /etc/logrotate.d/
cat /etc/logrotate.confLa idea no es borrar logs constantemente. La idea es conservar suficiente historial para diagnosticar problemas sin dejar que el disco se llene.
Servicios y unidades fallidas
Un sistema puede parecer normal aunque tenga servicios fallando. systemctl permite ver rápidamente si hay unidades en mal estado.
Comprobar estado general:
systemctl --failedVer servicios activos:
systemctl list-units --type=service --state=runningRevisar un servicio concreto:
systemctl status nombre-del-servicioReiniciar un servicio después de corregir un problema:
sudo systemctl restart nombre-del-servicioActivar un servicio al arranque:
sudo systemctl enable nombre-del-servicioDesactivarlo:
sudo systemctl disable nombre-del-servicioNo conviene desactivar servicios sin saber para qué sirven. Antes de tocar, revisa:
systemctl cat nombre-del-servicio
journalctl -u nombre-del-servicioLa pregunta correcta no es solo «¿está funcionando?», sino también «¿debería estar funcionando?».
Red y puertos abiertos
Parte del mantenimiento consiste en saber qué servicios están escuchando en red. Esto ayuda a detectar exposiciones innecesarias.
Ver puertos TCP y UDP en escucha:
ss -tulpenEn un servidor público, revisa especialmente servicios como SSH, bases de datos, paneles web, proxies, servidores de desarrollo y herramientas internas.
Una base de datos que solo debería usarse localmente no debería escuchar en todas las interfaces. Un panel de administración no debería estar expuesto sin protección. Un servicio de pruebas no debería quedar activo en producción.
Si usas firewall, comprueba sus reglas con la herramienta correspondiente:
sudo ufw status verboseO en sistemas con firewalld:
sudo firewall-cmd --list-allEl mantenimiento de red no es solo cerrar puertos. También es documentar qué puertos deben estar abiertos y por qué.
Memoria, carga y procesos
Para una revisión rápida del rendimiento:
free -h
uptime
topfree -h muestra memoria usada y disponible. uptime muestra cuánto tiempo lleva encendido el sistema y la carga media. top permite ver procesos que consumen CPU o memoria.
También puedes usar:
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | headUna carga alta no siempre significa problema. Depende del número de CPU, del tipo de trabajo y del momento. Lo importante es detectar cambios raros: un proceso que antes consumía poco y ahora consume mucho, una memoria que se agota cada día o una carga que sube siempre a la misma hora.
Si quieres profundizar en esta parte, puedes apoyarte en una rutina de monitoreo básico del sistema para convertir estas comprobaciones en hábitos repetibles.
Backups: no basta con «tener copias»
Un backup que no se ha probado es una esperanza, no una garantía.
En el mantenimiento del sistema hay que revisar:
- Que las copias se están generando.
- Que se guardan fuera del equipo principal o en otro volumen.
- Que incluyen los datos importantes.
- Que no incluyen solo archivos vacíos o incompletos.
- Que se pueden restaurar.
- Que hay historial suficiente para recuperar errores antiguos.
Comprobaciones sencillas:
ls -lh /ruta/de/backups
find /ruta/de/backups -type f -mtime -7 -lsSi usas rsync, borg, restic, snapshots del proveedor, copias de bases de datos o herramientas de panel, revisa sus logs y realiza una restauración de prueba periódicamente.
Ejemplo de revisión conceptual:
- El backup más reciente es de hoy o de esta semana.
- El tamaño tiene sentido.
- La tarea programada no ha fallado.
- Las credenciales o claves de cifrado están disponibles.
- Existe un procedimiento escrito para restaurar.
Para bases de datos, copiar solo los archivos del directorio puede no ser suficiente si el servicio está en uso. Muchas veces conviene usar mysqldump, pg_dump, snapshots consistentes o herramientas específicas.
Seguridad básica: usuarios, permisos y acceso
La seguridad también forma parte del mantenimiento. No hace falta convertir cada revisión en una auditoría completa, pero sí conviene mirar lo esencial.
Usuarios del sistema:
cut -d: -f1,3,7 /etc/passwdUsuarios con shell interactiva:
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwdMiembros del grupo sudo en Debian y Ubuntu:
getent group sudoEn otros sistemas puede ser el grupo wheel:
getent group wheelRevisa:
- Usuarios que ya no deberían existir.
- Cuentas con permisos de administrador.
- Claves SSH antiguas en ~/.ssh/authorized_keys.
- Accesos de aplicaciones o despliegues que nadie usa.
- Archivos con permisos demasiado abiertos.
Para buscar archivos con permisos peligrosos en una ruta concreta:
find /ruta/a/revisar -type f -perm -o+w -lsNo cambies permisos de forma masiva sin entender el impacto. Un chmod -R mal aplicado puede romper una aplicación o abrir datos sensibles.
Cron y systemd timers
Muchas tareas de mantenimiento, backups, renovaciones de certificados, limpiezas y sincronizaciones se ejecutan de forma programada. Si fallan, a veces nadie se entera hasta que el problema ya es grande.
Revisar cron del usuario actual:
crontab -lRevisar cron del sistema:
ls /etc/cron.d/
ls /etc/cron.daily/
ls /etc/cron.weekly/Con systemd timers:
systemctl list-timers<br>systemctl list-timers --allVer detalles de un timer:
systemctl status nombre.timer
systemctl cat nombre.timerUn punto clave: una tarea programada debe registrar errores de forma visible. Si un script falla silenciosamente, no es mantenimiento; es una sorpresa aplazada.
Política de reinicios
Linux puede aguantar mucho tiempo sin reiniciar, pero eso no siempre es una virtud. Después de actualizar kernel, librerías centrales o servicios críticos, reiniciar puede ser necesario.
En servidores, define una política:
- Cuándo se permite reiniciar.
- Quién debe aprobarlo si afecta a usuarios.
- Qué servicios se comprueban después.
- Cómo se avisa si hay interrupción.
- Qué hacer si el sistema no vuelve correctamente.
Antes de reiniciar:
who
uptime
systemctl --failedDespués de reiniciar:
uptime
systemctl --failed
journalctl -p err -bEn equipos personales, reiniciar tras actualizaciones importantes suele ser más simple. En servidores, debe hacerse con ventana de mantenimiento o con alta disponibilidad si el servicio lo requiere.
Archivos de configuración y cambios controlados
Muchos problemas de mantenimiento aparecen porque alguien cambió una configuración y nadie lo documentó.
Buenas prácticas:
- Antes de editar un archivo importante, crea una copia con fecha.
- Usa control de versiones para configuraciones cuando sea posible.
- Anota por qué se hizo el cambio.
- Valida la configuración antes de reiniciar el servicio.
- Guarda comandos usados en una nota operativa.
Ejemplo con Nginx:
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-2026-07-01
sudo nginx -t
sudo systemctl reload nginxEjemplo con SSH:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-2026-07-01
sudo sshd -t
sudo systemctl reload sshEl objetivo no es llenar el sistema de copias antiguas, sino poder volver atrás si una modificación rompe algo.
Monitorización mínima
Aunque no uses una plataforma completa de monitorización, deberías tener una forma de enterarte de problemas básicos.
Como mínimo, conviene vigilar:
- Espacio en disco.
- Uso de memoria.
- Carga del sistema.
- Servicios críticos.
- Certificados TLS que caducan.
- Backups fallidos.
- Errores repetidos en logs.
En sistemas pequeños, una combinación de systemctl, journalctl, alertas del proveedor, scripts sencillos y comprobaciones manuales puede ser suficiente. En sistemas importantes, herramientas como Prometheus, Grafana, Zabbix, Netdata, Nagios, Uptime Kuma o los monitores del proveedor ayudan mucho.
La regla práctica: si algo puede dejarte sin servicio, deberías enterarte antes que tus usuarios.
Automatizar sin perder el control
Automatizar mantenimiento puede ser buena idea, pero no todo debe automatizarse igual.
Se puede automatizar:
- Alertas de disco.
- Comprobación de backups.
- Informes de servicios fallidos.
- Limpieza controlada de cachés.
- Actualizaciones de seguridad en sistemas no críticos o bien probados.
Conviene revisar manualmente:
- Actualizaciones grandes.
- Cambios de versión de distribución.
- Limpiezas de datos.
- Eliminación de usuarios.
- Cambios de firewall.
- Reinicios de servidores críticos.
La automatización debe dejar logs y avisar cuando falla. Un script silencioso puede crear una falsa sensación de seguridad.
Conclusión
El mantenimiento del sistema en Linux combina actualizaciones, limpieza, observación, seguridad y disciplina operativa. No se trata de ejecutar muchos comandos sin pensar, sino de entender el estado del sistema y actuar con criterio.
Una buena rutina de mantenimiento del sistema evita discos llenos, servicios caídos, backups inútiles, accesos olvidados y problemas que aparecen justo cuando más necesitas que el sistema funcione. Si mantienes una lista semanal y otra mensual, documentas los cambios y pruebas tus copias de seguridad, ya estarás por delante de la mayoría de problemas habituales.
