Come recuperare i dati da dischi virtuali QCOW2 e snapshot KVM (QEMU) in RHEL 7.9
In questo articolo spiegheremo come recuperare dischi virtuali KVM e snapshot in Red Hat Enterprise Linux 7.9, identificare la causa della perdita di dati e ripristinare l’accesso alle informazioni utilizzando gli strumenti appropriati.

- Architettura KVM e LVM in RHEL 7.9
- Collegamento dei dischi al computer
- Come recuperare macchine virtuali e snapshot KVM (QEMU) da RHEL 7.9
- Conclusione
- Domande frequenti
- Commenti
La virtualizzazione basata su KVM (Kernel-based Virtual Machine) e QEMU è ampiamente utilizzata in Red Hat Enterprise Linux 7.9 per creare e gestire macchine virtuali. I relativi sistemi operativi, le applicazioni e i file utente sono memorizzati su dischi virtuali, ad esempio nei formati QCOW2 o RAW. Gli snapshot possono essere utilizzati per preservare uno stato precedente delle macchine virtuali, consentendo di tornare a un determinato punto nel tempo. Tuttavia, l’eliminazione accidentale di file, il danneggiamento dell’immagine del disco, il guasto di un’unità fisica o una catena di snapshot interrotta possono portare alla perdita di accesso ai dati critici.
Come recuperare macchine virtuali KVM (QEMU) e snapshot da RHEL 7.9
Architettura KVM e LVM in RHEL 7.9
Analizziamo più da vicino l’architettura del nostro sistema server.
Il sistema operativo Red Hat Enterprise Linux 7.9 è installato su un disco di sistema separato con file system XFS. Lo spazio di archiviazione per l’ambiente di virtualizzazione KVM, invece, utilizza un sottosistema di dischi complesso a più livelli.

