Pregunta a quien lleva tu clúster de Proxmox quién decidió pasar de 9.1 a 9.2 y en qué reunión se aprobó. La respuesta honesta, en la mayoría de sitios, es que nadie lo decidió: se aplicaron los parches de un martes cualquiera y el número cambió solo. No es un descuido de tu equipo. Es cómo están montados los repositorios.
Llevamos Proxmox VE en producción desde las ramas 3.x y operamos clústeres con almacenamiento Ceph repartidos en varios datacenters. Hacemos copias con Proxmox Backup Server y con Veeam según el caso. Y hay una cosa que hemos visto morder a gente que lo hace todo bien: mantener el hipervisor al día y mantener el software de copias al día son dos relojes que no están sincronizados, y solo uno de los dos corre solo.
En Proxmox no existe una rama «9.1 con parches»
Quien viene de vSphere trae un reflejo incorporado: eliges un build, te quedas en él y aplicas parches dentro de ese build. La versión del hipervisor es una decisión que se toma una vez y se sostiene durante meses.
Proxmox no funciona así. Los repositorios están organizados por versión mayor: pve-enterprise y pve-no-subscription apuntan a trixie para toda la rama 9, y las versiones menores son, sencillamente, el estado del repositorio en un momento dado. No hay nada parecido a un pve-9.1-security. El único componente que Proxmox sí publica con repositorio propio por release es Ceph —hoy conviven ceph-squid y ceph-tentacle—, precisamente porque va en su calendario aparte.
La consecuencia es la que importa: la pregunta «¿subimos a 9.2?» nunca llega a formularse. Un apt dist-upgrade rutinario, el mismo que aplica los parches de seguridad que sí quieres, te deja en la última versión menor publicada. La decisión no se toma: se hereda del calendario de parcheo. Y la alternativa —dejar de actualizar para quedarte donde estás— es claramente peor.
En agosto contamos el caso contrario, el de Proxmox VE 8 caducando sin que apt lo dijera: ahí el gestor de paquetes se callaba que el soporte se había acabado. Este es el simétrico. Aquí apt no se calla nada: hace exactamente su trabajo, y al hacerlo te mueve a una versión que la pieza de al lado todavía no cubre.
Las fechas, puestas en fila
- ·21 de mayo de 2026 — Proxmox publica Virtual Environment 9.2.
- ·29 de julio de 2026 — Veeam publica el Plug-in for Proxmox VE 4.0 (build 13.4.0.300), el que acompaña a Backup & Replication 13.1. Esa rama es la que publica el rango que incluye 9.2; la 13.0 publicaba 8.2–9.1.
- ·5 de agosto de 2026 — sale la variante arm64 de 9.2, la primera de Proxmox para una arquitectura distinta de x86-64.
- ·25 de agosto de 2026 — Veeam publica el Plug-in 3.3 (build 13.3.3.23), el de Backup & Replication 13.0.3. Es decir: la rama antigua recibe una actualización veintisiete días después de que saliera la nueva.
Entre la primera línea y la segunda hay 69 días. Ese número no es una queja: certificar una versión menor de un hipervisor ajeno en diez semanas nos parece un plazo razonable, y nadie sensato querría que fuera más rápido a costa de probar menos. El problema no es el plazo. El problema es que el otro lado no tiene freno: mientras el fabricante de copias se toma diez semanas prudentes, tu repositorio no espera a nadie.
Dónde estás hoy, 30 de septiembre
Hay que decirlo claro, porque si no este post parece una alarma y no lo es: ese hueco concreto ya está cerrado. La guía de soporte de plataformas vigente publica hoy el rango 8.2–9.2, y lo cubre la rama 13.1. Si estás ahí, estás dentro.
El caso vivo es otro, y es el que conviene mirar esta semana: si sigues en la rama 13.0 y tus nodos ya derivaron a 9.2. Esa combinación es perfectamente plausible en una empresa ordenada —no has saltado de versión mayor del producto de copias porque no tocaba, y has aplicado los parches del hipervisor porque sí tocaba—, y es justo la que hay que comprobar contra la matriz de tu rama, que no es la misma página que la de la rama nueva. Nosotros no vamos a afirmar aquí en qué lado cae tu instalación: ese dato lo tiene tu consola, no este post.
Y el hueco de 69 días no fue el último. Habrá otro con la 9.3, y otro con la que venga detrás, porque el mecanismo que lo produce no ha cambiado: un lado publica cuando está listo y el otro cuando ha terminado de probar.
Lo incómodo: no salta ninguna alerta
Quedarse fuera de una matriz de soporte no dispara un aviso, no cambia un icono y no manda un correo. Las copias de esa noche se hacen y el trabajo termina bien. Lo que has perdido no es la copia: es el derecho a abrir un caso. «Configuración no soportada» es una frase que solo escucharás el día que llames, y el día que llamas es exactamente el día en que no quieres tener esa conversación.
El 24 de septiembre escribimos sobre un trabajo de copia que se salta discos y aun así termina bien. Aquello era un fallo de alcance dentro del trabajo; esto no es un fallo de nada. Es un cambio de estado contractual que ocurre en silencio mientras todo funciona, y por eso es más difícil de ver.
Tres datos en el mismo sitio, antes de abrir la ventana
No hace falta un procedimiento nuevo. Hace falta que tres cosas vivan juntas en la misma línea, en el mismo documento, con la misma fecha al lado — y que esa línea se mire antes de tocar el primer nodo, no después:
- 1La versión que corre hoy en los nodos.
pveversion -ven cada uno, no solo en el que tienes abierto. En un clúster que se actualiza nodo a nodo, la respuesta pueden ser dos números distintos, y esa situación transitoria a veces dura semanas. - 2La versión y el build del software de copias, con su rama. No «Veeam 13», sino el build entero: es lo que te dice en qué rama estás y, por tanto, qué página de matriz te aplica. La rama 13.1, por ejemplo, empezó en 13.1.0.411 el 29 de julio y ha seguido moviéndose desde entonces.
- 3La fecha en que alguien miró la matriz del fabricante y el rango que leyó, copiado tal cual. Si esa fecha tiene más de un trimestre, lo que tienes no es un dato: es un recuerdo.
El orden correcto de la ventana se cae solo de ahí: primero la matriz, después el apt. Si el fabricante todavía no cubre la versión a la que te va a llevar el repositorio, eso no significa automáticamente aplazar los parches —a veces significa subir primero la consola de copias, y a veces significa asumir la ventana con los ojos abiertos y dejarlo escrito—. Significa que alguien lo ha decidido, que es exactamente lo contrario de lo que pasa hoy.
La versión no es la única casilla: la arquitectura también
La misma página de soporte que publica el rango de versiones añade una frase que se lee en dos segundos y decide compras: las máquinas con arquitectura de CPU ARM no están soportadas. Es decir, el nodo arm64 que puedas plantearte el mes que viene nace fuera de matriz, y no por deriva de versión sino por arquitectura. Ya contamos que la variante arm64 no amplía tu clúster, te obliga a llevar dos; esto es la misma frontera vista desde el lado de las copias.
Y el mecanismo es general, no exclusivo de las copias. Cada pieza que se integra con el hipervisor por su API —el agente de monitorización, el plug-in de la cabina, el conector del orquestador— trae su propia matriz, y cada matriz añade una restricción a tu calendario. Nadie las suma. No hay un sitio donde se vea la intersección. Es el mismo problema de fondo que contamos con el ciclo de vida de Kubernetes, solo que del revés: allí el calendario es explícito y brutal, y por eso se planifica; aquí es implícito y suave, y por eso se ignora.
Dónde esta grieta no existe
Si tus copias las hace Proxmox Backup Server y nada más, puedes cerrar el post. Ojo, no porque PBS no tenga matriz: la tiene, y está publicada —Proxmox prueba la versión mayor actual y la anterior, y a dos releases de distancia declara soporte «best effort»—. La diferencia es que su matriz va por versión mayor, así que un salto de 9.1 a 9.2 no te mueve de casilla. La grieta de este post, la de las menores, ahí no se abre.
Lo que no se deduce de aquí es «quita Veeam». Si ya lo tienes por el resto del parque —físicos, Microsoft 365, lo que sea—, tener las dos vías es 3-2-1 de verdad y no un eslogan. La recomendación honesta no es cambiar de producto: es saber cuál de las dos vías te salva si la otra queda fuera de matriz, y haber restaurado alguna vez desde ella.
Los límites de lo que acabamos de decir
Las matrices se mueven, y un post no es fuente de verdad para ellas: los rangos que citamos son los que estaban publicados el 30 de septiembre de 2026, y la página que manda es la de tu producto y tu rama, leída el día de tu ventana. Tampoco decimos que las copias fallen fuera de matriz —casi siempre siguen funcionando—; decimos que «funciona» y «está soportado» son afirmaciones distintas y que la diferencia solo se nota el día malo.
Y no es un reproche al fabricante de copias. Certificar tarda, mantener dos ramas vivas a la vez es lo correcto con una base instalada, y publicar una actualización de la rama antigua un mes después de estrenar la nueva es buena práctica, no descuido. La asimetría la pone el otro lado: uno de los dos calendarios tiene freno y el otro no.
El conflicto de interés, por delante: esto describe trabajo que facturamos. Llevar el inventario de versiones de una plataforma y mirar matrices antes de cada ventana es, literalmente, mantenimiento gestionado. Si en tu empresa ya hay alguien con esas tres líneas escritas y fechadas, no nos necesitas para esto.
Fuentes (verificadas el 30 de septiembre de 2026): la fecha de publicación de Proxmox VE 9.2 y sus novedades — nota de prensa de Proxmox Server Solutions y Roadmap de Proxmox VE; la variante arm64 del 5 de agosto de 2026 — descargas de Proxmox; la organización de los repositorios por versión mayor y los de Ceph por release — Package Repositories, wiki de Proxmox VE; las versiones, builds y fechas del plug-in de Veeam para Proxmox VE (4.0 / 13.4.0.300 el 29-07-2026 con B&R 13.1; 3.3 / 13.3.3.23 el 25-08-2026 con B&R 13.0.3) — Veeam KB4706; el rango de versiones soportadas y la frase sobre arquitectura ARM — guía de soporte de plataformas de Veeam Backup & Replication, que es la página a consultar antes de cada ventana; las combinaciones soportadas entre Proxmox VE y Proxmox Backup Server y el «best effort» a dos releases — Roadmap de Proxmox Backup Server.
¿Quién mira la matriz antes de tu ventana de parches?
Si la respuesta es «el que esté libre esa noche», no es un reproche: es que falta a quién le toca. Llevamos el inventario de versiones de tu plataforma, miramos las matrices antes de cada ventana y respondemos cuando algo sale mal a las tres de la madrugada — es nuestro soporte IT 24×7. Y si estás llegando a Proxmox desde vSphere, este reflejo es de los primeros que hay que cambiar: lo trabajamos dentro de la migración de VMware a Proxmox.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN