Il Disaster Recovery, o meglio il Disaster Recovery Plan, nasce per un’esigenza precisa: proteggere l’azienda da circostanze ed eventi in grado di generare disruption nei confronti del business. Da un punto di vista che potremmo definire olistico, Disaster Recovery significa poter continuare a creare valore e generare fiducia nei confronti degli stakeholder anche di fronte ad un evento avverso e pericoloso che spesso trova modo di insinuarsi nella storia dell’azienda. Il Disaster Recovery Plan richiede una rilevazione precisa dei rischi (Risk Analysis), degli impatti e della predisposizione delle misure con cui farvi fronte. Rientra dunque nel macrocosmo del Risk Management aziendale ed è strettamente connesso al Business Continuity Plan, rispetto al quale ha una funzione più tecnica di gestione dei fattori di rischio e della predisposizione di azioni preventive e interventi correttivi per ripristinare l’operatività dei sistemi e garantire la continuità del business.

Disaster Recovery: i rischi da cui difendersi

Il concetto stesso è quindi intimamente connesso con le infrastrutture e gli apparati IT, i quali rappresentano da sempre un cardine della continuità operativa aziendale. L’idea da cui partire è quella di vulnerabilità, un concetto che pervade qualsiasi asset tecnologico aziendale (dai PC ai server, dai router alla rete, senza dimenticare il software, lo storage, i load balancer, ecc.). Significa quindi essere soggetti a un impatto che va calcolato e quantificato: l’hardware si guasta, il software è soggetto a bug e va aggiornato, attacchi hacker con costi di un data breach letteralmente spaventosi, un’intrusione (fisica) o una calamità naturale che colpisca il datacenter, senza contare le minacce interne e un discorso di conformità normativa da valutare attentamente.

In tutti questi casi, la logica conseguenza è che il business si ferma e inizia la tragica conta dei danni i quali, passando le ore di downtime, crescono a dismisura e si sommano a quelli – già citati – del data breach e alle conseguenze (a volte incalcolabili) in termini di immagine. Tutto questo può essere evitato con un corretto Disaster Recovery Plan, il cui compito non è quello di ripristinare la situazione precedente, ma mettere l’azienda in condizione di continuare a lavorare e ad erogare i propri servizi: le due cose potrebbero non coincidere, ma lo scopo del Disaster Recovery è non bloccare l’azienda nei suoi processi critici e/o di farli ripartire il più in fretta possibile, considerando tutta la catena di conseguenze dell’evento.

Qui si innestano i due acronimi per eccellenza nel mondo del Disaster Recovery: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). A seconda dell’azienda, del settore, della normativa, dei sistemi e del processo in questione, un’azienda può decidere di definire autonomamente gli obiettivi del Disaster Recovery Plan in termini di RTO e RPO, poiché c’è un equilibrio da tenere in considerazione tra gli obiettivi da raggiungere e i costi da sostenere. Così si coglie una grande verità sul Disaster Recovery Plan: la scelta della soluzione “migliore” dipende dalle esigenze della singola azienda, del sistema e del processo che vuole proteggere.

Disaster Recovery e il fenomeno “as-a-service”: come scegliere il migliore

Come anticipato, Disaster Recovery non ha una soluzione adeguata a tutti: ogni piano è diverso dall’altro, differiscono RTO e RPO in funzione dell’investimento e della criticità del processo, dei dati e delle applicazioni da proteggere; così come i sistemi messi in atto per ripristinare l’operatività dei business. E’ tutto un bilanciamento tra costi e prestazioni che si vogliono ottenere: un semplice backup settimanale verso un recovery site remoto non è certamente oneroso, ma visto che l’RPO è noto, questa soluzione quale RTO può garantire nel caso in cui il datacenter principale prenda fuoco?

Ecco che allora, nell’ottica del backup dei dati, delle applicazioni e di interi sistemi verso siti remoti, si è sempre fatta la distinzione tra siti ‘freddi’, ‘caldi’ e ‘hot’, dove si va progressivamente da semplici repliche periodiche fino a repliche sincrone e risorse sempre disponibili per far girare le applicazioni in caso di disastro. È palese il fatto che, nell’ottica del bilanciamento tra gli obiettivi del plan e i costi, l’ultimo caso porti a RTO e RPO sensibilmente minori del primo ma anche ad un costo molto maggiore. La scelta della soluzione migliore tra questi estremi dipende da caso a caso.

Poi c’è il discorso, tutt’altro che secondario, del DRaaS, ovvero Disaster Recovery as a Service (anche noto come Cloud DR): con questa espressione – chiaramente legata al paradigma Cloud e alla virtualizzazione – si esternalizza l’attività di Disaster Recovery affidandola a un Service Provider che può sfruttare i benefici dell’infrastruttura Cloud per ospitare dati e applicazioni, fornire scalabilità, un elevato livello di servizio e garantire il failover in caso di evento disastroso all’infrastruttura primaria. Anche in questo caso non vengono meno le indicazioni e, soprattutto, gli obiettivi di RTO e RPO perseguiti da cliente a cui il provider può far fronte in diversi modi: da un semplice backup periodico dei dati su cloud fino a una replica su macchine virtuali, che può essere un’ottima scelta per le applicazioni critiche. Ma anche qui, vige la regola di base: non c’è un caso uguale all’altro, dipende tutto dalla ‘bontà’ del piano di Disaster Recovery e dalla capacità di spesa, poiché le tecnologie e le potenzialità per permettere alle aziende di dormire sonni tranquilli ci sono tutte.