Aggiornare Proxmox VE da 8 a 9 e PBS da 3 a 4: guida e checklist

Quando finisce il supporto di Proxmox VE 8 e Proxmox Backup Server 3?

Proxmox VE 8 e Proxmox Backup Server (PBS) 3 sono a fine supporto da agosto 2026: i nodi e i server di backup ancora su queste versioni vanno aggiornati alla 9 e alla 4. Le FAQ di Proxmox VE spiegano il calendario. Proxmox VE 8 si basa su Debian 12 «Bookworm» ed è uscita a giugno 2023; Proxmox indica la fine del supporto a luglio 2026 per Debian 12 e ad agosto 2026 per Proxmox VE 8. Una versione di Proxmox VE è supportata almeno quanto il Debian Security Team supporta la versione di Debian su cui si basa, cioè circa tre anni dalla prima uscita. Debian 12 prosegue con il supporto LTS fino al 30 giugno 2028, che aggiorna i pacchetti di Debian, non quelli di Proxmox. Le FAQ di Proxmox Backup Server indicano lo stesso per PBS 3, che si basa su Debian 12, mentre PBS 4 si basa su Debian 13 ed è uscito ad agosto 2025.

L'annuncio ufficiale di PBS 4.0, del 6 agosto 2025, precisa che PBS 3.4 riceve aggiornamenti di sicurezza e correzioni dei bug critici fino ad agosto 2026. Con la fine del supporto di Proxmox VE 8 un nodo non riceve più aggiornamenti dei pacchetti Proxmox, quelli di sicurezza compresi, e lo stesso vale per un PBS 3. Le Roadmap ufficiali riportano come versioni correnti Proxmox VE 9.2 del 21 maggio 2026 e PBS 4.2 del 29 aprile 2026; sulla prima c'è l'articolo con le novità di Proxmox VE 9.2. Proxmox VE 9 si basa su Debian 13 «Trixie» ed è uscita ad agosto 2025; la fine del suo supporto non è ancora fissata. Per la piattaforma Proxmox VE la guida ufficiale «Upgrade from 8 to 9» prevede due strade: un'installazione nuova su hardware nuovo, con il ripristino di VM e container dal backup, oppure l'aggiornamento sul posto (in-place) con apt. Questa guida descrive l'aggiornamento sul posto.

Prerequisiti: cosa controllare prima di aggiornare

Prima di toccare i repository verifica la versione minima su ogni nodo, il backup, lo spazio libero sulla root e l'accesso: predisponi IPMI/iKVM o la console fisica, oppure una sessione SSH dentro tmux o screen. Proxmox richiede un backup valido e provato di tutte le VM e i container, e raccomanda di provarne il ripristino prima in un ambiente di test. Se hai solo SSH, raccomanda di provarlo prima su una macchina identica non di produzione. Non eseguire l'aggiornamento dalla console virtuale della GUI: si interrompe durante l'aggiornamento, come precisa anche la guida «Upgrade from 3 to 4» di PBS.

Lo script pve8to9 è incluso nei pacchetti più recenti di Proxmox VE 8.4. Con pve8to9 --full esegue tutti i controlli senza cambiare niente sul sistema: segnala soltanto. Esegui lo script prima dell'aggiornamento, dopo ogni correzione e dopo l'aggiornamento. Su PBS l'equivalente è pbs3to4, con pbs3to4 --full, incluso negli ultimi pacchetti 3.4. Se un esito non è quello atteso, correggi prima di procedere.

I comandi di questa guida riportano la procedura della documentazione ufficiale alla data di consultazione: confrontali con la guida della tua versione e adattali al tuo ambiente prima di eseguirli in produzione.

Per la copia della configurazione del PBS, il comando indicato da Proxmox è questo:

tar czf "pbs3-etc-backup-$(date -I).tar.gz" -C "/etc" "proxmox-backup"

In che ordine aggiornare cluster, Ceph e Proxmox Backup Server