Il sistema è basato su array di dischi RAID 5 e RAID 0. Su di essi sono implementati volumi logici LVM. Per garantire la sicurezza dei dati, questi volumi sono inoltre crittografati mediante lo standard LUKS, e solo all’interno di questo contenitore crittografico viene creato il file system ext4, in cui sono memorizzati direttamente i file delle macchine virtuali.
Tutto questo ambiente è gestito tramite il demone Libvirt, che astrae comodamente la gerarchia dei dischi fisici in pool di archiviazione e li associa alle configurazioni di ciascuna macchina virtuale. Tuttavia, nel momento di un guasto, questa comodità si ritorce contro di noi, perché quando si verifica un problema al livello di archiviazione sottostante, Libvirt perde immediatamente la connessione ai pool. Di conseguenza, tutte le macchine virtuali scompaiono semplicemente dalla console di gestione oppure diventano immediatamente indisponibili.
Il problema principale è che un’architettura così complessa complica in modo significativo il processo di recupero dei dati. L’intera struttura (RAID, LVM, LUKS ed ext4) è strettamente interconnessa. Un guasto a uno qualsiasi di questi livelli interrompe immediatamente l’intera catena e blocca completamente l’accesso alle macchine virtuali.
Passiamo direttamente alle macchine virtuali. Esse utilizzano dischi virtuali nel popolare formato qcow2. Questo formato supporta gli snapshot, ossia acquisizioni dello stato del sistema in un determinato momento. Archiviare tutti gli snapshot e le modifiche correnti in un unico file di disco virtuale è estremamente comodo per l’amministrazione e la gestione delle risorse.
Tuttavia, dal punto di vista dell’affidabilità, ciò rende il sistema altamente vulnerabile. Se questo singolo file qcow2 si corrompe logicamente a causa di un guasto del sistema host, si rischia di perdere non solo la versione operativa corrente della macchina virtuale, ma anche tutti i suoi stati salvati in un colpo solo.
Fortunatamente, ciò non significa una perdita permanente delle informazioni, perché con Hetman RAID Recovery è possibile analizzare la struttura danneggiata e recuperare con successo sia i dischi virtuali stessi sia i dati in essi contenuti.
| Componente | Scopo e caratteristiche |
|---|---|
| KVM (Kernel-based Virtual Machine) | Un modulo del kernel Linux che fornisce la virtualizzazione hardware e consente l’esecuzione di macchine virtuali in RHEL 7.9. |
| QEMU | Emula l’hardware virtuale e fornisce il funzionamento delle macchine virtuali, incluso l’accesso ai relativi dischi virtuali. |
| libvirt | Strumenti di gestione della virtualizzazione utilizzati per creare, avviare, arrestare e configurare macchine virtuali tramite virsh e altri strumenti. |
| Macchina virtuale (VM) | Un ambiente isolato in cui un sistema operativo guest esegue le proprie applicazioni, impostazioni e file. |
| Disco virtuale QCOW2 | Un formato di immagine disco di QEMU che supporta allocazione dinamica, metadati e snapshot interni. Può essere utilizzato anche come parte di una catena di snapshot esterni. |
| Disco virtuale RAW | Un’immagine disco priva della struttura contenitore aggiuntiva di QCOW2. Può essere memorizzata in un file o su un dispositivo a blocchi LVM. |
| Snapshot | Uno stato salvato di un disco o di una macchina virtuale. Gli snapshot possono essere interni, memorizzati in un unico file QCOW2, oppure esterni, in cui le modifiche vengono scritte in un file separato. |
| Catena di snapshot esterni | Una sequenza composta da un’immagine di base e da dischi figlio che memorizzano le modifiche. Per accedere allo stato corrente dei dati, i collegamenti corretti tra i file devono essere preservati. |
| LVM (Logical Volume Manager) | Un sistema di gestione dei volumi logici di Linux che consente di combinare dispositivi fisici in gruppi di volumi e di creare volumi logici per i dischi virtuali. |
| PV (Physical Volume) | Un dispositivo fisico o una partizione predisposta per l’uso in LVM. È il livello base della struttura LVM. |
| VG (Volume Group) | Un gruppo di volumi che combina uno o più PV e fornisce spazio per la creazione di volumi logici. |
| LV (Logical Volume) | Un volume logico che può essere utilizzato come dispositivo a blocchi per archiviare un disco virtuale RAW o un file system con immagini QCOW2. |
| File system dell’host | Il file system di RHEL, ad esempio XFS o ext4, su cui possono essere memorizzati i file dei dischi virtuali e le configurazioni delle macchine virtuali. |
| Configurazione XML di libvirt | Contiene i parametri della macchina virtuale, incluso il percorso del disco, il tipo di controller e altre impostazioni. Aiuta a determinare quale immagine è stata utilizzata dalla macchina virtuale. |
| Metadati LVM | Contiene informazioni su volumi fisici, gruppi di volumi e volumi logici. Il danneggiamento di questi metadati può rendere inaccessibili i volumi logici e i dati in essi memorizzati. |
Collegamento dei dischi al computer
Per iniziare il processo di recupero, è necessario rimuovere fisicamente i dischi dal server problematico e collegarli a un computer. L’opzione migliore e più rapida è un collegamento diretto alla scheda madre del computer tramite porte SATA o SAS.
È inoltre possibile utilizzare docking station o adattatori USB esterni, ma si tenga presente che ciò può ridurre la velocità di scansione.
Una regola importante durante l’assemblaggio degli array: per recuperare con successo i dati da un array RAID 5, è sufficiente collegare tutti i dischi tranne uno guasto. Per un array RAID 0, invece, è obbligatorio collegare assolutamente tutte le unità che facevano parte dell’array; in caso contrario, il recupero sarà impossibile.
Se non ci sono abbastanza porte libere per collegare tutte le unità, oppure se i dischi mostrano segni di guasto hardware, la soluzione migliore è creare immagini settore per settore. Questa funzione integrata di Hetman RAID Recovery consente di salvare una copia esatta, byte per byte, di ciascun disco come file normale. Lavorare con le immagini è una pratica di sicurezza standard, poiché la scansione avviene senza alcun carico fisico sui dischi originali del server.
Per creare un’immagine, selezionare il disco collegato nella finestra principale e fare clic sul pulsante Salva disco nel pannello superiore, specificando il percorso di salvataggio.

Dopo aver creato tutte le immagini, montarle nel programma: aprire il menu principale e selezionare Monta disco.

Selezionare il tipo Immagini disco RAW e aprire i file salvati.

Compariranno immediatamente nell’elenco dei dispositivi disponibili, pronti per l’assemblaggio automatico dell’array e per la successiva scansione.

Come recuperare macchine virtuali e snapshot KVM (QEMU) da RHEL 7.9
METODO 1. Recupero dei file della macchina virtuale
Passiamo alla pratica e consideriamo il recupero dell’accesso a un file disco virtuale qcow2.
Nel nostro caso, il file non è stato eliminato, ma l’accesso ad esso è stato completamente bloccato a causa di un improvviso guasto hardware del server e della conseguente distruzione della struttura logica dell’array.

Tuttavia, gli algoritmi di Hetman RAID Recovery consentono di aggirare facilmente questo problema. Nella finestra principale del programma possiamo vedere un array RAID 5 già assemblato automaticamente, ma per accedere ai dati il suo volume logico deve prima essere sbloccato inserendo la password LUKS.

Solo dopo aver rimosso con successo la protezione crittografica selezioniamo questo volume e avviamo l’algoritmo di Scansione rapida, che analizzerà immediatamente la struttura del nostro file system, che in questo caso è ext4.

Accedere alla cartella in cui era memorizzata la macchina virtuale. Il programma ha ricostruito correttamente l’albero delle directory e ha trovato il nostro file qcow2 integro.

