Recupero dati da disco virtuale VMDK e VHDX

Un disco virtuale può dipendere da descrittore, extent, snapshot e file parent: consolidare la catena sbagliata crea blocchi incoerenti.

Richiedi un preventivo

Inventario della macchina virtuale, dell’hypervisor e della catena di snapshot disposto sui monitor accanto al server fermo

Sintomo

Inventariare ogni componente del disco virtuale

VMDK può separare descrittore ed extent; VHDX e QCOW2 conservano metadati e mappe proprie.

Prima del recupero dati si registrano file, percorsi, UUID, dimensioni e riferimenti.

Un singolo file grande non rappresenta necessariamente lo stato attivo.

L’inventario conserva nomi originali, struttura delle cartelle, dimensione logica e fisica, data di modifica e hash quando calcolabile senza alterare il datastore. Per VMware si raccolgono descrittori, flat o sparse extent, delta, file VMX e log; per Hyper-V configurazione, VHDX e AVHDX; per QCOW2 backing file e metadati disponibili. Un export già incompleto non sostituisce la sorgente: anche file piccoli possono contenere la mappa che collega blocchi e snapshot.

Si identifica inoltre dove risiede ogni componente: datastore locale, SAN, NAS, replica o backup. Un percorso mancante può essere un mount non disponibile, non un file cancellato. Versione dell’hypervisor, operazioni recenti, migrazioni, backup interrotti e consolidamenti falliti aiutano a ordinare gli eventi. Se esistono copie con nomi simili, non vengono rinominate per comodità prima dell’analisi. Il rapporto fra file vale più dell’ultima data mostrata dal sistema operativo.

Un manifest separa sorgenti originali, copie di sicurezza e file esportati dopo il guasto. Percorso, dimensione e hash impediscono che due delta omonimi vengano confusi durante il trasferimento. Per i file sparse si registra anche lo spazio fisicamente allocato, perché un normale archiviatore può espanderli o omettere aree significative. Questa inventariazione rende ripetibile la ricostruzione su un’altra stazione di lavoro.

Conservare nomi, percorsi, UUID e dimensioni senza rinominare i file
Distinguere sorgenti originali, esportazioni successive e copie di backup
Registrare hypervisor, datastore e operazioni eseguite prima del guasto

Descrittore ed extent

Il descrittore collega capacità, geometria e file di blocchi. Anche un elemento molto piccolo può essere indispensabile per interpretare correttamente l’extent principale.

Snapshot e configurazione

Delta, AVHDX, backing file e log ricostruiscono la cronologia. I file di configurazione aiutano a legare dischi, controller virtuali e macchina corretta.

Un file virtuale di grandi dimensioni può essere soltanto la base: descrittori, delta e configurazione determinano quale stato sia davvero attivo.

Macchina virtuale arrestata con consolidamento automatico sospeso sulla copia del datastore

Prima mossa

Fermare avvii e consolidamenti automatici della VM

Ogni boot scrive log, journal e dati applicativi nel layer corrente.

Un merge forzato può fissare una relazione sbagliata.

Il datastore viene congelato o duplicato e soltanto la copia diventa area di lavoro.

La VM viene arrestata in modo coerente con lo stato dell’incidente e non riaperta per controllare se ‘parte ancora’. Snapshot automatici, replica, backup e politiche di consolidamento vengono sospesi affinché non creino nuovi delta. Se lo storage è instabile, prima si protegge il livello fisico o RAID sottostante. Una copia di sicurezza deve includere tutti i file collegati e preservare la mappa di allocazione dei file sparse. Uno strumento non adatto può espandere l’allocazione fisica oppure omettere file o metadati della catena; dimensione logica e riferimenti devono restare invariati.

Non forzare il consolidamento degli snapshot sul datastore originale
Copiare descrittori, delta, extent e parent con i loro nomi
Non riavviare la VM prima della messa in sicurezza

L’ambiente originale resta in sola lettura quando possibile

Correzioni di descrittori, CID, UUID o parent locator vengono provate soltanto su duplicati indipendenti. Uno strumento di gestione può aggiornare automaticamente header e log appena apre il disco; per questo l’ispezione iniziale usa metodi che non montano in scrittura il guest. Anche un clone apparentemente riuscito viene verificato con hash e dimensioni prima di diventare la base delle prove.

Il blocco è documentato con orario e responsabile

Se la VM appartiene a un cluster, anche HA e orchestrazione vengono sospesi: potrebbero riavviarla su un altro host o creare nuove operazioni di storage. Log volatili vengono acquisiti soltanto quando non richiedono il mount in scrittura della sorgente. La conservazione dello stato precede ogni tentativo di disponibilità.

