Veeam 13.1 protegge le VM OpenShift: come evitare buchi di backup

di EP ConsultingInformatica per aziende
Migrazione di macchine virtuali verso OpenShift protetta da Veeam 13.1

Veeam Backup & Replication 13.1 estende la protezione nativa alle macchine virtuali eseguite su Red Hat OpenShift Virtualization. La novità, resa disponibile da Veeam l’8 settembre 2026, interessa soprattutto le aziende che stanno affiancando o sostituendo VMware vSphere e vogliono evitare che una VM, una volta spostata, esca dalle politiche di backup esistenti. L’integrazione utilizza un plug-in KubeVirt installato in Veeam e un proxy leggero distribuito nel cluster OpenShift tramite Helm. Le VM vengono quindi inventariate e gestite dalla console già usata dagli amministratori Veeam. Non significa però che ogni risorsa Kubernetes sia automaticamente protetta: la funzione riguarda le VM KubeVirt, mentre applicazioni containerizzate, namespace e dati Kubernetes richiedono una strategia specifica. Per una PMI strutturata o un provider IT, il valore non è soltanto tecnico: consente di pianificare la migrazione mantenendo repository, retention, immutabilità e procedure di ripristino già note.

Veeam 13.1 e backup delle VM OpenShift: cosa cambia

OpenShift Virtualization consente di eseguire macchine virtuali insieme ai workload containerizzati usando KubeVirt. Per chi migra da un hypervisor tradizionale, questo permette di portare inizialmente le applicazioni esistenti nel nuovo ambiente senza trasformarle subito in microservizi.

Il punto critico è la continuità della protezione. Un job che seleziona una VM nell’inventario vSphere non continua necessariamente a proteggerla dopo il trasferimento su un’altra piattaforma. Se il controllo non viene aggiornato, la migrazione può riuscire dal punto di vista applicativo ma lasciare un intervallo senza backup valido. Veeam presenta la nuova integrazione proprio per ridurre questo rischio e stima che i programmi di migrazione possano durare da 12 a 18 mesi: durante questo periodo i due ambienti possono convivere a lungo.

Con Veeam Backup & Replication 13.1 o successivo, le VM OpenShift possono essere aggiunte ai job dalla stessa console usata per vSphere. Restano utilizzabili i repository già supportati da Veeam, compresi repository locali, Scale-out Backup Repository, storage a oggetti compatibile, Azure Blob, Google Cloud Storage e hardened repository Linux con immutabilità. È una continuità operativa utile, ma non elimina la necessità di ridimensionare capacità, banda e finestre di backup.

Come funziona l’architettura con KubeVirt

L’integrazione è composta da due elementi principali:

  1. Veeam KubeVirt Plug-in, installato nell’ambiente Veeam Backup & Replication;
  2. Veeam KubeVirt Proxy, distribuito nel cluster OpenShift mediante un chart Helm.

Dopo la configurazione della connettività, Veeam interroga le API KubeVirt, rileva le macchine virtuali e le rende selezionabili nei job. Il proxy nel cluster gestisce il percorso dei dati tra i dischi virtuali e l’infrastruttura di backup. Questa impostazione evita di trattare OpenShift come una semplice destinazione generica e permette alla piattaforma di conoscere gli oggetti VM.

Il flusso operativo

In pratica l’amministratore aggiorna Veeam, installa il plug-in, distribuisce il proxy nel cluster, configura credenziali e rete, quindi verifica l’inventario. Solo dopo questi passaggi assegna le VM ai job, applica retention e notifiche ed esegue un primo backup controllato. La presenza automatica nell’inventario non equivale alla protezione: una VM è realmente coperta soltanto quando appartiene a un job riuscito e dispone di un punto di ripristino verificato.

Veeam dichiara backup completi e incrementali, replica fuori sede, archiviazione su nastro, ripristino a livello di file, deduplicazione, cifratura dei file di backup e uso dello storage immutabile supportato. La pagina di prodotto include inoltre Instant VM Recovery tra le opzioni disponibili. Prima di inserirla in un piano di continuità è comunque opportuno validare la funzione sul proprio abbinamento di versione OpenShift, storage class, rete e repository.

Licenze, versioni e requisiti da verificare

La protezione delle VM OpenShift è inclusa in Veeam Backup & Replication 13.1 e utilizza le licenze Veeam Universal License già disponibili. Secondo Veeam non serve acquistare un prodotto, uno SKU o un contratto separato. Questo non significa che il progetto sia privo di costi: possono aumentare il numero di workload consumati dalla licenza, lo spazio nel repository, il traffico tra cluster e infrastruttura di backup e le attività di progettazione.

Veeam Data Platform 13.1 è stata annunciata come disponibile il 29 luglio 2026, mentre il plug-in OpenShift era indicato per il terzo trimestre ed è stato poi presentato come disponibile l’8 settembre. Chi ha installato la prima build di 13.1 non dovrebbe quindi presumere di avere automaticamente tutti i componenti: occorre verificare build, plug-in scaricato e relativa matrice di compatibilità.

Per aggiornare direttamente una installazione Windows, la guida Veeam indica come base minima la build 12.3.1.1139. Versioni precedenti richiedono un percorso intermedio. Prima dell’upgrade vanno inoltre controllati compatibilità di sistema operativo e database, integrazioni, provider di servizi e componenti distribuiti. Se i backup vengono inviati a un Veeam Cloud & Service Provider, il tenant non può utilizzare una versione più recente del provider: il coordinamento va fatto prima della finestra di manutenzione.

VM OpenShift e container non sono la stessa cosa

Questa distinzione è decisiva. Il plug-in protegge le macchine virtuali KubeVirt eseguite su OpenShift. Non sostituisce automaticamente il backup delle applicazioni Kubernetes native, dei namespace, dei manifest, dei secret e dei volumi persistenti usati dai container. Veeam indica Veeam Kasten come soluzione per i workload containerizzati; i due prodotti possono coesistere.

Anche Red Hat documenta un percorso nativo basato su OpenShift API for Data Protection (OADP): per OpenShift Virtualization richiede i plug-in kubevirt e openshift, con backup tramite risorse personalizzate e opzioni storage supportate basate su CSI, anche con DataMover. OADP e l’integrazione Veeam non vanno confusi: hanno architetture, flussi operativi e perimetri di supporto differenti.

Una corretta matrice di protezione dovrebbe quindi elencare separatamente:

  • VM migrate o create in OpenShift Virtualization;
  • applicazioni containerizzate e relativi namespace;
  • database che richiedono consistenza applicativa;
  • configurazione del cluster e componenti infrastrutturali;
  • repository, copie off-site e credenziali di ripristino.

Portabilità tra hypervisor: utile, ma da collaudare

Veeam presenta la possibilità di ripristinare una VM protetta verso OpenShift e di riportare una VM OpenShift verso un hypervisor supportato. È una funzione interessante per migrazioni, test e piani di uscita, perché separa maggiormente il dato dal singolo hypervisor. Non va però interpretata come garanzia di portabilità immediata per qualsiasi applicazione.

Un ripristino cross-platform può richiedere modifiche a driver, firmware virtuale, configurazione di rete, indirizzi IP, strumenti guest e procedure di avvio. Anche licenze applicative legate all’hardware virtuale o al sistema operativo possono reagire al cambio. La raccomandazione di EP Consulting è eseguire un test documentato su almeno una VM rappresentativa per ogni classe di servizio, misurando tempo di recupero, consistenza e attività manuali.

Cosa significa per una PMI

Per una piccola azienda con pochi server VMware, OpenShift Virtualization potrebbe essere sovradimensionato: richiede competenze Kubernetes, progettazione del cluster e una gestione più articolata rispetto a un hypervisor tradizionale. La nuova integrazione Veeam non è quindi un motivo sufficiente, da sola, per scegliere OpenShift.

Diventa invece rilevante per PMI strutturate, software house, imprese industriali con piattaforme applicative moderne, gruppi con più sedi e fornitori MSP che già adottano Red Hat. In questi casi permette di mantenere un punto di controllo comune mentre alcune VM restano su vSphere e altre passano a OpenShift. Per confrontare l’impatto di alternative più tradizionali può essere utile leggere anche l’approfondimento su VMware vSphere Standard per la virtualizzazione server e la guida sul supporto enterprise 24/7 di Proxmox.

