Una macchina virtuale non è collocata in una partizione come un sistema classico: è un grosso file posato su un disco, quasi sempre un server in RAID. Quando l'hypervisor va in crash, il RAID cede o questo file si corrompe, non si perdono necessariamente i dati, ma occorre ricostruire due livelli uno dopo l'altro: prima ritrovare il file della macchina virtuale, poi ricostruire il sistema al suo interno. Il riflesso giusto è lo stesso di qualsiasi server: spegnere tutto, non ricreare nulla e affidare i dischi a un laboratorio.

Quanto segue spiega che cos'è davvero la virtualizzazione, come un ambiente virtualizzato va in guasto e perché alcuni tentativi di riparazione condannano definitivamente i dati.

La virtualizzazione in chiaro

Virtualizzare significa far girare una macchina completa, con il proprio sistema operativo, all'interno di un'altra. Questa macchina virtuale non fa parte del partizionamento del disco: è memorizzata in un grosso file, il che le consente di essere spostata da un server a un altro come un semplice documento.

Esistono due modi di virtualizzare, e la distinzione conta. Il primo è la cosiddetta virtualizzazione desktop, con un software come VMware Workstation o Oracle VirtualBox, installato all'interno di un sistema operativo esistente, per esempio Windows. Questo software fa girare un secondo sistema in una finestra. Si impilano allora i livelli: la macchina virtuale comunica con il software di virtualizzazione, che parla a Windows, che accede infine all'hardware reale, la scheda madre, la scheda di rete e il resto. È pratico per testare o far coesistere due sistemi su una postazione, ma non è ciò che si utilizza in produzione.

Per un server aziendale si impiega un hypervisor: VMware ESXi, Microsoft Hyper-V o Proxmox, quest'ultimo esistente anche in versione community, open source e gratuita. Qui non c'è un grande sistema operativo sopra il quale si installerebbe un software. L'hypervisor è esso stesso un piccolo software leggero, posato direttamente sulla macchina, ed è su di esso che si installano vere macchine virtuali, con Windows, Linux, macOS o sistemi più leggeri.

Il vantaggio è economico e pratico. Una macchina fisica potente non è quasi mai sollecitata al massimo in permanenza. Piuttosto che lasciare dormire questa potenza, si fanno girare due, tre o quattro server virtualizzati su una sola macchina, che ne condividono le risorse. Meglio ancora, si può attribuire a ogni VM un numero di processori e una quantità di memoria, poi aumentarli su richiesta se un server aumenta di carico. Questa flessibilità decreta il successo della virtualizzazione, ed è anche ciò che concentra molti dati critici su una sola macchina.

Virtualizzazione desktop e hypervisor: la differenza

Criterio	Virtualizzazione desktop	Hypervisor (server)
Esempi	VMware Workstation, Oracle VirtualBox	VMware ESXi, Microsoft Hyper-V, Proxmox
Installazione	In un sistema esistente (Windows)	Direttamente sulla macchina
Livelli impilati	VM, software, Windows, hardware	VM, hypervisor, hardware
Uso tipico	Testare, far coesistere due sistemi	Server di produzione
Archiviazione	Un file sul disco della postazione	Un file su un datastore, quasi sempre in RAID

Come un ambiente virtualizzato va in guasto

Poiché tutto poggia su una medesima macchina fisica e su uno stack software, i punti di rottura sono molteplici. Ecco quelli che vediamo.

Guasto	Conseguenza
Hypervisor che va in crash	Nessun accesso ai file delle macchine virtuali
RAID del server che cede	L'archiviazione delle VM diventa inaccessibile
Datastore corrotto	Lo spazio che ospita le VM non è più leggibile
File VMDK o VHDX corrotto	Come un guasto della partizione della VM
Partizione interna alla VM danneggiata	La VM non si avvia più

L'hypervisor può andare in crash e rifiutare di riavviarsi: si perde allora l'accesso ai file che contengono le diverse macchine virtuali. Il RAID del server può cedere, e poiché i server di virtualizzazione girano quasi sempre su un RAID, è un classico. Il datastore, quello spazio che ospita le VM e ne descrive l'organizzazione, può corrompersi. Il file della macchina virtuale stesso, un VMDK in VMware, un VHDX in Hyper-V, può essere danneggiato, il che equivale a un guasto della partizione della VM. Infine, il guasto può situarsi all'interno stesso della macchina virtuale, nel suo file system, impedendole di avviarsi.

Nella pratica, i due casi più frequenti sono il RAID che cede e l'hypervisor difettoso. Il resto vi si aggiunge o ne deriva.

La trappola dello snapshot

Una confusione molto diffusa costa cara: molti considerano uno snapshot come un backup. È falso, e pericoloso.

Uno snapshot non è che un'istantanea differenziale: registra i cambiamenti avvenuti da un dato momento e dipende interamente dal disco padre su cui si appoggia. Se questo disco padre è perso o corrotto, o se la catena di snapshot è interrotta, lo snapshot da solo non vale più nulla. Peggio ancora, una lunga catena di snapshot mai consolidati indebolisce l'insieme e complica qualsiasi recupero. Uno snapshot aiuta a tornare indietro rapidamente, ma non sostituisce in alcun modo un vero backup indipendente.

Il doppio livello: ritrovare il file, poi il suo contenuto

È ciò che distingue il recupero di un server virtualizzato da quello di un disco ordinario: ci sono due livelli da ricostruire, uno dopo l'altro.

