Plan de actualizaciones de seguridad automáticas y reinicios en VPS (2026): cómo configurar unattended-upgrades, reboot-required y ventanas de mantenimiento

La documentación oficial de Ubuntu Server sitúa las actualizaciones automáticas dentro de la gestión de software, y el componente central es unattended-upgrades. Puede instalar actualizaciones de seguridad automáticamente y también puede configurarse para decidir si limpia automáticamente y si reinicia automáticamente.

Pero estas acciones deben verse por separado:

• Comprobar actualizaciones automáticamente
• Descargar actualizaciones automáticamente
• Instalar actualizaciones de seguridad automáticamente
• Si se necesita reiniciar después de la actualización
• Si realmente se reinicia automáticamente
• Si los servicios se recuperan con normalidad después del reinicio

Muchos VPS solo llegan al tercer paso. Los paquetes de seguridad sí se instalan, pero la máquina no se reinicia y nadie revisa el servicio web, la base de datos ni los contenedores Docker. Para un blog personal puede ser solo un riesgo menor; para un sitio web con pedidos, inicios de sesión y devoluciones de pago, puede convertirse en un incidente en producción.

Primero confirma si el paquete está instalado:

dpkg -l unattended-upgrades

Si no está instalado, puedes instalarlo:

sudo apt update
sudo apt install unattended-upgrades

Luego revisa la configuración de actualizaciones automáticas:

cat /etc/apt/apt.conf.d/20auto-upgrades

Una configuración común es similar a:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Estas dos líneas significan aproximadamente: actualizar la lista de paquetes cada día y ejecutar unattended-upgrades.

También puedes confirmarlo con la salida de configuración propia de apt:

apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade'

Si solo ves Update-Package-Lists y no ves Unattended-Upgrade, puede significar que solo se actualiza automáticamente la lista de paquetes y no se instalan automáticamente las actualizaciones de seguridad.

Los sistemas Ubuntu/Debian actuales suelen activar las tareas relacionadas con apt mediante temporizadores de systemd. Puedes revisar:

systemctl list-timers | grep apt

Es posible que veas:

apt-daily.timer
apt-daily-upgrade.timer

Luego revisa el estado específico:

systemctl status apt-daily.timer
systemctl status apt-daily-upgrade.timer

No te tranquilices solo porque veas el temporizador activo. Que el temporizador esté activo solo significa que se ejecutará según lo programado; no significa que cada actualización tenga éxito.

Revisar los registros es más fiable:

sudo ls -lh /var/log/unattended-upgrades/
sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log

Si quieres consultar el historial relacionado con apt:

sudo less /var/log/apt/history.log
sudo less /var/log/apt/term.log

Fíjate en si hay información como failed, kept back, dependency problem o dpkg interrupted.

Para un VPS normal, prefiero instalar automáticamente las actualizaciones de seguridad en lugar de instalar sin supervisión todas las actualizaciones normales.

Las razones son prácticas:

• Las actualizaciones de seguridad suelen ser más adecuadas para la automatización
• Las actualizaciones de versión normales pueden introducir cambios de configuración
• Los cambios de versión mayor en bases de datos, entornos de ejecución de lenguajes y servicios web tienen más probabilidades de afectar a la aplicación
• Los equipos pequeños o los sitios personales no tienen pruebas de regresión completas

/etc/apt/apt.conf.d/50unattended-upgrades configura las fuentes permitidas para las actualizaciones automáticas. En Ubuntu suele habilitarse el security pocket. Puedes revisar:

sudo grep -n "Allowed-Origins" -A 20 /etc/apt/apt.conf.d/50unattended-upgrades

No copies un bloque grande de Internet sin leer la configuración. Las distintas versiones de Ubuntu, si Ubuntu Pro está habilitado y si existen fuentes de terceros pueden hacer que la configuración sea diferente.

Mi consejo es:

• Parches de seguridad del sistema: se pueden instalar automáticamente
• Repositorios de terceros: precaución con las actualizaciones automáticas
• Versiones mayores de bases de datos: no actualizar sin supervisión
• Aplicaciones de negocio: seguir tu propio proceso de publicación

Las actualizaciones automáticas sirven para reducir riesgos de seguridad básicos, no para hacer una gestión completa de cambios por ti.

En Ubuntu/Debian, la comprobación más directa:

test -f /var/run/reboot-required && cat /var/run/reboot-required

Si existe, normalmente muestra:

*** System restart required ***

También puedes ver qué paquetes activaron la necesidad de reinicio:

cat /var/run/reboot-required.pkgs

Comúnmente verás:

linux-base
linux-image-...
libc6

Si se actualizó el kernel y quieres confirmar qué kernel se está ejecutando actualmente:

uname -r
dpkg -l 'linux-image*' | grep '^ii'

Si el nuevo kernel ya está instalado pero uname -r sigue siendo la versión antigua, eso significa que se necesita un reinicio para cambiar.

unattended-upgrades puede configurarse para reiniciar automáticamente; por ejemplo, la opción relevante suele verse así:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Aquí no recomiendo que todos lo cambien directamente a true.

Los riesgos del reinicio automático son concretos:

• Los servicios no se inician automáticamente después del reinicio de la máquina
• Los contenedores Docker no tienen configurada una política de reinicio
• Las reglas del firewall se pierden después del reinicio
• La recuperación de la base de datos es lenta y el sitio web devuelve 502 durante un tiempo breve
• Las comprobaciones de disco o el mantenimiento del proveedor de la nube hacen que el arranque tarde más
• Estás en medio de una sesión SSH y la máquina se reinicia de repente
• Un sitio web pequeño no tiene supervisión y está caído medio día antes de que alguien lo note

Si es un VPS puramente de pruebas, el reinicio automático no supone problema. Si es un sitio en producción, prefiero "instalación automática de actualizaciones de seguridad + reinicio manual/semiautomático en una ventana de mantenimiento fija".

Para la mayoría de los sitios web pequeños, lo organizaría así:

• Comprobar e instalar actualizaciones de seguridad automáticamente cada día
• Fijar una ventana de mantenimiento de bajo tráfico cada semana, por ejemplo los martes a las 03:30
• Revisar /var/run/reboot-required antes de la ventana de mantenimiento
• Si se necesita reiniciar, confirmar primero las copias de seguridad, el estado de los servicios y la monitorización
• Ejecutar un conjunto de comprobaciones de estado después del reinicio

Una comprobación sencilla antes del mantenimiento:

hostnamectl
uptime
systemctl --failed
df -h
df -i
free -m
test -f /var/run/reboot-required && cat /var/run/reboot-required

Si systemctl --failed ya muestra servicios fallidos, no te apresures a reiniciar. Primero averigua si los servicios fallidos son críticos. De lo contrario, después del reinicio puede convertirse en "antes solo fallaba un servicio, ahora todo el sitio no abre".

Antes de reiniciar el VPS, revisa si los servicios críticos están enabled:

systemctl is-enabled nginx
systemctl is-enabled mysql
systemctl is-enabled postgresql
systemctl is-enabled docker

Si usas Docker Compose, confirma la política de reinicio de los contenedores:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker inspect --format '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' $(docker ps -q)

Las políticas comunes incluyen:

always
unless-stopped
on-failure

Si tu sitio web depende completamente de Docker, pero Docker no se inicia al arrancar, o los contenedores no tienen política de reinicio, es muy probable que el sitio web no se recupere automáticamente después de reiniciar el VPS.

Cuando llegue la ventana de mantenimiento, se recomienda dejar primero un registro del estado actual:

date
uptime
systemctl --failed
ss -lntp

Luego reiniciar:

sudo reboot

Si es un VPS remoto, espera de 1 a 3 minutos después del reinicio antes de volver a conectarte por SSH. Distintos proveedores de nube, distintas actualizaciones del kernel y distintos estados del disco pueden hacer que el tiempo de arranque varíe.

Al volver, revisa primero:

uptime
uname -r
systemctl --failed
journalctl -b -p warning --no-pager | tail -n 80

Luego revisa los servicios de negocio:

systemctl status nginx --no-pager
systemctl status docker --no-pager
curl -I https://example.com

Si el sitio web tiene una base de datos, cola o caché detrás, revisa también los servicios correspondientes. No termines solo porque SSH puede conectarse.

Normalmente preparo una lista de verificación muy sencilla pero eficaz:

systemctl --failed
journalctl -b -p err --no-pager
ss -lntp
df -h
df -i
free -m

Para sitios web, añade:

curl -I https://example.com
curl -I https://example.com/login

Nginx:

