Dónde estamos desde el 31 de agosto de 2026
Debian ofreció dos años de soporte a largo plazo para Debian 11 (bullseye), hasta el 31 de agosto de 2026. Esa fecha ya pasó: el proyecto Debian ya no publica correcciones de seguridad para esta versión. Plesk ha alineado su calendario: el anuncio del 15 de octubre de 2026 indica que Plesk Obsidian 18.0.81 es la última versión que admite Debian 11, y que el servidor puede actualizarse a Debian 12 con la herramienta de dist-upgrade de Plesk, o sustituirse por un servidor con un sistema soportado, al que se migran los dominios.
En la práctica, un servidor con Debian 11 sigue funcionando y sirviendo sus sitios. Pero no recibirá ninguna actualización de Plesk más allá de la 18.0.81 ni más correcciones de seguridad del sistema. El riesgo no se ve: crece en silencio, hasta que se publique el primer fallo contra un paquete que nadie corregirá.
Qué implica seguir en Debian 11
- Sin más correcciones de Debian — el soporte a largo plazo del proyecto terminó el 31 de agosto de 2026; los fallos descubiertos después quedan abiertos.
- Plesk congelado — las versiones 18.0.82 y posteriores no se instalan ni se actualizan en Debian 11.
- Soporte de pago de terceros posible, pero ajeno a Debian — hay proveedores que ofrecen seguridad extendida hasta el 30 de junio de 2031; no es un servicio del proyecto Debian, y el anuncio de Plesk no menciona que admita ese esquema.
- Integraciones que se quedan atrás — Plesk prevé retirar en la versión 18.0.82 las versiones del protocolo XML-RPC anteriores a 1.6.9.1; una integración de facturación o gestión que dependa de una versión anterior dejará de responder.
- Una deuda que crece — cuanto más se espera, mayor es la distancia con la versión de destino y más cara resulta la intervención el día en que se vuelve urgente.
Dist-upgrade o migración: el criterio de decisión
La documentación de Plesk presenta dos formas de actualizar el sistema de un servidor: migrar a un servidor que ya funcione con un SO más reciente mediante Plesk Migrator, o hacer un dist-upgrade en el sitio. Recomienda la migración, porque el dist-upgrade no es un proceso sencillo: exige una sólida experiencia en administración de sistemas y conocimiento de los componentes del SO. También desaconseja combinarlo con actualizaciones de Plesk, que por tanto deben hacerse antes.
La regla práctica que se deduce: migre por defecto los servidores críticos o cargados de módulos de terceros, y reserve el dist-upgrade para máquinas sencillas, bien respaldadas, que pueda clonar y probar antes. El dist-upgrade impone un corte total de Plesk, de los sitios y del correo durante toda la conversión; la migración deja el servidor antiguo en servicio hasta el cambio.
Dist-upgrade en el sitio o migración a un servidor nuevo
Desplace la tabla
| Criterio | Dist-upgrade (herramienta Plesk) | Migración (Plesk Migrator) |
|---|---|---|
| Recomendación de Plesk | Posible, pero no es un proceso sencillo | Vía recomendada |
| Indisponibilidad | Plesk, sitios y correo cortados durante toda la conversión, 20 a 30 minutos anunciados | El servidor antiguo sigue en línea hasta el cambio |
| Reinicios | Tres, con reanudación automática por el servicio plesk-dist-upgrader | Ninguno en el servidor de origen |
| Vuelta atrás | Snapshot y copia de seguridad; la opción de reversión de la herramienta solo cubre el tramo anterior a la actualización de paquetes | El servidor antiguo queda intacto mientras no lo apague |
| Requisitos | Plesk al día, 5 GB libres, 2 GB de RAM, módulo Remote management, fuera de un contenedor | Un servidor nuevo con un SO soportado y una transferencia de datos |
| Indicado para | Un servidor sencillo que pueda clonar y probar | Un servidor crítico, módulos de terceros, o un SO que hay que renovar de todos modos |
Inventariar el parque antes de decidir
Antes de elegir una vía hay que saber en qué punto está cada servidor. En cada máquina, cat /etc/os-release da la versión del sistema: un VERSION_ID de 11 señala un servidor afectado. plesk -v muestra la versión de Plesk instalada, plesk installer list las versiones disponibles para instalar y apt list --upgradable los paquetes pendientes de actualización. Anote los resultados en una tabla del parque, con el cliente, el papel del servidor, los módulos de terceros instalados y la fecha de la última copia de seguridad.
Ordene después por criticidad. Empiece por una máquina de pruebas o de poco riesgo para validar el procedimiento, y trate luego los servidores por orden creciente de importancia, avisando a los clientes del corte antes de cada intervención. Compruebe también que el servidor no sea un contenedor: la herramienta no se aplica allí, y solo su proveedor puede confirmar el tipo de entorno.
Preparar el dist-upgrade a Debian 12
Comprobar la elegibilidad
La herramienta de Plesk para pasar de Debian 11 a Debian 12 exige Plesk Obsidian 18.0.57 o superior. Compruébelo con
plesk -v. Verifique 5 GB de disco libre y 2 GB de RAM, y que el servidor no sea un contenedor Virtuozzo ni Docker.Actualizar Plesk primero
Lleve Plesk a la última versión disponible antes de tocar el SO: Plesk desaconseja combinar el dist-upgrade con actualizaciones de Plesk. Revise los paquetes pendientes con
apt list --upgradable.Instalar el módulo Remote management
La herramienta exige que el módulo Remote management esté instalado: sin él, puede perder el acceso al servidor si el servicio SSH no se reinicia durante la conversión.
Respaldar y luego crear un snapshot
Haga una copia de seguridad completa del servidor, bases de datos incluidas, y luego un snapshot en el hipervisor o en su proveedor. El snapshot es su verdadera vuelta atrás: la opción de reversión de la herramienta puede fallar ella misma.
Probar en un clon
Si nunca ha hecho un dist-upgrade, restaure el snapshot en una máquina de pruebas y ejecute allí todo el procedimiento. Verá los bloqueos, la duración real y el comportamiento de sus módulos de terceros antes de arriesgar la producción.
Anunciar el corte
Avise a los clientes: Plesk, los sitios alojados y el correo no están disponibles durante toda la conversión, que la página de la herramienta estima entre 20 y 30 minutos. Elija una ventana tranquila y deje margen, porque la duración depende del servidor.
Lanzar la conversión y seguirla
Conéctese como root, descargue la herramienta desde la página de versiones del repositorio plesk/debian11to12 y hágala ejecutable. La página del repositorio da el ejemplo wget https://github.com/plesk/debian11to12/releases/download/v1.0.7/debian11to12-1.0.7.zip, luego unzip debian11to12-1.0.7.zip y chmod 755 debian11to12; revise la lista de versiones para tomar la más reciente. Después ejecute la herramienta dentro de una sesión screen, para que un corte de SSH no interrumpa la conversión: screen -S debian11to12, luego ./debian11to12. Para recuperar la sesión tras una desconexión, screen -r debian11to12. Antes de lanzar, ./debian11to12 --show-plan muestra las etapas previstas.
Seguir y reanudar una conversión
Vigilar el avance
Desde otra sesión,
./debian11to12 --statusda el estado y./debian11to12 --monitorabre un seguimiento en directo. El registro se escribe en/var/log/plesk/debian11to12.log.Esperar los tres reinicios
La conversión requiere tres reinicios. Tras el primero, el servicio systemd plesk-dist-upgrader retoma el trabajo por sí solo. Puede comprobar su estado con
systemctl status plesk-dist-upgradery leer sus mensajes conjournalctl -u plesk-dist-upgrader.Relanzar si el proceso se interrumpe
Si la interrupción ocurrió antes del primer reinicio, relance con la opción
--resume. Si ocurre después, ejecutesystemctl restart plesk-dist-upgrader.Revertir si el fallo es temprano
Si la conversión falla durante la fase de preparación, antes de la actualización de paquetes, la opción
--revertrestablece Plesk. Pasado ese punto ya no puede deshacer los cambios: el snapshot toma el relevo.Verificar el mensaje final
Al terminar, un mensaje de la herramienta indica que el servidor se ha actualizado a Debian 12; puede retirarlo de
/etc/motd. Compruebe despuéscat /etc/os-release,plesk -v, que el panel abre, algunos sitios, el envío y la recepción de un correo, y las copias de seguridad programadas.
Módulos de terceros y protección del servidor: verificar antes, no después
La página del repositorio de la herramienta no menciona Imunify360 ni ningún otro módulo de seguridad de terceros. Ese silencio no es luz verde ni roja: antes de convertir un servidor que lleve uno, pregunte al proveedor de cada módulo si admite Debian 12 con su versión de Plesk, y pruebe en el clon. Haga la misma comprobación con las extensiones de Plesk, las tareas programadas personalizadas y las reglas del cortafuegos.
Resolver una conversión que se bloquea
El caso mejor documentado afecta a los discos múltiples. Con la versión 1.0.7 de la herramienta, un servidor BIOS con RAID por software puede detenerse durante la preparación con el mensaje Grub's install-device is not found: /dev/sda, /dev/sdb, aunque ambos discos existan: la comprobación lee la lista de dispositivos separados por comas como una sola ruta. El repositorio indica que la corrección está en el código fuente pero no en el archivo de la versión 1.0.7; use una versión o compilación que la incluya. Para distinguir este falso positivo de un disco realmente ausente, inspeccione el sistema sin iniciar la conversión con debconf-show grub-pc y lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT.
El repositorio advierte además: no elimine un destino GRUB válido ni eluda la comprobación solo para que pase. Si un dispositivo configurado falta de verdad, corrija primero la configuración de arranque. Para cualquier otro bloqueo, ./debian11to12 --prepare-feedback genera un archivo para adjuntar a un ticket de GitHub.
Elegir la migración: qué cambia para el parque
Migrar a un servidor nuevo equivale a construir una máquina sana y trasladar a ella los dominios con Plesk Migrator. Se gana un sistema limpio, un servidor antiguo intacto hasta el cambio y una vuelta atrás trivial. Se pierde tiempo de preparación: un servidor que aprovisionar, una transferencia de datos, un cambio de DNS que planificar, y certificados y buzones de correo que revisar tras el cambio. Para un servidor crítico, ese coste suele ser menor que el riesgo de un corte sin salida de emergencia.
Para una agencia: un proyecto de parque, no de servidor
Para una agencia que lleva varios servidores Plesk, la actualización del SO es un proyecto de parque: tres reinicios por máquina, ventanas de corte que negociar cliente a cliente y módulos de terceros que validar uno a uno. Una alternativa es confiar la infraestructura a un proveedor que la mantenga por usted: usted conserva la relación con el cliente, nosotros mantenemos la infraestructura. Si sus servidores también necesitan licencias Plesk, la página de licencias Plesk detalla lo disponible. La administración de servidores sigue siendo una opción aparte, nunca incluida por defecto.
La documentación oficial
Anuncio de Plesk Obsidian 18.0.81: https://www.plesk.com/blog/plesk-news-announcements/plesk-obsidian-18-0-81-is-now-available/
Página de la versión Debian 11 (bullseye): https://www.debian.org/releases/bullseye/
Procedimiento de dist-upgrade de Plesk: https://support.plesk.com/hc/en-us/articles/12377714344983
Herramienta de conversión de Debian 11 a 12: https://github.com/plesk/debian11to12
La página de documentación de Plesk sobre el soporte de dist-upgrade expone la recomendación de migrar: https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/dist-upgrade-support.74627/