Catena di snapshot con file parent e delta, UUID e identificatori di contenuto confrontati sui monitor

Tecnica

Riordinare parent, child e snapshot con prove tecniche

Delta e differencing disk indicano un predecessore.

CID, UUID, header e log aiutano a ricostruire la linea temporale.

Riferimenti mancanti non vengono corretti alla cieca: si confrontano più montaggi su copie indipendenti.

La catena può avere rami, snapshot eliminati solo dal catalogo o delta creati da backup e replica. Ogni child viene associato al parent atteso confrontando identificativi, capacità virtuale, geometria, blocchi modificati e log dell’hypervisor. Un file più recente non è automaticamente il figlio corretto. Se due rami rappresentano stati diversi, vengono mantenuti separati e valutati rispetto all’orario dell’incidente, senza fondere modifiche incompatibili in un’unica immagine.

Per ciascuna ipotesi si genera una vista temporanea e si controllano strutture che attraversano molti blocchi: partizioni, superblock, directory, journal e file noti. Una catena sbagliata può mostrare il desktop e fallire solo su database o file aggiornati di recente. Le modifiche necessarie per rendere leggibile un descrittore vengono documentate e restano fuori dai file sorgente. Coerenza dei metadati e contenuto reale devono confermare la relazione.

Quando mancano identificativi affidabili, i blocchi modificati vengono confrontati con più parent candidati. Header di file, record del journal e sequenze applicative rivelano incongruenze che un semplice mount non mostra. Solo la variante che supera controlli distribuiti procede alla validazione del guest e delle applicazioni. Ogni ramo conserva un nome tecnico distinto e il relativo grado di fiducia.

Associare ogni child al parent tramite identificativi e capacità virtuale
Confrontare partizioni, journal e file noti per ogni ipotesi
Mantenere separati i rami che rappresentano momenti incompatibili

Relazione parent-child

Identificativi, geometria e blocchi modificati devono concordare. Data e dimensione del file, isolate, non dimostrano che un delta appartenga a quella base.

Rami alternativi

Snapshot concorrenti vengono montati su copie indipendenti e confrontati con eventi noti. Nessun ramo viene fuso automaticamente per creare uno stato apparentemente recente.

Un delta piccolo contiene soltanto le differenze. Associarlo a una base errata può produrre una VM che parte ma combina dati appartenenti a momenti diversi.

Metadati di VMDK e VHDX, file sparse e mappa dei blocchi allocati esaminati in un editor tecnico

Diagnosi

Interpretare thin provisioning, sparse file e blocchi mancanti

Un disco sottile non occupa fisicamente ogni settore logico.

Dopo un guasto storage, mappe di allocazione e extent possono essere danneggiati.

La diagnosi distingue spazio mai allocato da blocchi persi e verifica il livello RAID sottostante.

Nei formati sparse o thin, un blocco assente può significare zero logico, area mai scritta, trim del guest oppure perdita della mappa. Header, tabelle di allocazione e bitmap determinano quale interpretazione è corretta. Riempire ogni buco con zeri può far montare il volume ma nascondere dati realmente mancanti; trattare ogni zero come perdita produce invece falsi allarmi. La ricostruzione mantiene una mappa delle aree certe, non allocate e non disponibili.

Il file virtuale dipende dal supporto che lo ospita

Errori in un RAID, deduplicazione, compressione, cifratura del datastore o snapshot dello storage possono interrompere extent in punti diversi. Prima di lavorare sul guest si verifica quindi la continuità del livello sottostante. Per datastore cifrati servono chiavi e configurazione autorizzate; copiare soltanto i file visibili dopo un montaggio parziale può escludere metadati indispensabili. La diagnosi collega perdita fisica, mappa virtuale e struttura interna senza confondere i tre livelli.

La loro assenza non equivale a un extent perso per guasto

UNMAP o TRIM del guest può essere propagato al formato virtuale e allo storage, rendendo non disponibili blocchi liberati. Viceversa, una tabella sparse danneggiata può descrivere come vuota un’area precedentemente allocata. Log del sistema e mappe ridondanti aiutano a distinguere i casi, ma non ricreano contenuto già eliminato.

Copia di un disco virtuale montata in sola lettura in un ambiente isolato senza avviare il sistema guest

Ricostruzione

Aprire il file system guest soltanto dopo la catena

Una VM può montarsi pur combinando snapshot incompatibili.

Solo uno stato coerente viene esaminato per NTFS, ext, XFS o altri formati.