Aggiorna prima Ceph a Squid, se lo usi in modo iperconvergente, e tutti i nodi alla 8.4; poi procedi un nodo alla volta. Proxmox Backup Server può passare alla 4 prima o dopo il cluster, perché le versioni adiacenti sono compatibili. La sequenza, costruita sui prerequisiti delle guide ufficiali:

1. Verifica il backup di tutte le VM e i container.
2. Con Ceph iperconvergente, aggiorna Ceph da Quincy o Reef a Squid, ancora su Proxmox VE 8.
3. Aggiorna tutti i nodi all'ultima 8.4.
4. Aggiorna un nodo alla volta da 8 a 9, spostando prima le VM e i container che devono restare accesi.
5. Aggiorna PBS da 3 a 4, prima o dopo il cluster.

Dopo ogni nodo controlla che tutti i nodi siano attivi; finché restano nodi da aggiornare, passa al successivo ripartendo dai prerequisiti. Secondo la guida di Proxmox VE, la migrazione di una VM o di un container da una versione più vecchia a una più nuova funziona sempre, mentre nel senso opposto può funzionare ma in generale non è supportata. Sposta quindi le VM dai nodi ancora sulla 8 verso quelli già sulla 9, mai il contrario. In un cluster in stato misto, se la GUI di un nodo 9 segnala errori su un'azione verso un nodo 8, ripeti l'azione dalla GUI del nodo 8.

In Proxmox VE 9 i gruppi HA sono deprecati a favore delle regole HA (HA rules). La conversione avviene automaticamente quando tutti i nodi sono sulla 9; in caso di problemi esegui journalctl -eu pve-ha-crm sul nodo con il CRM attivo ed esamina il log. L'annuncio di PBS 4.0 indica come sicuri i backup da Proxmox VE 8 verso PBS 4 e da Proxmox VE 9 verso PBS 3, mentre fra versioni a due o più release di distanza la compatibilità è solo «best effort». Se PBS è installato sullo stesso host di Proxmox VE, segui entrambe le guide e allinea i cambi di repository.

Come portare Ceph da Reef a Squid prima di Proxmox VE 9

Con Ceph iperconvergente, Proxmox VE 9 richiede Ceph 19.2 Squid, e il passaggio si fa ancora su Proxmox VE 8, un servizio alla volta, come descrive la guida «Ceph Reef to Squid». Servono Proxmox VE 8.2 o successiva con pve-manager 8.2.8 o successivo, pacchetti Ceph Reef 18.2.4-pve3 o successivi (verificali con pveversion --verbose), un cluster sano e funzionante e nessun OSD FileStore. Il passaggio diretto da Quincy a Squid è possibile, ma Proxmox consiglia di passare prima a Reef.

1. Punta il repository di ogni nodo a Squid: sed -i 's/reef/squid/' /etc/apt/sources.list.d/ceph.list
2. Imposta il flag noout una volta sola: ceph osd set noout
3. Aggiorna i pacchetti su ogni nodo con apt update e poi apt full-upgrade; i servizi continuano a eseguire Reef finché non riavvii i demoni.
4. Riavvia i monitor, un nodo alla volta, con systemctl restart ceph-mon.target, controllando ceph -s fra un riavvio e l'altro; poi ceph mon dump | grep min_mon_release deve indicare 19 (squid).
5. Riavvia i manager se non sono ripartiti automaticamente: systemctl restart ceph-mgr.target
6. Riavvia gli OSD un nodo alla volta, per non perdere ridondanza, con systemctl restart ceph-osd.target, controllando ceph status fra un nodo e l'altro.
7. Quando tutti gli OSD eseguono la 19.2, esegui ceph osd require-osd-release squid.
8. Con CephFS, aggiorna i server MDS seguendo la procedura della guida: riduci max_mds a 1, arresta gli MDS in standby, riavvia l'ultimo attivo, riavvia gli standby, ripristina i valori.
9. Rimuovi il flag: ceph osd unset noout

