Recupero dati VMware ESXI RAID #4017

Case ID #4017: Recupero dati VMware ESXI RAID

Un sistema RAID composto da 8 dischi fissi SAS montati su un server VMware ESXI, con 7 macchine virtuali, è stato reso inoperativo dal guasto di due dischi fissi.

Supporti ricevuti

Data di arrivo: 12 luglio 2016;
Dischi fissi (No. 8): Toshiba (Fujitsu) Mod. MK3001GRRB;

Informazioni e richieste comunicate dal cliente

I dischi fissi sono parte di un sistema RAID su server in configurazione RAID-5 hardware; I dischi No. 7 e 8 risultano essere “offline” e non accessibili dal server. I due dischi si sono guastati nell’arco di due giorni, ma non è noto in quale ordine.

Il sistema RAID è configurato su un server di rete con installato VMware ESXI ver. 5.5, sul quale sono residenti sette macchine virtuali con sistemi operativi della famiglia Windows Server in varie versioni, ognuna delle quali con uno o più dischi virtuali “Flat” e/o ad “allocazione dinamica”, alcuni con uno o più “snapshot” (definiti anche file di differenze o file Delta).

Le macchine virtuali ospitano varie applicazioni con i relativi motori di database SQL installati (Microsoft SQL Server ed Oracle), altre contengono cartelle condivise con file e documenti di vario tipo.

È fondamentale recuperare non solo file e database ma, possibilmente, tutte le  macchine virtuali presenti, integre ed avviabili. Non esiste alcuna copia di backup dei dati.

Livello Raid: Raid-5 hardware;
Sistema operativo Host: VMware ESXI versione 5.5;
Partizioni/File system: Una, circa 2 TB;
Macchine viruali (VM) presenti: 7
Sistemi operativi Guest: Windows Server 20xx, varie versioni;
Cartelle da recuperare: No. 7 macchine virtuali in 7 diverse cartelle della root;
Stima (indicativa) dei dati presenti: 1.000~1.500 GB circa.

La diagnosi

Dischi Nn. 1-6
L’esame dei dischi fissi non ha evidenziato particolari problemi di funzionamento e sono risultati essere operativi ed accessibili. La copia binaria integrale dei settori (512 byte ognuno) è stata effettuata positivamente e senza errori su quattro dei sei dischi.

Su due dischi sono state rilevate una o più zone con in totale alcune centinaia di settori danneggiati, quasi totalmente corretti dalle successive ripetute letture effettuate. Nel dettaglio, dal disco No. 3 risultano essere illeggibili 4 settori mentre il disco No. 6 ne conta 2. Il contenuto dei settori non letti è stato quindi posto a zero (valore binario 0x00). I numeri dei settori non leggibili di ogni disco sono memorizzati in una tabella che verrà utilizzata in fase di ricostruzione del volume RAID dal tool software  BW_RaidRebuilder, di nostra realizzazione ed esclusiva proprietà. Grazie a questo tool è possibile rideterminarne il contenuto originario dei settori non letti in base alle informazioni di parità presenti sugli altri dischi, e mapparne la collocazione all’interno del file system del volume logico ricostruito.

Disco No. 7
L’esame del settimo disco ha evidenziato problemi di malfunzionamento delle testine, ed è quindi risultato essere non operativo e, di conseguenza, inaccessibile.

Disco No. 8
L’esame dell’ottavo disco ha evidenziato gravi problemi ai cuscinetti interni e, pur essendo parzialmente operativo, risulta essere anch’esso inaccessibile. L’esame interno del disco, effettuato in ambiente con atmosfera controllata in “classe 100”, non ha evidenziato danni né alle testine né sulle superfici del disco.

ESITO DELLa diagnosi

L’esame dei primi sei dischi  ha confermato la presenza di uno schema RAID fault-tollerant. Non essendo accessibile il contenuto delle unità No. 7 e No. 8 per effettuare i dovuti riscontri, si può presumere corretta una configurazione del sistema con schema Raid-5, composta dagli 8 dischi per un totale di 2.1 TB utilizzabili, coerente con le informazioni rilevate dalla tabella di partizioni (MBR) presente sul disco No. 1.

Non essendo il cliente in grado si segnalare quale disco (il No. 7 o il No. 8) è stato escluso per primo dal sistema si rende necessario il recupero del contenuto di entrambi per poter ricostruire il volume logico, sulla base di tre possibili combinazioni, delle quali solo una risulterà essere valida e coerente:

Combinazione 1: Dischi No. 1-2-3-4-5-6-7, con ricostruzione del No. 8 in base alla parità;
Combinazione 2: Dischi No. 1-2-3-4-5-6-8, con ricostruzione del No. 7 in base alla parità;
Combinazione 3: Improbabile, dischi No. 1-2-3-4-5-6-7-8, con verifica delle parità;

Su queste basi, in data 13 luglio è stato formulato il preventivo per il recupero dei dati, sottoposto al cliente e dallo stesso accettato in data 19 luglio con formula “Urgente”.

LE OPERAZIONI DI RECUPERO DEI DATI

Le operazioni di recupero a livello fisico sono state effettuate sui dischi No. 7 e No. 8, il cui contenuto non era accessibile, a causa di guasti a componenti hardware degli stessi. L’apertura dei dischi è stata effettuata presso i nostri laboratori, in ambiente idoneo con atmosfera controllata in “classe 100”. Le operazioni di sostituzione del gruppo testine del disco No. 7 e di sblocco del motore effettuata sul disco No. 8 sono state completate con successo ed è stata ripristinata l’accessibilità al contenuto delle due unità.

Le operazioni di copia del disco No. 7 si sono concluse con la lettura quasi totale, con soli 15 settori illeggibili, nonostante la persistenza di serie problematiche relative ad una superficie che hanno protratto le operazioni per circa 16 ore. L’esito delle operazioni effettuate sul disco No. 8, nonostante i gravi problemi ai cuscinetti che ne impedivano la piena operatività con un funzionamento intermittente, hanno consentito l’accesso ai dati presenti e la lettura è stata effettuata con successo, sia pure con 43 settori rimasti illeggibili. La tabella con l’elenco dei settori non leggibili dalle unità è stata quindi aggiornata per procedere alla ricostruzione tramite il nostro tool software BW_RaidRebuilder.

Sulla base delle analisi effettuate su blocchi di settori letti dai dischi è stato determinato lo schema RAID-5 con i corretti parametri di ricostruzione (stripe size, schema di distribuzione delle parità etc), da applicare alla combinazione No. 1 che è risultata essere la sola valida, in quanto è stato possibile determinare che il disco No. 8 era stato escluso dall’array a causa del guasto prima del disco No. 7.

Il volume logico di 2.1 TB è stato quindi totalmente ricostruito su file con il contenuto di sette dischi in base alla combinazione No. 1 rideterminando, per i soli settori risultati illeggibili (presenti sui dischi No. 3, 6 e 7), il contenuto originario sulla base delle informazioni di parità presenti su tutte le unità.

Il controllo del volume logico ricostruito ha evidenziato la presenza della partizione con file system VMFS di dimensione coerente con le dimensioni del volume e con le indicazioni del cliente. Il controllo del file system ha dato esito positivo, risultando essere integro, terminando senza segnalazione di errori.

Tutti i file e le cartelle presenti nella partizione VMFS sono quindi stati estratti e copiati su un nuovo supporto. L’analisi della tabella relativa ai settori risultati illeggibili e ricostruiti ha consentito al nostro software di determinare la collocazione di tali settori all’interno del volume VMFS ricostruito. Gli stessi sono risultati essere riferiti quasi totalmente a zone non allocate e in tre soli casi interessare file di log di VMware, non importanti né ai fini del recupero, né per il corretto funzionamento delle relative macchine virtuali.

I file e le cartelle così estratti sono stati analizzati e, nel dettaglio, sono risultate essere presenti tutte e sette le VM con i relativi dischi virtuali, come indicato e richiesto dal cliente (per questioni di riservatezza tutti i nomi dei file e delle cartelle sono stati troncati “(omissis)”):

1. Cartella VM “\AGE(omissis)”
   Un disco virtuale da 100 GB, nessuno snapshot;
2. Cartella VM “\Doc(omissis)”
   Un disco virtuale “Doc(omissis)-flat.vmdk”, 32 GB, con 1 snapshot da 7 GB;
   Un disco virtuale “Doc(omissis)_1-flat.vmdk”, 10 GB, con 1 snapshot da 3 GB;
3. Cartella VM “\mag(omissis)”
   Tre dischi virtuali da 73 GB, 4 snapshot ognuno per un totale di 87 GB;
   Un disco virtuale da 147 GB, con 4 snapshot, per un totale di 87 GB;
4. Cartella VM “\min(omissis)”
   Tre dischi virtuali  da 73 GB, nessuno snapshot;
5. Cartella VM “\Sha(omissis)”
   Un disco virtuale da 97 GB, con 2 snapshot per un totale di 45 GB;
6. Cartellla VM “\Srv(omissis)”
   Un disco virtuale da 65 GB, con 4 snapshot per un totale di 4 GB;
7. Cartella VM “Web(omissis)”
   Un disco virtuale da 68 GB, con 1 snapshot da 19 GB.

Con il consenso del cliente a procedere sono stati effettuati dei test di utilizzabilità su una ulteriore copia dei file trasferiti su una nostra postazione di verifica predisposta con il software VMware che, senza peraltro fornire indicazioni dettagliate del problema, ha impedito il montaggio e l’avvio di cinque macchine virtuali. Le VM interessate sono risultate essere le cinque dove sono presenti degli “snapshot”. Le restanti due VM sono risultate essere avviabili ed operative, sia pure con la segnalazione di problemi minimi sul file system (risolti da Windows all’avvio) e con l’avviso di un arresto imprevisto del sistema visualizzato al momento dell’accesso.

Le nostre procedure di recupero di macchine virtuali VMware prevedono una ulteriore fase di verifica dell’integrità dei file, tramite l’analisi effettuata dal software “VM_VmdkCheck” da noi sviluppato, che ha evidenziato la seguente situazione (riportiamo, a titolo esemplificativo, quella relativa ad una sola macchina virtuale):

 
Il controllo dei volumi FLAT di VMware (che sono delle esatte copie binarie su file di un disco fisico) è stato eseguito effettuando il montaggio in sola lettura da sistema operativo dei dischi virtuali. Il controllo delle partizioni presenti, risultate essere tutte del tipo NTFS (il file system utilizzato da Windows) è stato effettuato sia con gli strumenti di Windows stessi (chkdsk) che con appositi software dedicati. Tutte le partizioni presenti sui dischi virtuali FLAT con snapshot (e quindi “congelate” al momento della creazione degli snapshot da VMware) sono risultate integre e i file system coerenti senza segnalazione di errori. Le altre partizioni dei dischi virtuali FLAT attivi (senza snapshot) hanno riportato problemi minimi, dovuti con molta probabilità al blocco del server durante il loro funzionamento.

Le segnalazioni di “uncleanShutdown” hanno reso necessario procedere con la riparazione e compattazione su volumi FLAT dei file di differenze (snapshot o Delta) di tutte le macchine virtuali, effettuata con il software “VM_VmdkRebuild” da noi sviluppato. Il risultato dell’operazione è stato positivo e non sono state segnalate situazioni non risolte (come da un estratto del log generato per una VM che riportiamo):

 
Il processo completo di ricostruzione di tutti i dischi virtuali ha richiesto circa 12 ore di elaborazione per unire tutti gli snapshot sui relativi file FLAT ed è avvenuto senza segnalazione di errori rilevanti o non risolvibili.

Si è proceduto quindi con la produzione di una ulteriore copia sulla nostra postazione di verifica per il controllo di integrità ed avviabilità di tutte le macchine virtuali, che sono state in questo caso correttamente montate ed avviate dal programma VMware Workstation, consentendo l’accesso al sistema. Le verifiche di integrità di file e database oltre che di funzionalità delle applicazioni presenti hanno dato anch’esse esito positivo.

Le cartelle con le macchine virtuali (sia quelle originariamente recuperate che quelle con i dischi virtuali ricostruiti) sono state copiate su due nuovi supporti e sono stati inviati al cliente gli elenchi dei file recuperati con tutti i report di controllo relativi ai database e alle applicazioni presenti sulle singole macchine virtuali.

In data 25 luglio è stata emessa la fattura relativa al servizio e ai nuovi supporti forniti (dischi USB di adeguata capacità) ed effettuata la spedizione alla sede del cliente.

CONCLUSIONI

L’approccio di TheRecovery al problema, che ha consentito il recupero dei dati, ha permesso al cliente di riattivare velocemente (in 4 gg lavorativi) l’operatività del proprio server, che è stato ripristinato interamente con le VM aggiornate al momento del guasto, senza che si sia verificata la benché minima perdita di dati.

Nel rivolgersi a noi per il recupero dei propri dati, il cliente ha sempre avuto la garanzia di non dover sostenere il costo del servizio di recupero qualora i volumi virtuali fossero risultati non essere utilizzabili per il ripristino dell’operatività delle proprie macchine virtuali.

Parole chiave recupero dati

Recupero dati RAID RAID-5 Recupero dati Macchine Virtuali VM
Recupero dati VMware Recupero dati Hyper-V VMware ESXI Windows Server