sudo nginx -t
sudo tail -n 80 /var/log/nginx/error.log

Docker:

docker ps
docker compose ps
docker compose logs --tail 80

Base de datos:

systemctl status mysql --no-pager
systemctl status postgresql --no-pager

Esto no es para presumir de comandos, sino para evitar que "la máquina se reinició, pero el negocio no se recuperó". El ciclo de las actualizaciones de seguridad debería ser: instalar, reiniciar, verificar, registrar.

Algunos VPS realmente no se pueden reiniciar sin más, por ejemplo cuando se está ejecutando una campaña, una migración de datos, tareas largas, o cuando temporalmente no hay nadie de guardia.

En ese caso, al menos hay que hacer tres cosas:

• Registrar el motivo por el que actualmente se necesita reiniciar
• Evaluar qué paquetes están implicados
• Acordar una hora de reinicio clara

Puedes revisar:

cat /var/run/reboot-required.pkgs
apt list --upgradable

Si es una actualización de seguridad del kernel, el riesgo de no reiniciar durante mucho tiempo será cada vez mayor. Puedes posponerlo unos días, pero no lo arrastres indefinidamente.

Algunas distribuciones o soluciones comerciales admiten live patching, que puede aplicar algunos parches de seguridad del kernel sin reiniciar. Pero no es una solución mágica y no puede sustituir todos los reinicios. Para VPS baratos normales, lo más fiable sigue siendo organizar una ventana de mantenimiento.

Si usas la familia RHEL, la idea es la misma, pero las herramientas son diferentes.

Comandos comunes:

sudo dnf update --security
sudo needs-restarting -r

needs-restarting suele venir de dnf-utils o del paquete de herramientas correspondiente. Puede determinar si se necesita reiniciar.

Para las actualizaciones automáticas programadas, revisa dnf-automatic:

sudo dnf install dnf-automatic
systemctl status dnf-automatic.timer

Las rutas de los archivos de configuración varían según la distribución, así que no apliques a la fuerza la configuración unattended-upgrades de Ubuntu en Rocky/AlmaLinux.

Si no quieres complicarte con un proceso complejo, puedes seguir esta configuración mínima:

Una vez por semana, en horario de bajo tráfico, ejecuta:

sudo apt update
sudo apt list --upgradable
sudo unattended-upgrade --dry-run --debug

Después de confirmar que no hay anomalías evidentes, deja que el sistema instale las actualizaciones de seguridad automáticamente, o ejecuta manualmente:

sudo unattended-upgrade

Si se necesita reiniciar:

test -f /var/run/reboot-required && cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Antes de reiniciar:

systemctl --failed
df -h
df -i

Después de reiniciar:

uptime
uname -r
systemctl --failed
curl -I https://example.com
journalctl -b -p err --no-pager

Por último, anota la fecha, los paquetes actualizados, si se reinició y si hubo anomalías. Aunque solo lo anotes en un archivo Markdown, es mejor que depender completamente de la memoria.

• Se confirmó si unattended-upgrades está instalado
• Se confirmó /etc/apt/apt.conf.d/20auto-upgrades
• Se revisaron apt-daily.timer y apt-daily-upgrade.timer
• Se revisaron los registros de /var/log/unattended-upgrades/
• El alcance de las actualizaciones automáticas solo cubre fuentes de software adecuadas
• Se revisó /var/run/reboot-required
• Se revisó /var/run/reboot-required.pkgs
• Se decidió si habilitar el reinicio automático
• Los VPS de producción tienen una ventana de mantenimiento fija
• Antes de reiniciar, se revisaron systemctl --failed, el disco y la memoria
• Se confirmó que Docker / Nginx / la base de datos arrancan al inicio
• Después de reiniciar, se revisaron los servicios, los puertos, los registros y el estado HTTP del sitio web
• Cada parche y reinicio tiene un registro sencillo

Lo que más preocupa de las actualizaciones de seguridad en VPS son dos extremos: uno es no actualizar nunca, y el otro es reiniciar automáticamente a ciegas. Un enfoque más fiable es usar la automatización para tareas repetitivas y de bajo riesgo, y poner los reinicios en una ventana de mantenimiento donde puedas ver cómo se recupera. Así no se retrasan los parches de vulnerabilidades durante meses, ni se reinicia el sitio web a medianoche y se queda caído sin que nadie lo sepa.