Journal e metadati mostrano se le directory appartengono allo stesso momento.

Dopo aver definito la catena, il volume guest viene aperto in sola lettura o tramite una copia derivata. Partizioni, LVM, software RAID interno, BitLocker o LUKS possono aggiungere altri livelli. Le chiavi valide vengono gestite separatamente e non sostituite con tentativi distruttivi. Strumenti come fsck o chkdsk vengono riservati a copie sacrificabili, perché possono scartare record e modificare il journal. Prima si preservano metadati e file prioritari nello stato ricostruito.

Directory apparentemente corrette possono puntare a blocchi provenienti da un altro snapshot. Timestamps, journal e identificativi dell’applicazione aiutano a riconoscere questi conflitti. Quando una catena consente solo un recupero parziale, i file integri vengono estratti senza obbligare l’intero sistema operativo ad avviarsi. Il risultato distingue copia di file, volume montabile e macchina virtuale realmente utilizzabile. La coerenza viene verificata con file distribuiti nel volume e aggiornati in momenti diversi.

Un volume cifrato coerente può sembrare rumore se viene valutato senza il relativo materiale. Le chiavi vengono gestite separatamente dal manifest e non inserite in messaggi non protetti. Se mancano, la catena può essere preservata, ma contenuto e applicazioni non sono automaticamente validabili. Per BitLocker, LUKS o cifratura applicativa servono chiavi e credenziali valide del titolare.

Aprire partizioni e volumi guest tramite una copia in sola lettura
Confrontare journal, directory e identificativi in punti distribuiti
Separare volume montabile, file recuperati e VM realmente utilizzabile

Il file più recente non è sempre lo stato giusto

UUID, riferimenti parent, sequenza e log del hypervisor determinano la catena. Dimensione e data di modifica, da sole, non bastano.

Cifratura del guest

BitLocker, LUKS e protezioni applicative richiedono chiavi valide. Il materiale di accesso viene gestito separatamente e non corretto con tentativi distruttivi.

Una VM che mostra il desktop può contenere blocchi di snapshot incompatibili; database, journal e file recenti devono confermare lo stesso stato.

Database e registri applicativi della macchina virtuale verificati su monitor in un laboratorio isolato

Priorità

Validare database e servizi oltre la semplice copia

Controller di dominio, database e server di posta richiedono file dati, log e configurazioni allineati.

Datastrophe verifica se è possibile un export coerente o una riparazione controllata.

Quando non lo è, il recupero parziale viene descritto con chiarezza.

Per database si confrontano datafile, transaction log, checkpoint e backup rispetto al punto scelto. L’avvio del sistema operativo non certifica la consistenza dell’applicazione. Su una copia isolata si usano i meccanismi nativi per ripristino o esportazione, evitando riparazioni che eliminino pagine senza renderlo esplicito. Mailstore e directory vengono controllati con conteggi, indici e campioni. Se mancano dipendenze esterne o chiavi, il limite accompagna i file consegnati.

La priorità viene definita per servizio, periodo e risultato atteso

Talvolta è più sicuro esportare tabelle, caselle o documenti da uno stato parzialmente coerente che tentare di riaccendere l’intera VM. Per server applicativi si raccolgono anche configurazioni, certificati e file di licenza necessari alla migrazione in un ambiente pulito. Un referente funzionale verifica record, messaggi o documenti significativi, non soltanto la presenza di cartelle e dimensioni plausibili.

I test usano una rete segregata e un piano applicativo

Controller di dominio e sistemi cluster richiedono particolare cautela: avviare una copia isolata con rete attiva può generare conflitti di identità o replica. Quando basta recuperare dati, si preferisce l’export offline. La rimessa in servizio resta una fase separata con nuove credenziali, patch e controlli di sicurezza.

Tecnico confronta versioni ricostruite del disco virtuale e mappa dei blocchi mancanti

Limiti

Scegliere il punto di ripristino in base all’incidente

Lo snapshot più recente può già contenere la corruzione.

Data dell’errore, backup e transazioni importanti aiutano a scegliere il punto utile.

Stati diversi possono essere prodotti e confrontati senza modificare la catena originale.

Gli snapshot non sostituiscono un backup indipendente: condividono datastore e spesso la stessa causa di guasto. Si definiscono l’ultimo momento sicuramente valido, la perdita temporale accettabile e le operazioni critiche da preservare. Un ramo più vecchio può essere coerente ma incompleto; uno nuovo può contenere dati recenti e corruzione. I due risultati vengono confrontati con criteri applicativi e non fusi automaticamente. La scelta finale resta documentata e reversibile sulle copie.

