Quanto è complesso il recupero dati da server NAS?

Pensi che il ripristino di un server NAS sia un compito facile? Non è propriamente così! I server NAS, pur essendo la soluzione di storage RAID a costo contenuto per le piccole e medie imprese, sono tecnicamente quasi altrettanto complessi e difficili da recuperare.

La maggior parte dei sistemi NAS oggi ha caratteristiche simili a quelle delle SAN di fascia alta, come la deduplica, il supporto della virtualizzazione e il targeting iSCSI. In questi sistemi i dati sono strutturati su più livelli, che devono essere recuperati e ricostruiti in sequenza prima di giungere ai dati veri e propri.

Per spiegare meglio la complessità di alcuni interventi di recupero dati da NAS, vi proponiamo un caso reale di un cliente che ha riscontrato un errore nel proprio NAS QNAP.

Errore Server NAS: cosa è successo?

Questo è quanto recentemente accaduto ad un cliente della filiale tedesca di Ontrack, che ha subito un guasto al proprio NAS QNAP. Il sistema RAID 6 comprendeva 24 dischi da 6TB ciascuno. Durante il setup sono state create 2 LUN iSCSI, rispettivamente con più di 40 e 60TB di dati. Ciascuna LUN era il target iSCSI di un sistema Windows Server 2012 R2 ed era formattata come partizione NTFS. Inoltre, la funzione di deduplica di Windows Server 2012 R2 era attivata su entrambe le LUN.

Quando il cliente, un reparto IT di un grande gruppo immobiliare, ha iniziato a riscontrare un comportamento anomalo e maggiore lentezza del NAS, ne ha forzato il riavvio.

Purtroppo, con questa operazione entrambe le LUN sono diventate inaccessibili anche se si potevano ancora visualizzare le unità. A peggiorare la situazione per il cliente, non c'era alcun backup disponibile!

Soluzione adottata per il ripristino del NAS

Solo a questo punto il cliente ha contattato Ontrack. L'analisi preliminare ha rivelato che per intervenire era necessario gestire i sei livelli di strutture di dati.

Dato che un NAS QNAP lavora con Linux, gli ingegneri hanno dovuto prima ricostruire il livello NAS QNAP RAID 6 per arrivare al file system Linux EXT4. Qui erano localizzati i frammenti delle LUN mancanti e gli stessi hanno dovuto essere ricostruiti per accedere ai 64 e 44TB di dati delle LUN in formato raw. La dimensione di ogni frammento era circa 1TB, pertanto è stato necessario lavorare, ricostruire e combinare più di 100 ‘pezzi’ di big data iSCSI.

I frammenti erano in origine gestiti dal QNAP e combinati in tempo reale, così che Windows Server credesse di accedere a due LUN esistenti. Gli esperti sono riusciti a ricomporre queste LUN iSCSI in un unico volume NTFS dopo che i blocchi di dati erano stati copiati su uno storage SSD temporaneo.

Vista la deduplica attiva sul sistema, gli ingegneri hanno dovuto lavorare su quest’ultimo sesto livello per identificare i dati interessati da questa funzione e creare un volume NTFS utilizzabile dal cliente. Questo volume è stato poi copiato dallo storage temporaneo su un sistema RAID nuovo che il cliente ha potuto connettere alla propria rete per accedere nuovamente ai dati persi.

Analisi ed esito dell’intervento

Anche con strumenti di ripristino altamente specializzati, il ripristino e la copia di una tale mole di dati nel nuovo archivio di backup del cliente ha richiesto diverse settimane per essere completato.

La ragione del malfunzionamento in questo caso è stata ricondotta ad una configurazione non corretta del NAS durante l’installazione. Per questo è importante assicurarsi che l’installazione del server sia effettuata in modo adeguato prima di memorizzarvi i dati, ed è in ogni caso saggio preparare un piano per fronteggiare eventuali perdite di dati.

I server di piccole e medie dimensioni come questo non sono a prova di errore come i server di fascia alta. L’utilizzo della funzione di deduplica potrebbe non essere stata una buona idea: questa ha infatti aggiunto un ulteriore livello di complessità al recupero dei dati. Inoltre, poiché il costo degli hard disk è abbordabile, sarebbe stato più opportuno acquistare e utilizzare unità aggiuntive piuttosto che “appesantire” un sistema già complesso per sua stessa composizione.

Perché la documentazione è importante per recuperare i dati da server NAS?

Capita spesso che i nostri specialisti di data recovery ricevono dei progetti che si basano su informazioni fornite dai clienti, che si rilevano inesatte o lacunose.

Un caso del genere si è verificato di nuovo in Germania, quando al tecnico è stato chiesto di recuperare i "dati criptati" da un ambiente QNAP NAS.

La NAS consisteva in quattro dischi rigidi – due HDD da 6 TB e due da 2 TB – in un sistema RAID 5.

All'ingegnere è stato detto che il cliente aveva bisogno di una macchina virtuale Microsoft HyperV che doveva essere archiviata in un grande file iSCSI che era a sua volta all'interno di una partizione criptata con la tecnologia Linux Unified Key Setup, "LUKS".

Gli era stato detto anche che il cliente aveva provato diverse volte, senza successo, a criptare la partizione contenente il file iSCSI con la chiave di decrittografia. Dopo aver ricevuto la soluzione QNAP NAS con il sistema QNAP e le password di crittografia, la situazione è subito apparsa molto diversa: in base alle indicazioni del cliente e utilizzando gli strumenti proprietari di data recovery di Ontrack, il tecnico è stato in grado di aprire la partizione LUKS e quindi di avere accesso al file iSCSI.

Con sua grande sorpresa, questo file non conteneva la macchina virtuale mancante e necessaria.

Di conseguenza il tecnico ha controllato l'intero sistema QNAP NAS, che non era del tutto criptato con LUKS (solo una delle partizioni era criptata), e ha scoperto che la macchina virtuale mancante era nascosta in uno spazio completamente diverso sugli storage del disco NAS e non nella partizione criptata.

Il tecnico è quindi riuscito a copiare la macchina virtuale mancante su un disco esterno e a mandarla al cliente tramite un servizio di consegna espresso perché potesse utilizzarla.

Durante una telefonata con il cliente è emerso che egli non aveva a disposizione la documentazione adeguata della NAS e aveva semplicemente pensato che la macchina virtuale fosse all'interno del file iSCSI.

A causa di questa supposizione errata, l'intero processo di data recovery ha impiegato più tempo del necessario e pertanto ha avuto anche un costo superiore.

Questo caso mostra chiaramente che è consigliabile avere un'adeguata documentazione di un sistema NAS, pronta in caso di errore del sistema, di accidentale cancellazione dei dati o di altri motivi che pregiudicano l'accesso ai dati o comportano una grave perdita di dati.

Senza la documentazione e senza le informazioni relative al tipo di dati e alla posizione in cui sono archiviati all'interno di un sistema, i tecnici di data recovery possono perdere molto tempo a esaminare e cercare i dati nelle sedi sbagliate.

Contattaci subito se hai bisogno di recuperare i dati dal tuo server NAS.