Con il repository enterprise, un errore 401 su apt update si risolve con pvesubscription update --force.

Come aggiornare Proxmox VE da 8 a 9 su ogni nodo

Su ogni nodo controlla con pve8to9, punta i repository da bookworm a trixie, avvia apt dist-upgrade e riavvia. Per aggiornare Proxmox VE 8 a 9 usi il repository enterprise se hai una sottoscrizione Proxmox, altrimenti il repository no-subscription. La guida all'installazione di Proxmox VE di Rackone riassume questi passi in breve.

1. Lavora da SSH (con tmux o screen) o dalla console fisica, non dalla console virtuale della GUI.

2. Sposta su un altro nodo le VM e i container che devono restare accesi.

3. Aggiorna il nodo all'ultima 8.4 e controlla la versione:

   apt update
   apt dist-upgrade
   pveversion
   

4. Con Ceph iperconvergente controlla ceph --version: deve essere Squid 19. Altrimenti fermati e torna alla sezione su Ceph.

5. Avvia pve8to9 --full, correggi i problemi segnalati e rilancia lo script finché non rileva più problemi.

6. Punta i repository Debian a trixie:

   sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
   sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list
   

   Commenta con # le righe rimaste su bookworm.

7. Crea il repository di Proxmox VE 9 nel formato deb822. Con la sottoscrizione, il file /etc/apt/sources.list.d/pve-enterprise.sources:

   Types: deb
   URIs: https://enterprise.proxmox.com/debian/pve
   Suites: trixie
   Components: pve-enterprise
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Poi rimuovi il vecchio pve-enterprise.list. Senza sottoscrizione il file è /etc/apt/sources.list.d/proxmox.sources:

   Types: deb
   URIs: http://download.proxmox.com/debian/pve
   Suites: trixie
   Components: pve-no-subscription
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Rimuovi anche la vecchia riga no-subscription di Proxmox VE 8.

8. Con Ceph iperconvergente crea /etc/apt/sources.list.d/ceph.sources. Con la sottoscrizione:

   Types: deb
   URIs: https://enterprise.proxmox.com/debian/ceph-squid
   Suites: trixie
   Components: enterprise
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Senza sottoscrizione:

   Types: deb
   URIs: http://download.proxmox.com/debian/ceph-squid
   Suites: trixie
   Components: no-subscription
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Poi elimina /etc/apt/sources.list.d/ceph.list e ogni riga backports.

9. Avvia apt update, verifica che non segnali errori, poi esegui apt policy per vedere i repository attivi.

10. Facoltativo: per non riempire il log di messaggi di audit durante l'aggiornamento, disattiva il socket di audit di journald con systemctl disable --now systemd-journald-audit.socket.

11. Avvia apt dist-upgrade. La durata indicata da Proxmox va da meno di 5 minuti su SSD a oltre 60 minuti su dischi meccanici lenti. Alle domande sui file di configurazione: per /etc/issue mantieni la versione attuale (la risposta predefinita «No»); per /etc/lvm/lvm.conf, /etc/ssh/sshd_config e /etc/chrony/chrony.conf scegli la versione del manutentore se non li hai modificati; per /etc/default/grub mantieni la tua nel dubbio e controlla le differenze.

12. Riesegui pve8to9 e riavvia sul nuovo kernel, anche se usavi già il kernel 6.14 opzionale della 8.

13. Svuota la cache del browser oppure esegui un ricaricamento forzato dell'interfaccia web.

Come aggiornare Proxmox Backup Server da 3 a 4

Si parte dalla 3.4 e il passaggio alla 4 si fa con apt, come conferma l'annuncio ufficiale. L'aggiornamento a Proxmox Backup Server 4 ricalca la procedura dei nodi (pbs3to4, repository trixie, apt dist-upgrade) e aggiunge la modalità di manutenzione dei datastore, che evita backup nuovi durante il passaggio.