Il primo consiste nel ritrovare il file della macchina virtuale, il VMDK o il VHDX, là dove si trova, ossia il più delle volte su un RAID guasto. Occorre dunque prima ricostruire il RAID per accedere al datastore, poi estrarne i file di virtualizzazione. Il secondo livello consiste nell'aprire questo file e ricostruire il sistema che contiene, con il proprio file system e i propri dati.

L'esigenza del cliente orienta allora il lavoro. Alcuni vogliono recuperare i file virtuali stessi, per rimetterli in funzione così come sono su un altro server. Altri non hanno più l'uso della virtualizzazione: vogliono migrare verso un Windows Server più recente, e non è il VMDK che li interessa, ma il suo contenuto. In questo caso, esportiamo il file della VM, poi ne analizziamo il contenuto per restituire a parte i file, i database o i sistemi di posta che racchiudeva.

Il nostro metodo non cambia. Come per qualsiasi recupero, iniziamo col congelare lo stato: nessun intervento diretto sugli originali, ma copie bit a bit di sicurezza, sulle quali soltanto lavoriamo in seguito. Ricostruiamo il RAID al volo a partire da queste copie, ritroviamo i file di virtualizzazione, li esportiamo, poi ricostruiamo il loro contenuto. Non abbiamo peraltro bisogno dell'intero server: tutto si rielabora virtualmente, a partire dai dischi.

Gli errori che aggravano, e la prevenzione

Di fronte a un ambiente virtualizzato in guasto, l'accanimento è il peggior nemico. Ricreare un datastore, generare nuovi snapshot, reinstallare l'hypervisor sui dischi o lanciare un rebuild RAID azzardato: ciascuna di queste manipolazioni scrive sull'archiviazione e può distruggere definitivamente dati ancora recuperabili. Più si tenta di riparare da soli alla cieca, più si riducono le probabilità. Il riflesso giusto è arrestare il server e affidare i dischi a un laboratorio prima di qualsiasi altro tentativo.

Sul versante della prevenzione, la virtualizzazione non dispensa dal fare backup, al contrario, poiché concentra più server su una sola macchina. Alcune soluzioni, come Proxmox, sanno realizzare veri backup verso un NAS remoto, il che è un vero vantaggio. Ma persino un backup automatizzato non protegge da tutto, potendo un ransomware per esempio raggiungere i file delle VM come il resto. Una macchina virtuale posata su un RAID non è un backup: occorre, anche qui, una copia indipendente conservata altrove.

Ciò che bisogna ricordare

Una macchina virtuale è un file, generalmente memorizzato su un server in RAID, e il suo recupero si gioca su due livelli: ritrovare il file VMDK o VHDX, poi ricostruire il sistema e i dati che contiene. I guasti più frequenti derivano dal RAID che cede o dall'hypervisor che va in crash, e uno snapshot, spesso scambiato per un backup, non lo è.

In caso di problema, la regola è quella di qualsiasi incidente serio su un server: non ricreare nulla, non reinstallare nulla, spegnere e affidare i dischi. Un laboratorio lavora su copie, ricostruisce il RAID virtualmente, estrae i file delle VM e il loro contenuto, senza mai toccare gli originali. E per il futuro, un vero backup esterno resta l'unica rete che regga.

Domande frequenti

Che cos'è di preciso una macchina virtuale?

È un computer completo, con il proprio sistema operativo, che gira all'interno di un'altra macchina. A differenza di un sistema classico, non occupa una partizione: è memorizzata in un grosso file (un VMDK in VMware, un VHDX in Hyper-V), il che consente di spostarla da un server all'altro come un documento.

Uno snapshot può fungere da backup?

No. Uno snapshot è un'istantanea differenziale che registra solo i cambiamenti da un dato momento e che dipende interamente dal disco padre. Se il padre è perso o se la catena di snapshot è interrotta, lo snapshot da solo non vale più nulla. Aiuta a tornare indietro, ma non sostituisce un backup indipendente.

Quali sono i guasti più frequenti su un server virtualizzato?

Nella pratica, due dominano: il RAID del server che cede (i server di virtualizzazione girano quasi sempre su un RAID) e l'hypervisor che va in crash e rifiuta di riavviarsi. Seguono poi il datastore corrotto, il file VMDK o VHDX danneggiato e la partizione interna alla VM.

Si possono recuperare i dati senza il server fisico?

Sì. Bastano i dischi. Ne realizziamo copie bit a bit, ricostruiamo il RAID virtualmente a partire da queste copie, ritroviamo i file di virtualizzazione, poi ricostruiamo il loro contenuto. Tutto si rielabora virtualmente, senza aver bisogno dell'intera macchina.

Cosa fare, e soprattutto non fare, quando una VM non si avvia più?

Non ricreare un datastore, non generare nuovi snapshot, non reinstallare l'hypervisor sui dischi e non lanciare un rebuild RAID azzardato: ciascuna di queste manipolazioni scrive sull'archiviazione e può distruggere dati ancora recuperabili. Il riflesso giusto è spegnere il server e affidare i dischi a un laboratorio.

La virtualizzazione dispensa dal fare backup?

Al contrario. Poiché concentra più server su una sola macchina, aumenta il rischio in caso di sinistro. Soluzioni come Proxmox sanno effettuare backup verso un NAS remoto, ma nessun backup protegge da tutto (un ransomware può raggiungere i file delle VM). Una VM posata su un RAID non è un backup: occorre una copia indipendente conservata altrove.