Disaster Recovery: best practice ed elementi base
Il Disaster Recovery (DR) è un ambito della gestione dei sistemi informativi che si occupa delle procedure da seguire e delle operazioni da attivare per ripristinare il regolare funzionamento dell’infrastruttura IT dopo un evento imprevisto che lo ha compromesso. Non è necessariamente un “disastro” naturale. Può essere anche un più banale guasto a qualche componente dell’infrastruttura o un attacco di hacker ostili che mette fuori uso uno o più server della rete.
Il Disaster Recovery è quindi una disciplina molto estesa: il suo tratto fondamentale è che si concentra sul ripristino dell’operatività dell’infrastruttura ICT in sé e non dei processi di business (quello è il tema della Business Continuity) dell’azienda, anche se la prima evidentemente supporta i secondi.
Leggi anche: Quanto costa il downtime
Il Disaster Recovery per essere efficace deve seguire un approccio trasversale e non essere semplicemente la reazione a un’emergenza. Richiede invece un approfondito lavoro di analisi preventiva in cui lo staff dedicato deve identificare i componenti dell’infrastruttura IT, la loro criticità per il funzionamento dei sistemi aziendali e le loro possibili vulnerabilità. A questo punto andrebbero identificate non solo le procedure da seguire per riportare i singoli componenti all’operatività ideale dopo un blocco ma anche le operazioni preventive da svolgere per ridurre al minimo il rischio e comunque le conseguenze del blocco stesso. La distinzione è importante.
Ad esempio, nel caso di un server web che gestisce le attività di e-commerce di un’azienda il DR non riguarda solo in senso più stretto le azioni per riportarlo in funzione dopo un’avaria ma anche ciò che serve per evitare l’avaria (ad esempio proteggerlo da attacchi esterni con un firewall) e per garantire che questa non abbia troppe conseguenze negative (ad esempio avendo attivo un altro web server a cui reindirizzare il traffico destinato a quello bloccato).
Tutte queste valutazioni e procedure così definite vanno a costituire il cosiddetto Disaster Recovery Plan (DRP), che deve contenere anche due indicazioni fondamentali: il RTO e il RPO.
- Il Recovery Time Objective (RTO) è il lasso di tempo massimo in cui i sistemi IT possono essere inattivi prima che i processi aziendali siano irrimediabilmente compromessi.
- Il Recovery Point Objective (RPO) è lo steso concetto ma applicato ai dati: la massima quantità di dati (di solito anch’essa identificata in un lasso di tempo) che si può perdere senza avere conseguenze troppo gravi.
Le procedure di protezione dei dati devono essere riviste e ottimizzate periodicamente
Sono due parametri essenziali perché dettano i tempi del Disaster Recovery: un DRP anche perfettamente eseguito non serve a molto se si completa quando l’azienda ha perso troppe informazioni per poter tornare davvero operativa. E ovviamente non basta definire un piano di DR, bisogna anche testarlo periodicamente per verificare che funzioni e che soddisfi le esigenze di operatività dell’azienda.
Non esiste “il” Disaster Recovery perché ogni azienda ha esigenze diverse in funzione della sua infrastruttura tecnologica e dell’ambito in cui opera. Esistono però fattori comuni a tutti i piani di DR: in primo luogo l’utilizzo di configurazioni ridondate per tutti gli elementi critici, dal singolo dispositivo di rete ai gruppi di server, alla protezione dei dati attraverso funzioni di backup e replica più o meno frequenti ed evolute. L’estremo del DR è la creazione di un “gemello” del data center aziendale da mantenere sempre allineato con il principale e a cui passare tutte le operazioni in caso di avarie.
