Guasto hardware
Server, storage o componenti possono diventare improvvisamente inutilizzabili.
Disaster recovery aziendale
Progettare il ripristino prima che serva davvero
Analizziamo sistemi, dati e dipendenze per costruire procedure e infrastrutture di disaster recovery coerenti con le reali priorità aziendali.
Backup e disaster recovery non sono la stessa cosa
Avere una copia dei dati non significa sapere come ripartire
Il disaster recovery riguarda il recupero di sistemi, applicazioni e dati dopo un evento che compromette l'ambiente principale.
Un backup può essere perfettamente valido e non essere sufficiente a riportare rapidamente l'azienda in condizioni operative. Servono priorità, dipendenze, risorse alternative e procedure definite.
Il progetto parte quindi dall'analisi del funzionamento dell'infrastruttura, non semplicemente dalla scelta di uno strumento di backup.
Scenari di indisponibilità
Il piano deve considerare più di un singolo guasto
Le procedure di recupero devono tenere conto degli eventi che possono rendere parzialmente o totalmente indisponibile l'infrastruttura.
Errore software
Configurazioni, aggiornamenti o applicazioni possono compromettere il servizio.
Errore umano
Cancellazioni, modifiche errate o operazioni non corrette possono richiedere un recupero.
Incidente di sicurezza
Una compromissione può rendere necessario ricostruire sistemi da copie affidabili.
Indisponibilità del sito
Problemi elettrici, connettività o indisponibilità fisica possono coinvolgere un'intera sede.
Problemi del provider
Anche infrastrutture cloud e servizi esterni devono essere considerati nell'analisi delle dipendenze.
Priorità
Non tutti i sistemi devono necessariamente ripartire nello stesso momento
Definiamo quali servizi sono indispensabili, quali dipendenze hanno e quale ordine di ripristino è tecnicamente possibile.
Server e infrastruttura
Identifichiamo le macchine e i servizi necessari alla ripartenza.
Database
Valutiamo dati, dipendenze e sequenze necessarie per il loro recupero.
Applicazioni
Individuiamo i software realmente critici per i processi aziendali.
Rete e accessi
Connettività, DNS, VPN e autenticazione possono essere prerequisiti per gli altri servizi.
RTO e RPO
Quanto tempo possiamo restare fermi e quanti dati possiamo perdere?
Queste due domande condizionano l'intero progetto di disaster recovery e determinano costi, tecnologie e procedure necessarie.
RTO
Il Recovery Time Objective definisce l'obiettivo temporale entro cui un servizio dovrebbe essere ripristinato.
RPO
Il Recovery Point Objective rappresenta la quantità di dati che l'organizzazione può accettare di perdere in termini temporali.
Backup
Il disaster recovery parte da copie affidabili
File, database, configurazioni e altri dati necessari devono essere protetti con modalità coer devono essere protetti con modalità coerenti con gli obiettivi di recupero.
Più copie
Valutiamo quali copie mantenere, dove conservarle e con quale frequenza.
Separazione
Le copie destinate al disaster recovery non dovrebbero dipendere dallo stesso singolo punto di guasto.
Protezione
Accessi, cifratura e protezione delle copie fanno parte dell'architettura.
Verifica
Una copia deve poter essere letta e utilizzata nel processo di ripristino.
Infrastruttura di recovery
Dove ripartono i sistemi se l'ambiente principale non è disponibile?
Il recupero può avvenire su hardware alternativo, in un altro datacenter, su cloud o attraverso architetture ibride.
Infrastruttura secondaria
Può essere predisposto un ambiente separato per i servizi più critici.
Cloud
Le risorse cloud possono essere utilizzate come parte della strategia di ripristino.
Connettività
Il piano deve considerare come utenti e sistemi raggiungeranno l'ambiente di recovery.
Procedure di ripristino
Le informazioni tecniche devono essere disponibili anche durante l'emergenza
Il piano operativo deve permettere di capire cosa ripristinare, in quale ordine e quali verifiche effettuare.
Sequenza
Definiamo l'ordine logico di ripristino dei componenti.
Accessi
Credenziali, chiavi e accessi necessari devono essere disponibili in condizioni controllate.
Documentazione
Configurazioni, dipendenze e procedure devono essere documentate.
Verifiche finali
Il recupero termina soltanto dopo aver verificato servizi, dati e funzionalità essenziali.
Test di disaster recovery
Un piano mai provato contiene ancora molte incognite
I test permettono di verificare tempi, procedure, dipendenze e problemi che sulla carta possono non essere evidenti.
Test controllati
Le procedure possono essere provate in ambienti separati quando tecnicamente possibile.
Tempi reali
Misuriamo quanto richiede realmente il recupero delle componenti testate.
Aggiornamento del piano
I risultati dei test servono a correggere procedure e documentazione.
Disaster recovery e business continuity
Il disaster recovery è una componente della continuità operativa
Il disaster recovery si concentra sul recupero dei sistemi tecnologici. La business continuity ha invece un perimetro più ampio e considera come l'organizzazione continua a svolgere le proprie attività essenziali.
Per questo, nella progettazione tecnica è importante collegare le priorità IT alle effettive priorità operative dell'azienda.
Come lavoriamo
Dall'analisi al test di ripristino
Il progetto viene costruito sulle reali dipendenze dell'infrastruttura.
01
Analisi
Mappiamo sistemi, dati, dipendenze e priorità.
02
Progettazione
Definiamo backup, infrastrutture alternative e procedure di recovery.
03
Test
Verifichiamo le procedure e aggiorniamo il piano sulla base dei risultati.