Actualizar un VPS Linux a Ubuntu 26.04 o Debian 13 sin romper producción

Ubuntu 26.04 LTS salió en abril de 2026 y, desde septiembre, la actualización desde 24.04 está abierta a todo el mundo. Debian 13 es la versión estable desde agosto de 2025, y Debian 12 ya solo lo mantiene el equipo LTS. Así puede llevar su VPS Linux a la nueva versión sin que una actualización se convierta en una caída de producción: situación actual, checklist, comandos y plan de vuelta atrás.

Dónde están Ubuntu y Debian en octubre de 2026

Datos de las notas de versión de Canonical y del calendario LTS de Debian:

Versión	Publicación	Soporte	Desde qué versión
Ubuntu 26.04 LTS (Resolute Raccoon)	23 de abril de 2026, point release 26.04.1 el 27 de agosto de 2026	5 años de actualizaciones estándar (abril de 2031), 10 años con ESM de Ubuntu Pro	solo 24.04 LTS o 25.10
Ubuntu 24.04 LTS	abril de 2024	soporte estándar hasta 2029	22.04 LTS
Debian 13 (trixie)	9 de agosto de 2025 (13.7 en septiembre de 2026)	equipo de seguridad hasta el 9 de agosto de 2028, luego LTS hasta el 30 de junio de 2030	solo Debian 12
Debian 12 (bookworm)	10 de junio de 2023	en LTS desde el 11 de junio de 2026, hasta el 30 de junio de 2028	Debian 11

Dos consecuencias prácticas:

Desde Ubuntu 22.04 no hay salto directo. Canonical lo deja claro: primero hay que pasar a 24.04 LTS (o 25.10) y después a 26.04. Cuente con dos actualizaciones, con reinicio y pruebas entre ambas.
Debian tampoco se salta versiones. Solo se admite la actualización desde la versión anterior: un servidor con Debian 11 pasa primero a 12 y luego a 13.

No hay prisa en un VPS con Ubuntu 24.04, cubierto hasta 2029. En cambio, un servidor con Debian 12 ya solo recibe correcciones del equipo LTS, con un alcance más limitado: planifique el paso a Debian 13 con calma, no con urgencia en 2028.

¿Actualización en el sitio o servidor nuevo?

Para un entorno de producción, la actualización en el sitio no siempre es la opción más segura. Tiene dos caminos:

Actualización en el sitio (do-release-upgrade o apt full-upgrade): rápida, conserva la IP y la configuración, pero el servicio se interrumpe durante la operación y volver atrás implica restaurar.
VPS nuevo con 26.04 o 13 y cambio posterior: migra los datos, prueba con calma y luego cambia el DNS. El servidor antiguo queda intacto y es su vuelta atrás inmediata.

Para un servidor sencillo, la actualización en el sitio basta si la preparación es seria. Con muchos repositorios externos o contenedores antiguos, una reinstalación limpia suele ser menos arriesgada.

La checklist antes de tocar producción

1. Un snapshot Y una copia de seguridad real

El snapshot del VPS, si su proveedor lo ofrece, es la forma más rápida de volver atrás: congela el disco entero. Pero se guarda en la misma infraestructura que el servidor y no sustituye a una copia de seguridad. Haga ambas cosas:

un snapshot justo antes de la operación, con los servicios o al menos las bases de datos detenidos, para obtener un estado coherente;
una copia externa de lo importante, fuera del servidor: volcados de bases de datos, /etc, directorios de los sitios, volúmenes Docker, crontabs.

# Como root (sudo -i), adáptelo a su instalación
mkdir -p /root/backup

# Volcados de bases de datos
mysqldump --all-databases --single-transaction > /root/backup/mysql-all.sql
su - postgres -c pg_dumpall > /root/backup/pg-all.sql

# Configuración y paquetes instalados
tar czf /root/backup/etc.tar.gz /etc
dpkg --get-selections '*' > /root/backup/paquetes.txt
apt-mark showmanual > /root/backup/paquetes-manuales.txt

Después copie /root/backup a otra máquina (rsync, almacenamiento de objetos, su propio ordenador). Una copia que nunca ha restaurado es solo una hipótesis: pruebe al menos un volcado.

2. Comprobar cgroup v2 (bloqueante para Ubuntu 26.04)

Es el cambio que más problemas está dando este año. systemd 259, incluido en Ubuntu 26.04, ya no admite cgroup v1 en absoluto (jerarquías legacy e híbrida). Según las notas de versión de Canonical:

una instalación de Ubuntu que funcione con cgroup v1 no podrá actualizarse a 26.04;
las cargas en contenedores de 26.04 no funcionan en un host arrancado con cgroup v1;
un host con 26.04 no admite contenedores que necesiten cgroup v1, por ejemplo imágenes de Ubuntu anteriores a 18.04.

Ubuntu y Debian usan cgroup v2 por defecto desde hace varias versiones, pero algunos servidores se forzaron a v1 para ejecutar contenedores antiguos, versiones viejas de Docker o agentes de monitorización. Compruebe:

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2, todo bien
# tmpfs      -> cgroup v1 o híbrido, corríjalo antes de actualizar

grep -o 'systemd.unified_cgroup_hierarchy=[0-9]' /proc/cmdline
grep -n 'cgroup' /etc/default/grub /etc/default/grub.d/* 2>/dev/null

Si queda un parámetro systemd.unified_cgroup_hierarchy=0 en la configuración de GRUB, elimínelo, ejecute sudo update-grub, reinicie y compruebe que sus contenedores siguen funcionando antes de actualizar. En Docker, liste contenedores e imágenes con docker ps -a y busque distribuciones muy antiguas: una imagen cuyo systemd interno es anterior a cgroup v2 hay que sustituirla, no rodearla, porque systemd 259 ya no puede arrancar con cgroup v1 y en 26.04 no existe ningún ajuste para volver a él.

En Debian 13, systemd 257 ya considera obsoleto cgroup v1: la misma comprobación le evitará sorpresas en la próxima actualización.

3. Inventariar los repositorios externos

Docker, PHP de un repositorio externo, Node.js, PPA varios: son ellos los que rompen las actualizaciones. Lístelos:

ls /etc/apt/sources.list.d/
grep -rhE '^(deb|URIs|Suites)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Para cada uno, compruebe que publica paquetes para la versión de destino (resolute para Ubuntu 26.04, trixie para Debian 13). El repositorio oficial de Docker, por ejemplo, admite Ubuntu 26.04 y Debian 13. do-release-upgrade desactiva los repositorios externos durante la operación; en Debian le toca a usted. En cualquier caso, anótelos para reactivarlos después.

4. Paquetes retenidos

apt-mark showhold

Un paquete esencial en estado hold hace fallar la actualización. Las notas de Debian recomiendan quitar las retenciones antes de empezar (sudo apt-mark unhold paquete), salvo para un paquete que haya recompilado usted mismo.

5. Espacio en disco, acceso de emergencia y franja de mantenimiento

Deje varios GB libres en / y revise /boot: df -h / /boot. En Debian, apt -o APT::Get::Trivial-Only=true full-upgrade calcula el espacio necesario una vez configuradas las nuevas fuentes.
Localice la consola de emergencia de su proveedor (consola VNC o equivalente en el área de cliente): es la que le salvará si la red no vuelve tras el reinicio.
Trabaje dentro de tmux o screen: si se corta la conexión SSH, la actualización sigue y puede volver a conectarse a la sesión.
Avise a sus usuarios, baje con antelación el TTL de sus registros DNS si piensa hacer un cambio de servidor y elija un momento tranquilo.

6. Escribir el plan de vuelta atrás

Decida antes de empezar, no durante: «si los servicios no han vuelto en X minutos, restauro el snapshot». Anote dónde está la restauración, cuánto tarda y qué pierde (todo lo escrito después del snapshot).

De Ubuntu 24.04 a 26.04, paso a paso

Desde la publicación de 26.04.1, la actualización se ofrece con normalidad: la opción -d, que servía para forzarla antes de la apertura oficial, ya no es necesaria.

# 1. Dejar 24.04 totalmente actualizado y reiniciar si se instaló un kernel nuevo
sudo apt update && sudo apt full-upgrade
sudo reboot

# 2. Comprobar la herramienta y la política de actualización
sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades   # debe mostrar Prompt=lts

# 3. Lanzar la actualización dentro de tmux
tmux new -s upgrade
sudo do-release-upgrade

Si la lanza por SSH, la herramienta propone abrir un segundo servicio SSH en otro puerto como respaldo; si acepta, abra ese puerto temporalmente en su cortafuegos. Ante las preguntas sobre archivos de configuración, conserve su versión en caso de duda y compárela después con el archivo .dpkg-dist.

Si parte de Ubuntu 22.04, el mismo comando le lleva a 24.04. Reinicie, revise sus servicios y vuelva a ejecutar do-release-upgrade para llegar a 26.04.

Qué cambia en un servidor Ubuntu 26.04

Kernel 7.0 y systemd 259; 26.04 es la última versión que admite scripts System V: migre a unidades systemd.
sudo-rs sustituye a sudo por defecto; el sudo original sigue disponible como sudo.ws. Pruebe scripts y playbooks que usen opciones de sudoers poco habituales.
rust-coreutils proporciona ahora las utilidades básicas. Canonical sigue ofreciendo las herramientas GNU para los casos incompatibles: pruebe sus scripts de shell.
/tmp en tmpfs por defecto: lo que había en /tmp ahora ocupa RAM y desaparece al reiniciar.
OpenSSH 10.2: las claves DSA ya no están soportadas.
Chrony es el servicio de hora en las instalaciones nuevas; en un servidor actualizado el cambio es manual (sudo apt-mark auto systemd-timesyncd y luego sudo apt install chrony).
Apache y mod_php: la unidad systemd de Apache activa MemoryDenyWriteExecute=yes, lo que rompe el JIT de PHP con libapache2-mod-php. Canonical recomienda pasar a php-fpm o, si no, anular la opción con sudo systemctl edit apache2.
PostgreSQL: Canonical señala una regresión de rendimiento con el kernel 7.0 y recomienda activar las huge pages.
Versiones: PHP 8.5, MySQL 8.4 LTS. Revise las notas de migración de sus aplicaciones.

De Debian 12 a Debian 13, paso a paso

Debian no tiene equivalente a do-release-upgrade: se cambian las fuentes de APT y se actualiza en dos fases.

# 1. Actualizar Debian 12 por completo (incluida la corrección de OpenSSH para actualizaciones remotas)
sudo apt update && sudo apt full-upgrade
sudo reboot

Las notas de versión advierten de que una sesión SSH interrumpida durante la actualización podía dejar el servidor inaccesible con el OpenSSH original de bookworm: asegúrese de tener al menos la versión 1:9.2p1-2+deb12u7 (dpkg -l openssh-server) y trabaje en tmux.

Después, pase las fuentes al formato deb822 recomendado por Debian 13: un único archivo /etc/apt/sources.list.d/debian.sources, retirando el antiguo /etc/apt/sources.list.

sudo mv /etc/apt/sources.list /root/backup/sources.list.bookworm
sudo tee /etc/apt/sources.list.d/debian.sources <<'EOF'
Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF

Añada contrib o non-free a la línea Components si su configuración anterior los usaba. Desactive los repositorios externos (renombre sus archivos a .disabled) y elimine las entradas bookworm-backports-sloppy, para las que Debian no prevé una ruta de actualización limpia.

# 2. Actualización mínima y luego completa
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

Antes de reiniciar, compruebe el nombre de su interfaz de red: el paso a systemd 257 puede cambiar el nombre generado para algunas tarjetas, y un VPS cuya interfaz cambia de nombre arranca sin red. Las notas de versión indican el comando que hay que ejecutar justo antes del reinicio:

ip -br link
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Sustituya eth0 por el nombre que muestra ip -br link. Si ID_NET_NAME difiere del nombre actual, adapte /etc/network/interfaces o fije el nombre con un archivo .link de systemd antes de reiniciar. Compruebe también que hay un metapaquete de kernel instalado (dpkg -l 'linux-image*' | grep ^ii | grep -i meta).

Tras el reinicio, haga limpieza y convierta las fuentes restantes:

sudo apt modernize-sources   # convierte los archivos .list restantes a deb822
sudo apt autoremove
apt list '?obsolete'          # paquetes que ya no vienen de ningún repositorio

Debian 13 indica además que las rutas de llaveros en .gpg son ya solo enlaces de compatibilidad hacia los archivos .pgp: una vez terminada la actualización, puede sustituir debian-archive-keyring.gpg por debian-archive-keyring.pgp en sus fuentes.

Qué cambia en un servidor Debian 13

Kernel 6.12, OpenSSH 10.0 (sin claves DSA), OpenSSL 3.5, PHP 8.4, PostgreSQL 17, MariaDB 11.8, Nginx 1.26, Python 3.13.
/tmp pasa a tmpfs (hasta el 50 % de la RAM por defecto), y /tmp y /var/tmp se limpian periódicamente: un servicio que guarde ahí archivos duraderos debe moverse.
i386 deja de ser una arquitectura completa: no actualice un servidor de 32 bits.

Tras el reinicio: las comprobaciones

lsb_release -a               # ¿versión correcta?
systemctl --failed           # ¿ningún servicio fallido?
journalctl -p err -b         # errores desde el arranque
ss -tlnp                     # ¿escuchan los puertos esperados?
stat -fc %T /sys/fs/cgroup/  # cgroup2fs
docker ps -a                 # ¿contenedores levantados?

Reactive después los repositorios externos con el nombre de la nueva versión. Para Docker suele bastar con poner Suites: resolute (Ubuntu 26.04) o Suites: trixie (Debian 13) en /etc/apt/sources.list.d/docker.sources y ejecutar sudo apt update && sudo apt full-upgrade. Por último, pruebe sus sitios y API desde fuera, las tareas cron, las copias automáticas y la renovación de certificados (sudo certbot renew --dry-run si usa Certbot).

Si algo se rompe: la vuelta atrás

El servidor no responde: use la consola de emergencia del proveedor. La causa más habitual es la red (nombre de interfaz, Netplan) o el cortafuegos.
Un servicio no arranca: journalctl -u servicio -b casi siempre da el motivo (opción de configuración eliminada, módulo PHP ausente, versión de la base de datos).
No se ha resuelto en el plazo que se fijó: restaure el snapshot, vuelva a poner el servicio en línea y analice con calma sobre una copia. No existe un «downgrade» limpio de una distribución: volver atrás significa snapshot o copia de seguridad.

Preguntas frecuentes

¿Se puede pasar directamente de Ubuntu 22.04 a 26.04?

No. Canonical exige pasar antes por 24.04 LTS (o 25.10). En un servidor, haga dos actualizaciones sucesivas con pruebas entre ambas.

¿Por qué do-release-upgrade dice que no hay ninguna versión nueva?

Compruebe Prompt=lts en /etc/update-manager/release-upgrades y que 24.04 esté totalmente actualizado. Tenga en cuenta además que un sistema con cgroup v1 no puede actualizarse a 26.04: pase antes a cgroup v2.

¿Sigue siendo seguro Debian 12 en producción?

Recibe correcciones de seguridad del equipo LTS hasta el 30 de junio de 2028, pero para un conjunto de paquetes más reducido. Sigue siendo utilizable, pero planifique el paso a Debian 13.

¿Funcionarán mis contenedores Docker antiguos en Ubuntu 26.04?

Los que necesitan cgroup v1, como las imágenes de Ubuntu anteriores a 18.04, no. Actualice esas imágenes antes de la actualización, en un servidor de pruebas si es posible.