Un guasto informatico può trasformarsi rapidamente in un problema operativo molto più grave del semplice malfunzionamento di un computer. Server indisponibili, storage danneggiati, database corrotti, errori di configurazione, problemi di rete, ransomware o interruzioni dei servizi cloud possono impedire ai dipendenti di accedere alle applicazioni necessarie per lavorare. In un'azienda moderna, dove ordini, clienti, documenti, comunicazioni e processi amministrativi dipendono dall'infrastruttura IT, la disponibilità dei sistemi è direttamente collegata alla continuità del business.
Il Disaster Recovery consiste nell'insieme delle strategie, delle tecnologie e delle procedure utilizzate per ripristinare sistemi, applicazioni e dati dopo un evento che compromette l'infrastruttura principale. Non deve essere confuso con il semplice backup. Il backup serve a conservare copie dei dati, mentre il Disaster Recovery definisce come utilizzare quelle copie, insieme alle altre risorse disponibili, per riportare l'ambiente operativo a uno stato funzionante.
Preparare un'azienda a un guasto significa quindi progettare preventivamente ciò che dovrà accadere nel momento in cui un sistema critico non sarà più disponibile.
Analisi dell'infrastruttura IT e identificazione dei sistemi critici
Il primo passaggio di un progetto di Disaster Recovery è conoscere con precisione l'infrastruttura aziendale. Non è possibile progettare un piano di ripristino efficace se non si conoscono server, database, applicazioni, dispositivi di rete, servizi cloud, sistemi di autenticazione e dipendenze tra i diversi componenti.
L'azienda dovrebbe quindi realizzare un inventario degli asset IT, identificando per ogni componente la funzione svolta e il livello di criticità. Un server che ospita il gestionale aziendale, ad esempio, può avere un'importanza molto superiore rispetto a una workstation utilizzata esclusivamente per attività secondarie.
L'analisi deve considerare anche le dipendenze. Un'applicazione potrebbe richiedere un database specifico, un server DNS, un servizio di autenticazione o una determinata connessione di rete. Ripristinare solamente il server applicativo senza ripristinare correttamente il database o i servizi dai quali dipende non permette di tornare realmente operativi.
Per questo motivo è utile costruire una mappa delle dipendenze applicative, nella quale siano identificati i componenti necessari al funzionamento dei servizi critici.
Business Impact Analysis e priorità di ripristino
Il Disaster Recovery non dovrebbe partire dalla domanda "quale server devo ripristinare?", ma da una domanda più importante: quali processi aziendali devono tornare operativi per primi?
La Business Impact Analysis (BIA) permette di identificare le conseguenze operative ed economiche derivanti dall'indisponibilità dei diversi servizi. Se il gestionale è indispensabile per elaborare gli ordini, la sua priorità sarà probabilmente superiore rispetto a un sistema utilizzato occasionalmente.
La BIA permette di stabilire le priorità e di collegarle a parametri tecnici come RTO e RPO. In questo modo le decisioni sull'infrastruttura vengono prese sulla base delle esigenze reali del business e non soltanto delle caratteristiche hardware dei server.
RTO: quanto tempo può rimanere fermo un sistema
Il Recovery Time Objective (RTO) rappresenta il tempo massimo entro il quale un servizio dovrebbe essere ripristinato dopo un'interruzione.
Se un'applicazione ha un RTO di quattro ore, l'infrastruttura di Disaster Recovery deve essere progettata in modo da consentire il ripristino entro quel limite. Un semplice backup giornaliero potrebbe non essere sufficiente se il processo di ripristino richiede molte ore.
L'RTO influenza quindi direttamente l'architettura tecnica. Per ottenere tempi di ripristino ridotti possono essere necessari sistemi di replica, macchine virtuali già predisposte, infrastrutture secondarie, storage ridondato o servizi cloud configurati per il failover.
Non tutti i sistemi devono necessariamente avere lo stesso RTO. È possibile definire livelli differenti in funzione della criticità applicativa.
RPO: quanti dati l'azienda può permettersi di perdere
Il Recovery Point Objective (RPO) indica la quantità massima di dati che l'azienda può accettare di perdere in seguito a un incidente.
Un RPO di 24 ore significa, in termini semplificati, che l'organizzazione accetta potenzialmente di perdere fino a un giorno di dati. Un RPO di pochi minuti richiede invece una strategia molto più frequente di replica o acquisizione delle modifiche.
Questo parametro è particolarmente importante per database e sistemi transazionali. Se un gestionale registra continuamente ordini e operazioni, perdere tutte le transazioni dell'ultima giornata potrebbe avere conseguenze molto più gravi rispetto alla perdita di dati meno recenti.
RTO e RPO devono quindi essere definiti per ogni servizio critico e utilizzati per progettare la tecnologia di ripristino.
Backup e Disaster Recovery non sono la stessa cosa
Uno degli errori più frequenti consiste nel considerare sufficiente avere un backup. Il backup rappresenta una componente fondamentale del Disaster Recovery, ma non costituisce da solo un piano completo.
Un sistema di backup deve creare copie affidabili dei dati e conservarle secondo una determinata politica di retention. Il Disaster Recovery deve invece definire come ripristinare l'intero ambiente necessario per tornare operativi.
Supponiamo che il server principale venga completamente distrutto. Il backup potrebbe contenere database e documenti, ma l'azienda deve comunque disporre di un'infrastruttura sulla quale ripristinarli. Deve inoltre essere possibile ricostruire sistema operativo, applicazioni, configurazioni di rete, autenticazione e servizi necessari.
Per questo motivo il Disaster Recovery deve considerare dati, applicazioni, infrastruttura e procedure operative come parti dello stesso processo.
Strategie di backup per il Disaster Recovery
La strategia di backup deve essere progettata in funzione dei dati e degli RPO definiti. I sistemi critici possono richiedere backup frequenti, mentre informazioni meno importanti possono essere protette con intervalli più ampi.
È inoltre importante considerare la retention, cioè il periodo durante il quale le copie devono rimanere disponibili. Una retention corretta permette di recuperare dati risalenti a periodi precedenti e può essere fondamentale in caso di corruzione dei dati scoperta solamente dopo diversi giorni.
La strategia dovrebbe inoltre prevedere copie separate dall'ambiente di produzione. Se il server principale e il repository di backup vengono compromessi contemporaneamente, il backup perde gran parte della propria utilità.
Per questo motivo vengono spesso adottati principi come la regola 3-2-1, che prevede più copie dei dati, su differenti supporti e con almeno una copia separata dall'ambiente principale.
Immutabilità dei backup e protezione dal ransomware
Il ransomware ha modificato profondamente il modo in cui deve essere progettato un sistema di Disaster Recovery. Non è sufficiente creare copie dei dati se un attaccante che compromette l'infrastruttura può successivamente eliminarle o cifrarle.
L'immutabilità permette di proteggere le copie impedendo che possano essere modificate o cancellate durante un determinato periodo. Può essere implementata attraverso tecnologie di storage specifiche o repository configurati secondo policy che impediscono modifiche arbitrarie.
Anche la separazione degli account amministrativi è fondamentale. Il sistema che gestisce il backup non dovrebbe essere protetto dalle stesse credenziali utilizzate per amministrare tutti gli altri sistemi dell'azienda. Una compromissione dell'account Domain Administrator, ad esempio, non dovrebbe consentire automaticamente di eliminare ogni copia di backup.
Replica dei server e alta disponibilità
Quando l'RTO richiesto è molto basso, il semplice ripristino da backup potrebbe non essere sufficiente. In questi casi può essere necessario utilizzare la replica.
La replica consiste nel mantenere una copia aggiornata di un sistema o dei suoi dati su un'infrastruttura secondaria. In caso di guasto, il servizio può essere avviato nell'ambiente alternativo riducendo significativamente i tempi di indisponibilità.
La replica può riguardare macchine virtuali, database, storage o interi servizi applicativi. La tecnologia utilizzata dipende dall'architettura esistente e dagli obiettivi di RTO e RPO.
È importante, tuttavia, non considerare automaticamente la replica come un sostituto del backup. Se un dato viene corrotto o cifrato nell'ambiente principale e la modifica viene replicata immediatamente, anche il sistema secondario potrebbe ritrovarsi nella stessa condizione. Backup e replica risolvono quindi problemi differenti e devono essere progettati in modo complementare.
Disaster Recovery locale, cloud o ibrido
L'infrastruttura di Disaster Recovery può essere realizzata in diversi modi. Un'organizzazione può predisporre un secondo server nella stessa sede, utilizzare un'infrastruttura in un'altra sede geografica oppure utilizzare servizi cloud.
Una soluzione completamente locale può offrire tempi di ripristino molto rapidi, ma presenta un limite evidente: se l'evento coinvolge fisicamente l'intera sede, anche l'infrastruttura secondaria potrebbe diventare inutilizzabile.
La separazione geografica aumenta quindi la resilienza. Un secondo ambiente collocato in una sede differente può continuare a essere disponibile anche in caso di incendio, allagamento, guasto elettrico grave o altro evento che renda inutilizzabile il data center principale.
Il modello ibrido può combinare infrastruttura locale e cloud, mantenendo alcune risorse on-premise e utilizzando servizi esterni per backup, replica o ripristino.
Failover e ripristino dei servizi
Un piano di Disaster Recovery deve stabilire anche come avviene il failover, cioè il passaggio dall'infrastruttura principale a quella alternativa.
Il processo può essere manuale oppure automatizzato. In un ambiente semplice, un amministratore può avviare le macchine virtuali secondarie, verificare il database e riconfigurare i servizi DNS. In infrastrutture più avanzate, invece, determinate procedure possono essere automatizzate attraverso orchestratori e sistemi di gestione del disaster recovery.
La procedura deve essere documentata in modo sufficientemente dettagliato da poter essere eseguita anche durante una situazione di emergenza. È fondamentale evitare che il piano dipenda esclusivamente dalla memoria del tecnico che normalmente gestisce l'infrastruttura.
Documentazione tecnica e procedure operative
Un Disaster Recovery Plan efficace deve contenere la documentazione necessaria per ricostruire l'ambiente. Devono essere conosciute almeno le configurazioni principali dei server, gli indirizzi IP, le VLAN, i servizi DNS e DHCP, le dipendenze applicative, le procedure di autenticazione, la posizione dei backup e le modalità di accesso ai sistemi.
Anche le credenziali di emergenza devono essere gestite in modo sicuro. Non devono essere inserite in documenti non protetti o conservate in file accessibili indiscriminatamente agli utenti.
La documentazione dovrebbe essere aggiornata ogni volta che cambia l'infrastruttura. L'aggiunta di un nuovo server, la sostituzione del firewall o la migrazione di un'applicazione possono infatti rendere obsolete le procedure precedentemente definite.
Test del Disaster Recovery
Un piano di Disaster Recovery che non viene mai testato non può essere considerato realmente affidabile. È possibile che una procedura apparentemente corretta presenti problemi nel momento in cui viene utilizzata: backup incompleti, credenziali non valide, dipendenze non documentate, software mancanti o tempi di ripristino superiori a quelli previsti.
I DR test devono quindi essere eseguiti periodicamente. Il test può iniziare dal semplice ripristino di un file e arrivare fino alla simulazione del completo fermo di un server o di un ambiente virtuale.
Durante i test devono essere misurati i tempi effettivi di ripristino e confrontati con gli RTO definiti. Se il server doveva essere ripristinato in due ore ma sono necessarie sei ore, il piano non è coerente con il requisito aziendale e deve essere modificato.
Disaster Recovery e sicurezza degli accessi
Anche la sicurezza dell'ambiente di ripristino deve essere considerata. Un'infrastruttura secondaria configurata in modo meno sicuro rispetto all'ambiente principale può diventare un punto debole dell'intera architettura.
Account amministrativi, autenticazione multifattore, segmentazione della rete, firewall e gestione dei privilegi devono essere applicati anche ai sistemi di Disaster Recovery. Le copie dei dati devono essere cifrate quando necessario e l'accesso ai repository deve essere limitato al personale autorizzato.
La protezione delle credenziali di emergenza è particolarmente importante. Durante un incidente gli amministratori possono avere necessità di accedere rapidamente ai sistemi, ma questo non deve trasformarsi in una situazione nella quale tutte le protezioni vengono bypassate.
Disaster Recovery e continuità operativa
Il Disaster Recovery è una componente della più ampia strategia di Business Continuity. La continuità operativa non riguarda infatti esclusivamente il ripristino dei server, ma la capacità dell'azienda di continuare a fornire i propri servizi anche durante un evento grave.
Se il gestionale viene ripristinato ma i dipendenti non possono accedere alla rete, il ripristino tecnico potrebbe non essere sufficiente. Allo stesso modo, se la posta elettronica è indisponibile, potrebbe essere necessario predisporre canali alternativi di comunicazione.
Per questo motivo il piano deve essere collegato ai processi aziendali e non limitarsi all'elenco delle apparecchiature informatiche.
Come preparare concretamente l'azienda a un guasto
Preparare un'azienda al Disaster Recovery significa innanzitutto conoscere l'infrastruttura e identificare quali sistemi sono realmente indispensabili. Da questa analisi devono essere definiti RTO e RPO realistici, sulla base dei quali progettare backup, replica e infrastruttura di ripristino.
Il passo successivo consiste nel proteggere i dati attraverso copie multiple, retention adeguata e, quando necessario, repository immutabili e separati dall'ambiente di produzione. Parallelamente devono essere documentate le configurazioni e le procedure necessarie per ricostruire i servizi.
Infine, il piano deve essere testato. Solo un test reale può dimostrare se i backup sono utilizzabili, se le procedure sono corrette e se i tempi di ripristino rispettano gli obiettivi stabiliti.
Un Disaster Recovery efficace riduce il rischio operativo
Un guasto non può essere sempre evitato. Un server può rompersi, uno storage può danneggiarsi, un errore umano può compromettere un database e un attacco informatico può rendere indisponibili interi sistemi. Quello che un'azienda può controllare è la propria capacità di reagire all'evento.
Un Disaster Recovery progettato correttamente permette di trasformare un'interruzione potenzialmente critica in un incidente gestibile. Backup affidabili, copie immutabili, replica, infrastrutture ridondate, RPO e RTO definiti, documentazione tecnica e test periodici costituiscono gli elementi fondamentali di questa strategia.
Il vero obiettivo non è quindi evitare qualsiasi guasto, ma fare in modo che un guasto non si trasformi in un fermo aziendale prolungato. La domanda da porsi non è semplicemente "cosa succede se il server si rompe?", ma "quanto velocemente siamo in grado di tornare operativi e quali dati possiamo recuperare?". La risposta a queste due domande rappresenta il punto di partenza per costruire un Disaster Recovery realmente efficace.