La consegna può comprendere più punti quando nessuno soddisfa ogni requisito: per esempio una VM stabile precedente e un export di file recenti dal ramo danneggiato. Ogni output riporta sorgente, catena, data stimata e test eseguiti. Questa composizione esplicita è preferibile a una sola immagine che nasconde blocchi provenienti da momenti incompatibili e potrebbe fallire dopo il primo avvio. Elementi mancanti o non verificabili restano separati.

Il referente approva il punto scelto con prove note: una transazione, un messaggio, un documento recente o una configurazione attesa. La decisione non modifica gli originali, quindi un secondo controllo rimane possibile. Successivamente il risultato viene inserito in un nuovo schema di backup, invece di conservare snapshot incidentati come unica protezione. Differenze fra rami vengono annotate prima della chiusura.

Dipendenze parent-child ricostruite
Stato coerente nel tempo ricostruito su una copia
File e applicazioni guest verificati

Punto stabile

Un ramo precedente può offrire una macchina coerente e avviabile. Il referente verifica che transazioni, messaggi e configurazioni corrispondano al momento dichiarato.

Recupero composito

Quando nessun ramo soddisfa tutto, una VM stabile può essere affiancata da file recenti estratti altrove. Provenienza e limiti restano espliciti.

Il punto più recente non è sempre il migliore: la scelta deve bilanciare coerenza, perdita temporale accettabile e dati applicativi prioritari.

Datastore e storage fisico acquisiti su una stazione di imaging prima dell’analisi dei file VMDK e VHDX

Orientamento

Collegare VMDK e VHDX allo storage che li ospita

Se il datastore proviene da un array guasto, si parte dal recupero RAID e NAS.

Sistemi operativi e applicazioni sono approfonditi nel recupero server.

Per la diagnosi serve l’elenco completo, non soltanto uno screenshot del messaggio di errore.

La richiesta include piattaforma e versione, elenco dei file con percorsi e dimensioni, configurazione della VM, cronologia di snapshot, backup o migrazioni e servizio prioritario. Si conservano anche log ed errori senza riavviare l’ambiente per produrne di nuovi. Se i file possono essere trasferiti in sicurezza, si usano copie verificate; se lo storage fisico è instabile, viene prima acquisito. Credenziali e chiavi non vengono inserite in e-mail non protette.

La VM danneggiata non viene rimessa in produzione come unica copia

Gli output sono forniti su storage sano o tramite trasferimento cifrato concordato. Manifest e checksum aiutano a verificare file molto grandi; formati sparse vengono copiati con strumenti che ne preservano la semantica. Un referente controlla applicazioni e dati prioritari in rete isolata, poi integra il risultato in un nuovo sistema di backup. Conservazione e cancellazione delle copie di lavoro seguono gli accordi dopo l’accettazione.

Un semplice screenshot dell’errore non sostituisce descrittori, log e catena

Se il trasferimento avviene dall’Italia tramite supporti fisici, i dischi che ospitano il datastore vengono spenti, etichettati e imballati contro urti; i file digitali viaggiano cifrati con chiave separata. Il laboratorio determina se servono i media originali o copie complete e verificate.

Domande frequenti

Quali file servono per ricostruire un disco virtuale VMDK o VHDX?

Occorrono descrittore, extent o file dati, snapshot, delta e configurazione della macchina virtuale disponibili. Anche nomi originari e struttura del datastore sono utili per ordinare correttamente parent e child senza affidarsi alle sole date.

Perché non bisogna avviare o consolidare la macchina virtuale danneggiata?

L’avvio scrive nel disco guest e può creare nuovi delta, mentre il consolidamento modifica la catena degli snapshot. Prima si congela l’insieme, si preserva il supporto originale, si inventariano hash, dimensioni e dipendenze e si lavora su copie.

Che cosa significa recuperare un disco virtuale thin provisioned?

Un disco thin contiene soltanto i blocchi allocati: un’area mai allocata non equivale a un file realmente mancante. La ricostruzione confronta metadati, extent e storage sottostante per distinguere blocchi mai allocati da componenti perduti.

Come si verifica un database recuperato da una macchina virtuale?

Montare il volume o vedere i file non basta. Dati, log e configurazioni devono essere coerenti tra loro; quando possibile si esegue un export controllato o un controllo applicativo sulla copia ricostruita.

Supporti

Altre competenze

Diagnosi

Dubbi su un supporto o su un guasto?

Datastrophe valuta il rischio prima di ogni intervento e indica il percorso più prudente.

Richiedi una diagnosi