La decisione dovrebbe partire dai carichi, non dal marchio: requisiti di disponibilità, competenze interne, dipendenze applicative, costi di licenza e supporto, capacità di backup e possibilità di uscita devono essere quantificati prima della migrazione. Anche un buon prodotto di backup non compensa un inventario incompleto o un ripristino mai provato.

Checklist prima di proteggere le VM OpenShift con Veeam

  1. Censire le VM: associare proprietario, criticità, RPO, RTO, dipendenze e destinazione di migrazione.
  2. Controllare le versioni: verificare build Veeam, versione del plug-in, OpenShift Virtualization e componenti supportati.
  3. Valutare la licenza: calcolare i workload aggiuntivi e la disponibilità effettiva di Veeam Universal License.
  4. Progettare la rete: documentare DNS, certificati, firewall, route e banda tra proxy KubeVirt e repository.
  5. Dimensionare storage e proxy: stimare dati iniziali, incrementali, retention, crescita e finestre.
  6. Separare VM e container: definire strumenti e responsabilità per ciascun perimetro.
  7. Creare un gruppo pilota: iniziare con VM non critiche ma rappresentative.
  8. Verificare il primo punto di ripristino: controllare esito, log, notifiche e presenza nel repository.
  9. Provare restore e portabilità: eseguire recupero completo, file-level e, se previsto, cross-hypervisor.
  10. Aggiornare procedure e monitoraggio: includere OpenShift nei report, negli alert e nei runbook di emergenza.

La gestione centralizzata del backup ibrido resta un riferimento utile per confrontare logiche di repository, copie e ripristino. Per valutare una migrazione o costruire una matrice RPO/RTO coerente, EP Consulting può affiancare l’azienda con una consulenza IT sull’infrastruttura e la continuità operativa.

FAQ

Veeam 13.1 protegge tutto il cluster OpenShift?

No. La nuova integrazione riguarda le macchine virtuali KubeVirt in Red Hat OpenShift Virtualization. I container, i namespace e i dati delle applicazioni Kubernetes native richiedono una protezione dedicata. Veeam indica Kasten per questo perimetro, mentre Red Hat documenta OADP come proprio percorso di backup e ripristino. L’azienda deve quindi costruire una matrice dei workload e verificare che nessuna risorsa resti fuori.

Serve una nuova licenza per le VM OpenShift?

Veeam dichiara che la funzione è inclusa in Backup & Replication 13.1 e usa Veeam Universal License esistente, senza un nuovo prodotto o contratto. Occorre comunque verificare che l’entitlement disponibile copra il numero di workload e considerare costi indiretti come capacità del repository, banda, infrastruttura OpenShift e attività di implementazione.

Le VM migrate da vSphere entrano automaticamente nei vecchi job?

Veeam può rilevarle nell’inventario OpenShift dopo l’installazione del plug-in e del proxy, ma la sola discovery non prova che siano protette. È necessario controllare l’appartenenza ai job, eseguire il backup e verificare un punto di ripristino. Durante la migrazione conviene confrontare quotidianamente inventario sorgente, inventario destinazione e report dei job.

È possibile usare gli stessi repository Veeam?

Sì, Veeam indica il supporto dei repository già gestiti da Backup & Replication, inclusi storage on-premises, SOBR, object storage e hardened repository Linux. Prima di riutilizzarli bisogna verificare capacità residua, throughput, retention, immutabilità e traffico generato dal nuovo cluster.

Si può ripristinare una VM OpenShift su un altro hypervisor?

Veeam presenta la mobilità cross-hypervisor tra OpenShift e piattaforme supportate. La possibilità tecnica non elimina le verifiche applicative: driver, rete, firmware virtuale, licenze e dipendenze possono richiedere interventi. Il percorso deve essere provato su VM pilota e documentato prima di essere inserito nel piano di disaster recovery.

Fonti