Selezionare l’immagine trovata e fare clic sul pulsante Recupero nel pannello superiore, quindi scegliere обязательно una posizione sicura sul disco locale del computer o su un altro dispositivo di archiviazione per evitare la sovrascrittura dei dati.

METODO 2. Recupero dei file dai sistemi operativi guest
Consideriamo ora un altro scenario comune: la perdita di dati si è verificata direttamente all’interno della macchina virtuale stessa. Nel nostro esempio, il sistema operativo guest è Windows 10.
In genere, per accedere a tali file è necessario avviare l’hypervisor e avviare completamente la macchina virtuale, operazione non sempre possibile o sicura dopo guasti di sistema. Tuttavia, Hetman RAID Recovery consente di lavorare direttamente con il formato qcow2. È possibile aprire il disco virtuale direttamente nell’interfaccia del programma senza utilizzare un hypervisor.

Per fare ciò, aprire il menu Monta disco, selezionare l’opzione appropriata per le macchine virtuali, specificare il percorso della cartella contenente il file qcow2 salvato,

e fare clic su Monta cartella.

Dopodiché, il disco virtuale apparirà immediatamente nell’elenco generale dei dispositivi. Poiché il nostro sistema guest è Windows 10, vediamo subito la sua partizione con file system NTFS.

Selezionare questa partizione e avviare l’analisi Scansione rapida. Il programma analizzerà in profondità la struttura interna del disco virtuale e troverà i dati eliminati o persi. Nel nostro caso, si tratta di un insieme di file di test. Grazie alla funzione di anteprima, è possibile valutare visivamente l’integrità di documenti e foto direttamente prima del recupero.
Dopo aver verificato la correttezza delle informazioni trovate, selezionare i file richiesti, fare clic sul pulsante Recupero e salvarli sul disco locale del computer.

METODO 3. Recupero dei dati tramite snapshot
Un’altra potente funzionalità di Hetman RAID Recovery è il lavoro con gli snapshot, ossia acquisizioni dello stato del sistema.
Come abbiamo menzionato all’inizio del video, il formato qcow2 memorizza tutti gli snapshot all’interno di un unico file. Quando tale disco virtuale viene montato, il programma trova automaticamente tutti gli snapshot in esso contenuti e li visualizza come unità collegate separate nell’elenco generale.

Ciò rende facile recuperare i dati da stati precedenti del sistema. Ad esempio, se un file importante è stato modificato o completamente eliminato e non esiste più nella versione operativa corrente della macchina virtuale, è possibile semplicemente tornare a uno snapshot più vecchio. Selezionare lo snapshot richiesto nell’elenco e avviare l’algoritmo Scansione rapida.

Il programma ne analizzerà la struttura e troverà le versioni precedenti dei file. Dopodiché, sarà sufficiente verificare visivamente i dati trovati, selezionare i file necessari e salvarli su un disco locale sicuro utilizzando il pulsante Recupero.

Conclusione
Il recupero di dischi virtuali KVM e snapshot in Red Hat Enterprise Linux 7.9 richiede la comprensione dell’architettura di virtualizzazione, della struttura di archiviazione e del modo in cui i dati sono memorizzati. A seconda della configurazione della macchina virtuale, il suo disco può essere rappresentato da un file QCOW2 o RAW collocato su un file system, oppure da un volume logico LVM. Ciò determina la scelta degli strumenti e la sequenza delle operazioni durante il recupero.
Se la macchina virtuale non si avvia più, il disco è stato eliminato accidentalmente oppure uno snapshot è danneggiato, il primo passo consiste nell’identificare la causa del problema e verificare la disponibilità dei dati originali. Occorre prestare particolare attenzione agli snapshot QCOW2 esterni, poiché collegamenti interrotti tra l’immagine di base e le immagini figlie possono comportare la perdita di accesso allo stato corrente del disco virtuale. Quando si utilizza LVM, è necessario controllare lo stato dei volumi fisici, dei gruppi di volumi e dei volumi logici senza modificarne inutilmente la struttura.
Per aumentare le probabilità di successo del recupero, si raccomanda di interrompere le scritture sul dispositivo di archiviazione danneggiato, evitare di eliminare i file residui degli snapshot e, se possibile, creare una copia settore per settore dell’unità o una copia di backup delle immagini. È possibile utilizzare software specializzati per il recupero dei dati per cercare i file persi, incluse le soluzioni di Hetman Software. Allo stesso tempo, il risultato dipende dal tipo di danno, dalle condizioni dell’unità e dal fatto che i dati persi siano stati sovrascritti.
Per ridurre al minimo il rischio di ulteriori perdite di dati, è opportuno creare regolarmente backup dei dischi virtuali e delle configurazioni delle macchine virtuali, verificare l’integrità dei backup e monitorare lo stato dei supporti di archiviazione. Gli snapshot devono essere utilizzati come mezzo per tornare a uno stato precedente, non come sostituto completo dei backup.

