Questo articolo è l’ultimo di una serie introduttiva sulla problematica del recupero dati. gli articoli precedenti sono qui: 1, 2, 3. Presto pubblicherò un link per poter scaricare il documento completo, in formato PDF. Il report sarà corredato da una seconda parte sponsorizzata da Kroll Ontrack.
La virtualizzazione
L’adozione massiva di strumenti di virtualizzazione dei server ha portato negli anni ad aggiungere un ulteriore strato di software da gestire, anche nel caso di una eventuale perdita di dati: i file system che contengono le macchine virtuali (Virtual Machines o, brevemente, VM). Infatti, mentre nel caso di un singolo server che perde l’accesso ai dati archiviati è necessario ripristinare la consistenza di un solo file system nel caso di una infrastruttura virtualizzata l’operazione è doppia perchè, oltre al file system che contiene la VM, c’è la probabilità che sia necessario ripristinare anche il FS all’interno della VM stessa!
Per poter recuperare i dati all’interno di una virtual machine è necessario che esista la consistenza di tutti gli strati intermedi. L’obiettivo è sempre quello di recuperare i dati o comunque, in questo caso, il ripristino della macchina virtuale che li ospita.
Le Virtual Machine ospitate all’interno di una infrastruttura virtuale, di solito, risiedono all’interno di uno o più sistemi storage condivisi. Il sistema di storage condiviso può essere di tipo NAS o SAN. Nel primo caso è lo storage che si occupa di gestire il file system e quindi le macchine virtuali sono dei file condivisi attraverso quello che in gergo viene definito uno share di rete. Il secondo caso, quello più complesso, si verifica quando l’accesso allo storage viene effettuato a blocchi invece che a file. Su questi volumi viene creato un filesystem di tipo cluster in cui vengono salvate le Virtual Machine e i relativi file di controllo, per poi essere acceduto contemporaneamente da più server. Un ulteriore complessità, riguardo soprattuto il recupero dei dati, può arrivare dall’uso di VSA, in pratica una Virtual Storage Appliance, che vitualizza e fornisce servizio storage alle altre Virtual machine prelevandolo da storage locale o condiviso.
Operare con ambienti virtuali quindi mostra una complessità superiore non tanto per il tipo di operazione in se, che va ripetuta più volte proprio per il fatto che le strutture di dati sono annidate, ma perchè è necessario conoscere a fondo anche la piattaforma di virtualizzazione (l’hypervisor).
Una difficoltà reale invece è data dalla mole di dati da recuperare sia per questioni di tempo che per spazio disco necessario. Proprio per questo motivo, in una operazione per il recupero di dati da una infrastruttura virtualizzata è più importante che mai conoscere cosa è inaccessibile esattamente, cosa è importante recuperare, cosa no e le priorità di recupero.
Fortunatamente, se non ci sono danni hardware ed essendo questa una attività particolarmente legata ad aspetti software, è possibile eseguirla da remoto con sensibili risparmi di tempo per l’utente finale.
La diagnosi del guasto
La prima cosa da fare quando si è perso il dato, e non esistono mezzi per recuperarlo da un backup, è quello di non intervenire ulteriormente. Proprio gli interventi successivi all’evento, se non fatti con la giusta perizia, possono definitivamente minare ogni possibile tentativo di recupero.
L’attività di recupero dei dati, qualsiasi sia il dispositivo e la natura del guasto, inizia con una diagnosi precisa, dove la prima difficoltà che si incontra è interagire con l’utente (il potenziale artefice del danno!). A volte è proprio l’operatore a nascondere la reale dinamica dei fatti, soprattutto se si tratta di errore umano. In altri casi si sottovaluta, si omette parte dell’accaduto o si preferisce negare di aver tentato un ripristino in autonomia. Tutte queste pratiche sono comprensibili proprio per il tipo di danno, che si immagina essere grave, e che non si ha voglia di ammettere. Le principali motivazioni di questo comportamento stanno nella paura di ricevere un rimprovero da un superiore (se non peggio, perdere il lavoro) o di subire rivalse da parte di clienti e colleghi. Purtroppo, tutto questo rende ancora più difficile l’attività di recupero proprio perchè chi deve operare non avrà un quadro chiaro su come muoversi. E’ importante quindi che si instauri subito un rapporto di fiducia fra utente e tecnico proprio per perseguire al meglio l’obiettivo comune: recuperare i dati.
Se il guasto è di tipo hardware la diagnosi è più complessa e prima di capire cosa è recuperabile è necessario ripristinare le funzionalità dell’hardware. In ogni caso, come si è potuto evincere dai capitoli precedenti, l’attività si complicano mano a mano che si aggiungono strati: ad esempio, nel caso di un ambiente virtualizzato in un array che ha subito un doppio guasto in raid group RAID 5, sarà necessario ripristinare gli HD per poi verificare la consistenza del raid group, il file system dell’hypervisor e per ultimo appurare lo stato delle singole VM.
Ovviamente, anzi in molti casi è probabile, un problema HW non è detto che non abbia avuto una conseguenza Software (corruzione del filesystem?) e quindi l’attività si complica.
In pratica, l’unico modo per poter sapere cosa è recuperabile, ovvero ottenere una lista esatta di ciò che è recuperabile, è arrivare ad eseguire un recupero dei dati o, quanto meno, arrivare a verificare che i dati siano leggibili.
Quanto appena scritto implica che chi fa la diagnosi deve essere anche in grado di agire direttamente sui dispositivi ed effettuare un “recupero preventivo dei dati”.
Successivamente alla prima fase, e alla verifica dello stato dell’hardware, si procederà al vero e proprio recupero. Ogni fornitore di servizi opera in modo diverso e con SLA diversi per cui è molto difficile destreggiarsi fra le varie offerte e capirne le differenze.
Disclaimer: L’azienda Kroll Ontrak ha sponsorizzato la realizzazione di un report sulla problematica del recupero dei dati. Il documento è diviso in due parti, nella prima viene presentata la problematica nei suoi aspetti più generali: introduzione, problematiche specifiche legate a diversi tipi di dispositivi, sistemi più complessi e virtualizzazione. La seconda parte di questa pubblicazione è dedicata alla presentazione di Kroll Ontrack. Il report sarà presto scaricabile dal sito dell’azienda e dall’area dei download del sito di Juku. In questo blog abbiamo deciso di pubblicare una serie di articoli che ripropongono la sezione indipendente del documento.