1. Facoltativo: configura ogni datastore in modalità di manutenzione di sola lettura:

   proxmox-backup-manager datastore update DATASTORE-ID --maintenance-mode read-only
   

2. Aggiorna PBS all'ultima 3.4: esegui apt update e apt dist-upgrade, poi proxmox-backup-manager versions (3.4.2-1 o successiva).

3. Avvia pbs3to4 --full e correggi i problemi segnalati.

4. Punta i repository Debian a trixie con sed -i 's/bookworm/trixie/g' /etc/apt/sources.list; controlla anche /etc/apt/sources.list.d/ e commenta le righe rimaste su bookworm.

5. Crea /etc/apt/sources.list.d/pbs-enterprise.sources:

   Types: deb
   URIs: https://enterprise.proxmox.com/debian/pbs
   Suites: trixie
   Components: pbs-enterprise
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Poi cancella /etc/apt/sources.list.d/pbs-enterprise.list. Senza sottoscrizione il file è /etc/apt/sources.list.d/proxmox.sources:

   Types: deb
   URIs: http://download.proxmox.com/debian/pbs
   Suites: trixie
   Components: pbs-no-subscription
   Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
   

   Se PBS è installato sullo stesso host di Proxmox VE e usi i repository no-subscription, le due guide creano lo stesso file proxmox.sources, e ricrearlo con il solo blocco di PBS cancella quello di Proxmox VE. Tieni i due blocchi nello stesso file, separati da una riga vuota, come prevede il formato dei file .sources.

6. Avvia apt update, verifica che non segnali errori, poi consulta apt policy.

7. Avvia apt dist-upgrade. Alle domande: mantieni /etc/issue attuale, scegli /etc/ssh/sshd_config del manutentore se non l'hai modificato, controlla con attenzione /etc/default/grub.

8. Riavvia con systemctl reboot.

Come verificare che l'aggiornamento sia riuscito

Dopo il riavvio controlla la versione, la salute del cluster e di Ceph, le regole HA e i servizi del PBS, poi riattiva i datastore. Se un esito non è quello atteso, cerca il sintomo nella sezione sugli errori comuni.

Ceph Squid 19.2.6 e Ceph Tentacle 20.2.4 hanno aggiunto controlli di salute per le chiavi che usano il metodo aes, interessato dalla CVE-2025-30156, e segnalano HEALTH_ERR. Se non ci sono altri avvisi, Proxmox indica di proseguire e di migrare le chiavi quando tutti i nodi sono sulla 9. Su PBS, facoltativo, apt modernize-sources converte i file dei repository nel formato deb822: con la risposta «n» visualizzi le modifiche senza applicarle, e quando esegui la conversione i vecchi file .list vengono conservati con il suffisso .bak. Controlla infine che il primo backup programmato dopo l'aggiornamento vada a buon fine.

Errori comuni e problemi noti

La maggior parte dei problemi noti si vede al riavvio o al primo avvio delle VM. Dopo ogni correzione riesegui pve8to9 o pbs3to4, a seconda del sistema.

La documentazione di aggiornamento segnala anche effetti che non richiedono interventi. La memoria delle VM può apparire più alta o sopra il 100%, perché il nuovo conteggio include l'overhead della VM. Su Debian 13, inoltre, /tmp è un tmpfs (fino al 50% della memoria) e viene ripulito durante il funzionamento.

Cluster Update con Rackone

Con il Cluster Update dei servizi sistemistici Proxmox, Rackone (Proxmox Gold Partner) esegue la verifica preliminare di configurazione, storage e servizi, l'aggiornamento nella finestra concordata e prepara un piano di rollback. Il backup non è compreso: prima dell'intervento eseguilo e verificalo tu. Se preferisci aggiornare in autonomia, la checklist di questa guida copre prerequisiti, ordine e verifica.

Pianifica l'aggiornamento del cluster