Quando si ferma un NAS o un server, parliamo sempre di una situazione d’emergenza. Ma quando fallisce uno storage composto da 42 hard disk da 2 TB per uno spazio totale complessivo di 76 TB concatenati in modo contiguo grazie al raid 60, allora parliamo di una caso di estrema gravità ed importanza.
Vi proponiamo una storia di successo: il recupero dati su storage di 76 TB e 42 hard disk dopo l’ avaria di 3 HD , cosa che di fatto ha invalidato il raid 60.
Le ferie sono ormai alle porte e questo piovoso Agosto ha inizio con l’arrivo di un cliente che porta il suo storage.
Dopo diversi anni d’impeccabile servizio, l’apparato, in seguito ad un violento temporale, si è inaspettatamente fermato .
Si tratta di uno storage Series EP-4423S/D-F4S3, è prodotto dalla nota azienda taiwanese Proware by Unifosa e distribuito in Italia da Lead SRL.
Al primo sguardo riconosciamo la solidità e la qualità del prodotto, che grazie all’uso di schede Raid dedicate di Areca offrono affidabilita’ ed una vasta configurabilità di livelli raid . Nonostante ciò, l’arresto operativo di 3 hard disk causato da un fulmine ha decretato l’arresto dell’ intero sistema.
Decidiamo di contattare il distributore per analizzare insieme la situazione. Riceviamo pronta risposta e, sin dal primo momento, sostegno e supporto gratuito. Purtroppo non tutti i distributori hardware sono così professionalmente seri e validi e dobbiamo ammettere da subito che senza il loro aiuto tutto sarebbe stato molto più difficile.
L’ analisi della situazione evidenzia il seguente stato:
- Il primo raid 6 composto da 21 HD è ancora funzionante e senza alcun disco guasto
- Il secondo raid 6 ha perso la configurazione e dopo lo stop di 3 HD è inaccessibile.
- Sembra che i due raid siano uniti tramite la configurazione raid 60 in un unico spazio utile di 76 TB, ormai non accessibile. Purtroppo, la definizione del RAID 60 è andata persa a causa della violenza del guasto e forse anche a causa dei primi tentativi di ripristino successivi al guasto.Come spesso accade nel campo del recupero dati, i maggiori danni vengono creati dopo l’evento iniziale!
Da qui viene presa la decisione di coinvolgere il tecnico presso la casamadre in Taiwan, sig. Chris dell’azienda produttrice Proware. Anche lui dimostra disponibilità : rapidamente tramite collegamento remoto ci offre una serie di utili consigli. Purtroppo, la differenza delle zone temporali ostacolano la comunicazione. Scopriamo che a causa dei fusi orai, le due giornate lavorative si sovrappongono solo per poche ore al giorno, per cui e’ essenziale usare al meglio il poco spazio temporale a disposizione.
Decidiamo la strategia:
- Tentare il recupero dei dati nei dischi ormai guasti e quindi
- Rianimare il raid con i dischi recuperati
Iniziamo quindi la parte di recupero dati dei dischi 32, 34 e 37. Scopriamo che HD 32 è graffiato e non recuperabile, mentre il disco 34 e 37 superano la verifica in camera bianca e sembra abbiano la superficie integra. Dopo le operazioni di preparazione, pulizia e verifica delle testine, affidiamo il lavoro a PC3000 con il risultato del recupero di entrambi i dischi.
Decidiamo di reinserire i dischi e di avviare lo storage. Adesso il secondo raid 6 che era fallito per mancanza di 3 hard disk si trova con solo un hard disk mancante e ci aspettiamo un esito favorevole della prova.
Lo storage riconosce come buoni i dischi e, promettenti, si accendeno i led verdi in corrispondenza della posizione dei due HD recuperati, ma, purtroppo, il RAID 6 ,scomparso, non riappare. Tentiamo alcuni comandi suggeriti da Chris che dovrebbero rianimare il volume perso, ma anche qui senza successo.
Cercando di individuare le cause e per verificare la situazione, prepariamo un dump di 10 MB estraendolo all’inizio di ogni disco, poi tramite il server FTP della Infolab Data queste porzioni di dati vengono rese disponibili a Chris per essere quindi dirottate anche ad Areca.
Dopo sole 24 ore arriva il verdetto di Areca: i dischi 34 e 37 sono stati invertiti!! Siamo increduli. Il rispetto della posizione dei dischi del Raid da lavorare è la 1.a regola del Recupero Dati! Come era potuto accadere?? Infatti la prima azione che usiamo fare una volta ricevuto il raid è di numerare i dischi mentre sono ancora all’interno dei loro alloggiamenti…. Solo più tardi si scopre la causa dell’ errore . Alcuni giorni dopo il guasto, direttamente a casa del cliente si era tentato di sostituire i dischi guasti con dei nuovi e durante il rimontaggio, quindi, i dischi guasti sono stati rimontati erroneamente.
Si riparte, mettendo i dischi al loro posto, ma, purtroppo, il Volume non compare lo stesso.
Da Taiwan suggeriscono di ricreare il raid in modalità senza inizializzazione, una funzionalità utile che permette di ricreare una struttura senza scatenare l’inizializzazione dei dischi. Il volume Raid 6 così ricreato però non basta e il server MAC Apple non lo vede.
Sappiamo che lo spazio dei due raid 6 ciascuno di 38 TB era unito in un unico volume da 76 TB e confidavamo nella capacita’ del controller Apple con xSan a bordo.
Per chi non conosce xSan, diremo trattarsi di un software sviluppato da Apple in grado di gestire le LUN esterne creando gli Storage pools e i Volumi come risultato dell’ unione degli elementi sottostanti. xSan si basa su un suo controller di metadati che descrive la posizione dei files. Se xSan non riconosce il volume, non c’è un modo semplice per sfogliare 76 TB di contenuti.
Decidiamo di smontare la configurazione dei Volumi dello Storage e di ripartire da due raidset 6 uniti, questa volta in Volume set in raid 60, ovviamente sempre senza inizializzazione con il rispetto dei parametri presenti nel RAID, che non sono pochi. La tensione è alle stelle, sappiamo che l’errore di anche un solo parametro comporterebbe la perdita di una consistente porzione del sistema .
Detto, fatto. Ricolleghiamo lo storage di nuovo al controller Apple, però xSan resta fermo nella sua decisone di non riconoscere il nuovo raid 60.
Decidiamo di provare con i tool “Data Rescue”di recupero di dati, tanto per validare la consistenza del RAID. Data Recue vede il volume di 76 TB, però la stima del tempo richiesto per un’analisi è davvero grande, pertanto ci accontentiamo solo di un sondaggio.
Bingo: i dati e i files anche di notevoli dimensioni sono perfettamente integri e si aprono.
Questo è già un grande successo. Lo storage è stato ricreato con successo, il volume è consistente, ma con dei problemi per i quali xSan non è in grado di montarlo.
Forti di questa conferma, decidiamo di esplorare i meandri strutturali di Apple XSan.
L’approfondimento di manuali e le risorse presenti nel web ci portano a eseguire i comandi di volume check direttamente dalla riga di comando del teminale MAC.
Tentiamo il volume check: sudo cvfsck -j VolumeName ricevendo un secco “segmentation fault”!
Continuamo con : sudo cvfsck -nv VolumeName sistemando numerosi inodes ed errori del filesystem.
Presto ci appare chiaro quanto sconfinato possa essere xSan in relazione al tempo a disposizione, che implacabile stava per scadere. Decidiamo di cercare aiuto nei forum di Apple oltre a rivolgerci ad alcuni esperti internazionali individuati in Internet con i quali riusciamo a continuare la sistemazione del Volume. Il risultato finale ottenuto grazie al loro aiuto ci porta a montare il volume della SAN, con l’accesso nativo a tutto il filesystem.
Ci fermiamo! Possiamo brindare alla collaborazione tra esperti internazionali, dalla lontana Taiwan all’Europa, che ha contribuito a risolvere un caso di notevole complessità. Abbiamo vinto contro un caso veramente difficile, imparando le modalità di recupero dati da Apple xSan.
Siamo felici per il successo, meritato, ottenuto dalla Infolab Data e dai suoi ingegneri che hanno sapientemente guidato e coordinato il lavoro durante tutte le fasi.
