Come recuperare dischi virtuali e snapshot KVM/QEMU con LUKS2 RAID 6
-
Autore:
Anton Kryvoruchko
-
Editore:
Mykhailo Miroshnichenko
Questo articolo esamina il ripristino di dischi virtuali e snapshot KVM/QEMU da un sistema di archiviazione basato su LUKS2 e RAID 6. L’attenzione è rivolta alla determinazione della corretta sequenza di ripristino, alla gestione sicura delle immagini dei dischi fisici, alla ricostruzione dell’array RAID, allo sblocco del contenitore cifrato, all’individuazione delle immagini QCOW2/RAW, all’analisi della catena di backing e al ripristino dell’accesso ai dati della macchina virtuale senza modificare il supporto originale.
- FASE 1. Creazione di una macchina virtuale KVM/QEMU
- FASE 2. Creazione di uno snapshot ed eliminazione della partizione LUKS2
- FASE 3. Collegamento dei dischi e avvio del ripristino
- FASE 4. Rilevamento automatico delle partizioni MD RAID 6 e LUKS2
- FASE 5. Analisi della partizione LUKS2 e ripristino dei file della macchina virtuale
- FASE 6. Montaggio di dischi virtuali e snapshot
- FASE 7. Confronto degli stati del disco e recupero dei file da uno snapshot
- FASE 8. Ricerca dei dati in base ai file system dei dischi virtuali
- Riepilogo
- Domande frequenti
- Commenti
Negli ambienti server moderni, la virtualizzazione basata su KVM/QEMU viene spesso utilizzata insieme ad array RAID software e alla cifratura dei dischi. Questa architettura combina prestazioni, tolleranza ai guasti e protezione dei dati, ma complica notevolmente il ripristino quando unità, metadati RAID, contenitore LUKS2, file system o la catena di snapshot della macchina virtuale risultano danneggiati.
Particolarmente complessi sono i casi in cui i dischi virtuali KVM/QEMU in formato QCOW2, RAW o altri formati compatibili sono memorizzati all’interno di un volume LUKS2 cifrato costruito su RAID 6. In una configurazione del genere, l’accesso ai dati dipende simultaneamente da più livelli: dischi fisici, struttura dell’array RAID, integrità dei metadati LUKS2, file system e struttura interna dei dischi virtuali.
Ulteriore complessità è introdotta dagli snapshot QEMU/KVM. Essi possono formare una catena di file QCOW2 dipendenti, in cui ciascuna immagine successiva contiene solo i blocchi modificati e fa riferimento al disco base o allo snapshot precedente. La perdita di un elemento di tale catena, il danneggiamento del file di backing o la determinazione errata della sequenza possono impedire l’avvio della macchina virtuale anche se la maggior parte dei dati è ancora fisicamente presente sui dischi.
Come recuperare un database MySQL eliminato da RAID 6 + LUKS2 (Ubuntu)
FASE 1. Creazione di una macchina virtuale KVM/QEMU
Per i test, abbiamo installato Ubuntu Server 24.04 e utilizzato Cockpit per creare un array software Linux MD RAID 6 composto da quattro dischi.
Sull’array RAID sono state create tre partizioni. Ognuna è stata cifrata con LUKS2 e all’interno dei contenitori cifrati sono stati creati file system Ext4. La terza partizione è stata utilizzata per memorizzare la macchina virtuale.
Il server eseguiva l’hypervisor KVM/QEMU. Tramite Cockpit abbiamo creato un pool di archiviazione separato per la macchina virtuale sulla terza partizione – raid6-vm-images. I file della macchina virtuale sono stati memorizzati nella directory vm-images.
Per la macchina virtuale abbiamo creato un disco di sistema QCOW2 con capacità di 32 gigabyte, oltre a due dischi aggiuntivi: un disco QCOW2 da 2 gigabyte e un disco IMG da 1 gigabyte.
Su disco di sistema è stato installato Windows 10. I due dischi aggiuntivi sono stati formattati in Windows rispettivamente come NTFS e FAT32.
FASE 2. Creazione di uno snapshot ed eliminazione della partizione LUKS2
Abbiamo copiato un set iniziale di file sul disco di sistema e sui due dischi aggiuntivi, quindi abbiamo creato uno snapshot esterno. Successivamente abbiamo aggiunto un’altra cartella con file ed eliminato alcuni di essi.
Dopo aver completato le modifiche di test, la macchina virtuale è stata arrestata. Successivamente, la cartella vm-images contenente le immagini del disco base, i file dello snapshot esterno e il file dello stato della memoria è stata copiata nella seconda partizione LUKS2 dell’array RAID.
Per simulare la perdita di dati, abbiamo utilizzato Cockpit per eliminare questa partizione dalla tabella delle partizioni. Di conseguenza, la sua area è diventata non allocata. Non l’abbiamo formattata né vi abbiamo scritto nuovi dati, per preservare la possibilità di un successivo ripristino.
FASE 3. Collegamento dei dischi e avvio del ripristino
Dopo aver eliminato la partizione, abbiamo spento il server e rimosso i dischi dell’array RAID. Solo due dei quattro dischi sono stati collegati a un computer con Windows 11 tramite una docking station USB.
Se Windows richiede di inizializzare o formattare i dischi dopo il collegamento, assicurarsi di fare clic su Cancel. Non scrivere nuovi dati sui dischi e non eseguire operazioni di controllo o riparazione degli errori, poiché ciò può peggiorare il risultato del ripristino.
È anche possibile lavorare con i dischi in altri modi. Ad esempio, collegarli in remoto al software tramite SSH oppure montare immagini precedentemente create se non si desidera lavorare direttamente con i dischi originali.
FASE 4. Rilevamento automatico delle partizioni MD RAID 6 e LUKS2
Subito dopo l’avvio, Hetman RAID Recovery ha letto le informazioni di servizio dai due dischi collegati.
RAID 6 consente la mancanza di un massimo di due dischi. Poiché entrambi i dischi disponibili erano integri e le informazioni di servizio erano intatte, il programma ha ricostruito automaticamente l’MD RAID 6. I due dischi mancanti sono stati mostrati come Empty disk e l’array ha ricevuto lo stato Recoverable.
Nelle proprietà vengono mostrati il layout Left Synchronous P+Q, una dimensione del blocco di 512 KB, nonché le posizioni dei dischi, gli offset e le dimensioni.
Il programma ha trovato tre aree con cifratura LUKS2 sull’array. La prima e la terza partizione erano ancora presenti, mentre la seconda, eliminata, è visualizzata come spazio non allocato contrassegnato con LUKS.
FASE 5. Analisi della partizione LUKS2 e ripristino dei file della macchina virtuale
Fare doppio clic sull’area non allocata contrassegnata LUKS. Il programma richiederà di immettere una password o selezionare un file di chiave.
Dopo lo sblocco, il file system Ext4 diventerà disponibile. Quindi selezionare la modalità di analisi.
Si consiglia di iniziare con Fast Scan. Se la scansione rapida non trova i dati necessari, eseguire Full Analysis e specificare il file system Ext2/3/4.
Nel nostro caso, Fast Scan è stato sufficiente. Il programma ha ripristinato la struttura della partizione eliminata e ha trovato la cartella vm-images, che conteneva il disco di sistema e i dischi virtuali aggiuntivi, nonché i relativi file di snapshot.
È importante notare che la configurazione della macchina virtuale è memorizzata separatamente dai dischi, di norma nella directory /etc/libvirt/qemu. Se il file di configurazione XML viene perso, i dati dei dischi virtuali possono comunque essere recuperati, ma la configurazione della macchina dovrà essere ricreata per poter avviare di nuovo la VM.
Selezionare la cartella contenente i dischi virtuali e i file di snapshot e fare clic su Recovery.
Si consiglia di ripristinare l’intera cartella, in modo che le immagini base e gli snapshot correlati rimangano insieme.
Selezionare un altro disco fisico per il salvataggio. Non ripristinare i file sull’array RAID originale, poiché ciò potrebbe sovrascrivere dati ancora recuperabili.
FASE 6. Montaggio di dischi virtuali e snapshot
Se è necessario accedere ai dati all’interno dei dischi virtuali o degli snapshot, nonché individuare e recuperare i file eliminati, è possibile farlo direttamente nel nostro programma.
Fare clic su Mount Disk.
Nella finestra Disk Image Type, sotto Virtual Machine Disk Images, selezionare QEMU, poiché nel nostro test la macchina virtuale e i suoi dischi sono stati creati in base a KVM/QEMU. Se le immagini sono state create in un altro ambiente di virtualizzazione, selezionare il tipo di disco corrispondente dall’elenco. Quindi fare clic su Next.
Nella fase successiva, specificare non un singolo file immagine, ma la cartella in cui abbiamo recuperato tutti i file della macchina virtuale. È importante che i dischi base e gli snapshot correlati siano archiviati insieme e mantengano i nomi originali.
Il programma analizzerà il contenuto della cartella, determinerà le relazioni tra i file e raggrupperà automaticamente i dischi base con i relativi snapshot. Se per un disco sono stati creati più snapshot, il programma li disporrà nell’ordine corretto. Lo stato più recente di ciascuna catena verrà contrassegnato come Active. Selezionare i dischi richiesti e i relativi stati, quindi fare clic su Next.
Dopo il montaggio, appariranno in Mounted Disks come unità separate. Nella schermata principale, l’etichetta Active non viene più visualizzata, quindi il disco base e i relativi snapshot possono essere distinti dai nomi dei file corrispondenti.
FASE 7. Confronto degli stati del disco e recupero dei file da uno snapshot
Per confrontare l’immagine del disco base e il relativo snapshot, è necessario analizzare entrambi i dischi montati. Fare doppio clic su ciascuno di essi ed eseguire prima Fast Scan.
Se Fast Scan non trova i dati necessari, eseguire Full Analysis. Durante l’analisi completa, è necessario specificare il file system utilizzato all’interno del disco virtuale.
L’immagine base conserva lo stato precedente del file system.
Sul disco montato dallo snapshot sono visibili le modifiche successive: la cartella aggiunta e i file eliminati al suo interno, che il programma contrassegna con una X.
Poiché questi file sono stati scritti dopo la creazione dello stato precedente del disco, devono essere individuati e recuperati dallo snapshot montato.
Esaminare i file trovati nella finestra di anteprima, che supporta molti formati comuni. Qui è possibile visualizzare il contenuto dei documenti, gli elenchi dei file all’interno degli archivi, immagini, video e altri dati. L’anteprima può essere espansa a schermo intero, il che è particolarmente comodo per la revisione di immagini e registrazioni video.
Dopo aver verificato che i file richiesti siano selezionati, marcarli e fare clic su Recovery. Salvare i dati recuperati su un altro disco fisico.
FASE 8. Ricerca dei dati in base ai file system dei dischi virtuali
Se le immagini dei dischi virtuali richieste non sono state trovate o non possono essere montate, è possibile provare a recuperare i dati direttamente in base ai file system utilizzati all’interno di tali dischi.
Per farlo, selezionare la partizione RAID sbloccata, avviare la procedura guidata di recupero e scegliere Full Analysis.
Durante la configurazione dell’analisi, invece del file system Ext4 effettivamente utilizzato su questa partizione per memorizzare i file dei dischi virtuali, specificare i file system presenti direttamente all’interno dei dischi virtuali stessi. Nel nostro caso, si tratta di FAT32 e NTFS, quindi selezioniamo FAT e NTFS per la ricerca.
Questo metodo è più efficace per i dischi virtuali in cui l’intero spazio è stato preallocato in anticipo. In questo caso, i dati del disco virtuale sono fisicamente presenti all’interno del file immagine e il programma può individuare e analizzare il file system in esso memorizzato anche se il file immagine stesso è danneggiato o perso.
Per i dischi virtuali thin-provisioned, questo approccio di solito non consente un recupero completo del disco. In tali immagini, vengono memorizzati fisicamente solo i blocchi ai quali sono già stati scritti dati, mentre lo spazio inutilizzato non viene preallocato. Pertanto, senza la struttura dell’immagine stessa, i singoli blocchi del disco virtuale possono risultare frammentati e la ricostruzione corretta dell’intero file system è molto più difficile.
Dopo il completamento dell’analisi, esaminare le partizioni e i file trovati.
Questo metodo può aiutare a recuperare singoli dati o persino un file system da un disco preallocato, ma in questo modo non vengono recuperati il file immagine stesso e le sue relazioni con gli snapshot.
Riepilogo
Di conseguenza, Hetman RAID Recovery ha assemblato automaticamente il Linux MD RAID 6 a partire da due dischi disponibili, ha trovato la partizione LUKS2 eliminata, l’ha sbloccata e ha ripristinato la cartella con le immagini dei dischi e gli snapshot della macchina virtuale.
Dopo il montaggio, siamo stati in grado di confrontare lo stato del disco prima e dopo la creazione dello snapshot, individuare i dati necessari e recuperare i file eliminati successivamente. È importante conservare insieme tutte le immagini e gli snapshot correlati, non modificarne i nomi e ripristinare i dati solo su un altro disco fisico.
