Disaster Recovery: perché è importante prevedere e non improvvisare un piano di ripristino di emergenza? Ecco i suggerimenti per ridurre drasticamente i danni
Come ho scritto nella lettera aperta della home page del nostro sito, parlare di disaster recovery è antipatico, sembra di voler parlare di sfortuna ed augurarla a qualcuno. Ma d’altronde lo ripeto: non aspettiamo il terremoto. Il 90% degli incidenti informatici sono dovuti allo shock elettrico e all’errore umano, oppure ad attacchi informatici. Ormai i dati, e non le macchine, insieme ai cervelli, sono il vero capitale delle nostre aziende, e non possiamo permetterci di perderli, a meno di non voler chiudere.
Affrontare un progetto di disaster recovery è complesso e richiede una cogenerazione di idee ed una condivisione di obiettivi: le domande cruciali di questo processo sono sempre due:
- Quanto tempo puoi stare fermo?
- Quanto sei disposto a spendere negli anni per raggiungere il tuo obiettivo di ripartenza?
Ci deve essere coerenza fra queste due risposte e ci si deve rendere conto che un sistema di disaster recovery è come quello della protezione civile: va provato prima, affinché nel momento del bisogno tutti gli attori coinvolti sappiano cosa fare, come farlo e con che ordine. Insomma, su questi progetti bisogna lavorare con un approccio olistico, perché o si fa tutto o non si fa niente. E, inoltre, tutte queste procedure sono tailored made, ossia su misura. Chi vi vende servizi di disaster recovery standard non vi dà una soluzione, mentre un intervento corretto prevede soluzioni e attività custom.
BACKUP E DISASTER RECOVERY: DIFFERENZE E OPPORTUNITÀ
Il piano di disaster recovery può essere realizzato partendo da:
- soluzioni di virtualizzazione;
- soluzione di back-up;
- soluzioni di storage
Le soluzioni di virtualizzazione sono legate alla disponibilità di un ambiente nel sito di DR analogo a quello di produzione e non coprono eventuali macchine fisiche presenti nell’architettura.
Le soluzioni di backup sono le più adatte per una copia off-line, ma non per la ripartenza o per i test (si pensi al problema degli IP Address sul sito di DR visibili anche dal sito di produzione). Per la ripartenza si può accendere la macchina durante la restore, ma sempre di un restore si tratta. Un’alternativa è quella di utilizzare le repliche che molti ambienti di backup offrono, con il limite di essere allineati, a livello di RTO e RPO, all’ultima replica.
La soluzione più completa e semplice da gestire è quella basata sullo storage: molti ambienti, come ad esempio Datacore, offrono la possibilità di “mirrorare” tutti i dati su un datacenter esterno o di replicare a blocchi tutto lo storage verso un terzo nodo, in modo continuativo, sia esso on-premise in un’altra sede, sia esso in cloud. In questo modo RTO ed RPO si avvicinano allo zero ad un costo più che accettabile! Il committente si troverà tutto l’ambiente pronto per la ripartenza, a patto di avere una numerazione IP congruente; inoltre, se si inserisce in progetto anche la parte VDI, l’organizzazione si troverà anche i pool dei client virtuali disponibili per la ripartenza, accessibili, se previsto dalla configurazione geografica di WAN ed Internet, anche da remoto.
Non solo: come anticipato, il disaster recovery plan presuppone i test per la ripartenza.
Diciamo sempre che il DR è come il piano di Protezione Civile: o si prova prima, o nel momento del bisogno si rischia di improvvisare. Questo significa avere un plan DR e non semplicemente un ambiente.
La nostra offerta include, in tutte le proposte, il servizio per i test di DR fatti con il cliente; include anche la possibilità, in determinati casi, di avere un ambiente pay-per-use per la ripartenza. Prendiamo in considerazione l’argomento e non dimentichiamo di sottoporlo alla direzione: che non ci affermino “Non me l’hai mai detto!”.
Ecco due disegni di progetti realizzati: il primo a base storage e il secondo a base backup.
Giuseppe Mazzoli
Amministratore Unico di 3CiME Technology
