Pregunta a qui porta el teu clúster de Proxmox qui va decidir passar de la 9.1 a la 9.2 i en quina reunió es va aprovar. La resposta honesta, a la majoria de llocs, és que ningú ho va decidir: es van aplicar els pedaços d'un dimarts qualsevol i el número va canviar sol. No és cap descuit del teu equip. És com estan muntats els repositoris.
Portem Proxmox VE en producció des de les branques 3.x i operem clústers amb emmagatzematge Ceph repartits en diversos datacenters. Fem còpies amb Proxmox Backup Server i amb Veeam segons el cas. I hi ha una cosa que hem vist mossegar gent que ho fa tot bé: mantenir l'hipervisor al dia i mantenir el programari de còpies al dia són dos rellotges que no estan sincronitzats, i només un dels dos corre sol.
A Proxmox no existeix una branca «9.1 amb pedaços»
Qui ve de vSphere porta un reflex incorporat: tries un build, t'hi quedes i apliques pedaços dins d'aquell build. La versió de l'hipervisor és una decisió que es pren una vegada i se sosté durant mesos.
Proxmox no funciona així. Els repositoris estan organitzats per versió major: pve-enterprise i pve-no-subscription apunten a trixie per a tota la branca 9, i les versions menors són, senzillament, l'estat del repositori en un moment donat. No hi ha res semblant a un pve-9.1-security. L'únic component que Proxmox sí que publica amb repositori propi per release és Ceph —avui conviuen ceph-squid i ceph-tentacle—, precisament perquè va en el seu calendari a part.
La conseqüència és la que importa: la pregunta «pugem a la 9.2?» no arriba mai a formular-se. Un apt dist-upgrade rutinari, el mateix que aplica els pedaços de seguretat que sí que vols, et deixa a l'última versió menor publicada. La decisió no es pren: s'hereta del calendari de pedaços. I l'alternativa —deixar d'actualitzar per quedar-te on ets— és clarament pitjor.
A l'agost vam explicar el cas contrari, el del Proxmox VE 8 caducant sense que l'apt ho digués: allà el gestor de paquets es callava que el suport s'havia acabat. Aquest és el simètric. Aquí l'apt no es calla res: fa exactament la seva feina, i en fer-la et mou a una versió que la peça del costat encara no cobreix.
Les dates, posades en fila
- ·21 de maig del 2026 — Proxmox publica Virtual Environment 9.2.
- ·29 de juliol del 2026 — Veeam publica el Plug-in for Proxmox VE 4.0 (build 13.4.0.300), el que acompanya el Backup & Replication 13.1. Aquella branca és la que publica el rang que inclou la 9.2; la 13.0 publicava 8.2–9.1.
- ·5 d'agost del 2026 — surt la variant arm64 de la 9.2, la primera de Proxmox per a una arquitectura diferent de l'x86-64.
- ·25 d'agost del 2026 — Veeam publica el Plug-in 3.3 (build 13.3.3.23), el del Backup & Replication 13.0.3. És a dir: la branca antiga rep una actualització vint-i-set dies després que sortís la nova.
Entre la primera línia i la segona hi ha 69 dies. Aquest número no és una queixa: certificar una versió menor d'un hipervisor aliè en deu setmanes ens sembla un termini raonable, i ningú amb seny voldria que fos més ràpid a canvi de provar menys. El problema no és el termini. El problema és que l'altre costat no té fre: mentre el fabricant de còpies es pren deu setmanes prudents, el teu repositori no espera ningú.
On ets avui, 30 de setembre
Cal dir-ho clar, perquè si no aquest post sembla una alarma i no ho és: aquell buit concret ja està tancat. La guia de suport de plataformes vigent publica avui el rang 8.2–9.2, i el cobreix la branca 13.1. Si hi ets, ets a dins.
El cas viu és un altre, i és el que convé mirar aquesta setmana: si continues a la branca 13.0 i els teus nodes ja van derivar a la 9.2. Aquella combinació és perfectament plausible en una empresa ordenada —no has saltat de versió major del producte de còpies perquè no tocava, i has aplicat els pedaços de l'hipervisor perquè sí que tocava—, i és justament la que cal comprovar contra la matriu de la teva branca, que no és la mateixa pàgina que la de la branca nova. Nosaltres no afirmarem aquí a quin costat cau la teva instal·lació: aquesta dada la té la teva consola, no aquest post.
I el buit de 69 dies no va ser l'últim. N'hi haurà un altre amb la 9.3, i un altre amb la que vingui darrere, perquè el mecanisme que el produeix no ha canviat: un costat publica quan està llest i l'altre quan ha acabat de provar.
L'incòmode: no salta cap alerta
Quedar-se fora d'una matriu de suport no dispara cap avís, no canvia cap icona i no envia cap correu. Les còpies d'aquella nit es fan i la tasca acaba bé. El que has perdut no és la còpia: és el dret a obrir un cas. «Configuració no suportada» és una frase que només sentiràs el dia que truquis, i el dia que truques és exactament el dia en què no vols tenir aquella conversa.
El 24 de setembre vam escriure sobre una tasca de còpia que se salta discos i tot i així acaba bé. Allò era una fallada d'abast dins de la tasca; això no és cap fallada de res. És un canvi d'estat contractual que passa en silenci mentre tot funciona, i per això és més difícil de veure.
Tres dades al mateix lloc, abans d'obrir la finestra
No cal cap procediment nou. Cal que tres coses visquin juntes a la mateixa línia, al mateix document, amb la mateixa data al costat — i que aquella línia es miri abans de tocar el primer node, no després:
- 1La versió que corre avui als nodes.
pveversion -va cadascun, no només al que tens obert. En un clúster que s'actualitza node a node, la resposta poden ser dos números diferents, i aquella situació transitòria de vegades dura setmanes. - 2La versió i el build del programari de còpies, amb la seva branca. No «Veeam 13», sinó el build sencer: és el que et diu en quina branca ets i, per tant, quina pàgina de matriu t'aplica. La branca 13.1, per exemple, va començar amb la 13.1.0.411 el 29 de juliol i ha continuat movent-se des de llavors.
- 3La data en què algú va mirar la matriu del fabricant i el rang que va llegir, copiat tal qual. Si aquella data té més d'un trimestre, el que tens no és una dada: és un record.
L'ordre correcte de la finestra es desprèn sol d'aquí: primer la matriu, després l'apt. Si el fabricant encara no cobreix la versió a la qual et portarà el repositori, això no vol dir automàticament ajornar els pedaços —de vegades vol dir pujar primer la consola de còpies, i de vegades vol dir assumir la finestra amb els ulls oberts i deixar-ho escrit—. Vol dir que algú ho ha decidit, que és exactament el contrari del que passa avui.
La versió no és l'única casella: l'arquitectura també
La mateixa pàgina de suport que publica el rang de versions afegeix una frase que es llegeix en dos segons i decideix compres: les màquines amb arquitectura de CPU ARM no estan suportades. És a dir, el node arm64 que et puguis plantejar el mes que ve neix fora de matriu, i no per deriva de versió sinó per arquitectura. Ja vam explicar que la variant arm64 no amplia el teu clúster, t'obliga a portar-ne dos; això és la mateixa frontera vista des del costat de les còpies.
I el mecanisme és general, no exclusiu de les còpies. Cada peça que s'integra amb l'hipervisor per la seva API —l'agent de monitoratge, el plug-in de la cabina, el connector de l'orquestrador— porta la seva pròpia matriu, i cada matriu afegeix una restricció al teu calendari. Ningú no les suma. No hi ha cap lloc on es vegi la intersecció. És el mateix problema de fons que vam explicar amb el cicle de vida de Kubernetes, només que del revés: allà el calendari és explícit i brutal, i per això es planifica; aquí és implícit i suau, i per això s'ignora.
On aquesta escletxa no existeix
Si les teves còpies les fa Proxmox Backup Server i res més, pots tancar el post. Compte, no perquè el PBS no tingui matriu: la té, i està publicada —Proxmox prova la versió major actual i l'anterior, i a dues releases de distància declara suport «best effort»—. La diferència és que la seva matriu va per versió major, així que un salt de la 9.1 a la 9.2 no et mou de casella. L'escletxa d'aquest post, la de les menors, allà no s'obre.
El que no es dedueix d'aquí és «treu el Veeam». Si ja el tens per a la resta del parc —físics, Microsoft 365, el que sigui—, tenir les dues vies és 3-2-1 de debò i no un eslògan. La recomanació honesta no és canviar de producte: és saber quina de les dues vies et salva si l'altra queda fora de matriu, i haver restaurat alguna vegada des d'ella.
Els límits del que acabem de dir
Les matrius es mouen, i un post no és font de veritat per a elles: els rangs que citem són els que estaven publicats el 30 de setembre del 2026, i la pàgina que mana és la del teu producte i la teva branca, llegida el dia de la teva finestra. Tampoc no diem que les còpies fallin fora de matriu —gairebé sempre continuen funcionant—; diem que «funciona» i «està suportat» són afirmacions diferents i que la diferència només es nota el dia dolent.
I no és cap retret al fabricant de còpies. Certificar triga, mantenir dues branques vives alhora és el correcte amb una base instal·lada, i publicar una actualització de la branca antiga un mes després d'estrenar la nova és bona pràctica, no descuit. L'asimetria la posa l'altre costat: un dels dos calendaris té fre i l'altre no.
El conflicte d'interès, per davant: això descriu feina que facturem. Portar l'inventari de versions d'una plataforma i mirar matrius abans de cada finestra és, literalment, manteniment gestionat. Si a la teva empresa ja hi ha algú amb aquelles tres línies escrites i datades, no ens necessites per a això.
Fonts (verificades el 30 de setembre del 2026): la data de publicació del Proxmox VE 9.2 i les seves novetats — nota de premsa de Proxmox Server Solutions i Roadmap de Proxmox VE; la variant arm64 del 5 d'agost del 2026 — descàrregues de Proxmox; l'organització dels repositoris per versió major i els de Ceph per release — Package Repositories, wiki de Proxmox VE; les versions, builds i dates del plug-in de Veeam per a Proxmox VE (4.0 / 13.4.0.300 el 29-07-2026 amb B&R 13.1; 3.3 / 13.3.3.23 el 25-08-2026 amb B&R 13.0.3) — Veeam KB4706; el rang de versions suportades i la frase sobre arquitectura ARM — guia de suport de plataformes del Veeam Backup & Replication, que és la pàgina a consultar abans de cada finestra; les combinacions suportades entre Proxmox VE i Proxmox Backup Server i el «best effort» a dues releases — Roadmap del Proxmox Backup Server.
Qui mira la matriu abans de la teva finestra de pedaços?
Si la resposta és «el que estigui lliure aquella nit», no és cap retret: és que falta a qui li toca. Portem l'inventari de versions de la teva plataforma, mirem les matrius abans de cada finestra i responem quan alguna cosa surt malament a les tres de la matinada — és el nostre suport IT 24×7. I si estàs arribant a Proxmox des de vSphere, aquest reflex és dels primers que cal canviar: ho treballem dins de la migració de VMware a Proxmox.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN