Disaster recovery, backup, RTO/RPO, failover e, soprattutto, la domanda che molte aziende si pongono solo dopo un guasto: sappiamo davvero ripristinare il sistema e tornare al lavoro?
Guasto del server. Database danneggiato. Errore dopo il deploy. Ransomware. Problemi con il fornitore dell’infrastruttura. Eliminazione accidentale dei dati. Guasto dell’intera regione.
Gli scenari sono molti. Il problema è che la maggior parte delle aziende si prepara soprattutto a evitare che il guasto si verifichi.
Molto più raramente, invece, si prepara alla situazione in cui il guasto si verifica davvero.
Questo è proprio l’ambito del disaster recovery.
Ed è qui che nasce la domanda fondamentale: se la tua applicazione smettesse di funzionare oggi alle 14:00, quanto tempo ti servirebbe per riattivarla e quanti dati potresti perdere nel frattempo?
Se la risposta è “abbiamo un backup”, non è ancora una risposta a questa domanda.
Il backup non è disaster recovery
Il backup è una copia dei dati. Il disaster recovery è il processo di ripristino del funzionamento del sistema.
È una distinzione molto importante.
Puoi eseguire copie del database ogni giorno, eppure non sapere:
-
se l’ultima copia è corretta,
-
se può essere ripristinata,
-
quanto tempo richiederà il ripristino,
-
se dopo il ripristino il database funzionerà con la versione attuale dell’applicazione,
-
se ripristinerai anche la configurazione del sistema,
-
se disponi di tutte le chiavi, i certificati e i segreti necessari per avviare l’ambiente,
-
se l’infrastruttura necessaria per avviare l’applicazione è ancora disponibile,
-
chi deve eseguire i singoli passaggi,
-
se l’intero processo rientra in un tempo accettabile per il business.
Il NIST indica esplicitamente la necessità di testare il ripristino delle copie, e le attuali linee guida AWS trattano anche i test periodici di recovery come un modo per verificare se il backup consente davvero di raggiungere l’RTO e l’RPO previsti.
Perciò il backup è un elemento della strategia di recovery, non il suo equivalente completo.
La domanda più importante: cosa succede dopo un guasto?
Immaginiamo un negozio online.
Alle 10:17 il database smette di rispondere.
Il server applicativo continua a funzionare, ma gli utenti non riescono ad accedere. Gli ordini non funzionano. Il pannello di amministrazione smette di rispondere. Il sistema di pagamento non riceve informazioni corrette.
Il team verifica la situazione.
Si scopre che l’ultimo backup del database è stato eseguito alle 8:00.
In teoria i dati possono essere recuperati.
Ma poi sorgono altre domande;
- Si sa dove si trova la copia?
- Si sa come ripristinarla?
- La persona che sa farlo è disponibile?
- Il backup è completo?
- La configurazione dell’applicazione corrisponde alla versione salvata nella copia?
- Dopo il ripristino, il database funzionerà con l’applicazione attuale?
- E la cosa più importante: quanto tempo ci vorrà per ripristinare il funzionamento del negozio?
Se nessuno lo ha verificato in precedenza, la risposta può essere sorprendente.
RTO - quanta interruzione possiamo accettare?
L’RTO, cioè Recovery Time Objective, definisce il tempo massimo accettabile per il ripristino del sistema dopo un guasto.
Ad esempio: RTO = 4 ore significa che l’organizzazione presume la possibilità di ripristinare il funzionamento del sistema entro un massimo di quattro ore.
Ciò non significa però che ogni applicazione debba avere un RTO di quattro ore.
Per un sistema interno usato poche volte al giorno un tempo del genere può essere accettabile. Per una piattaforma di vendita attiva 24/7 può significare perdite molto gravi.
L’RTO dovrebbe quindi derivare dal business, non da ciò che l’infrastruttura offre al momento.
Il NIST definisce l’RTO come il tempo durante il quale un sistema può rimanere in fase di ripristino prima che ciò influisca negativamente sulle attività dell’organizzazione.
RPO - quanti dati possiamo perdere?
Il secondo parametro fondamentale è l’RPO, cioè Recovery Point Objective.
L’RPO risponde alla domanda: quanto indietro nel tempo possiamo tornare con i dati dopo un guasto?
Esempio: RPO = 1 ora significa che l’organizzazione accetta una potenziale perdita di dati fino a circa un’ora.
Se il sistema va in guasto alle 15:00 e l’ultimo backup utilizzabile risale alle 14:00, proprio questo scenario rientra nell’RPO previsto. Ma se il backup viene eseguito una volta al giorno, è difficile aspettarsi un RPO di un’ora.
L’RPO influisce quindi direttamente sul modo in cui si eseguono i backup, si replica i dati e si progetta l’infrastruttura.
L’RTO ci dice soprattutto per quanto tempo possiamo restare indisponibili.
L’RPO ci dice quanti dati possiamo perdere.
Questi due parametri dovrebbero essere definiti insieme al business, perché il loro raggiungimento comporta costi e soluzioni tecniche. Anche Microsoft sottolinea che RTO e RPO dovrebbero derivare da reali esigenze di business, non dall’astratta assunzione di “zero downtime e zero perdita di dati”.
Il backup può esistere ed essere comunque inutile
Questo è uno dei miti più pericolosi dell’IT.
“Il backup viene eseguito correttamente” non significa automaticamente: “il sistema può essere ripristinato da esso”.
La copia può essere incompleta. Può essere danneggiata. Può contenere dati che non possono essere utilizzati correttamente. Può essere stata creata in un modo che non consente di ripristinare l’intero ambiente.
Per questo il backup va testato tramite un ripristino reale.
Non basta controllare se il file esiste.
Bisogna ripristinarlo.
Avviare il sistema.
Verificare i dati.
Controllare le dipendenze.
Verificare la configurazione.
Misurare il tempo.
E rispondere alla domanda se il risultato corrisponde agli obiettivi RTO e RPO.
AWS indica come errore tipico proprio il ripristino del backup senza verificare se la risorsa ripristinata funzioni davvero e se sia possibile utilizzare i dati recuperati.
Failover - quando non vogliamo aspettare il ripristino
Non tutte le applicazioni possono permettersi di attendere ore per il ripristino. In questi casi si utilizzano, tra le altre cose, i meccanismi di failover.
Il failover consiste nel passare il funzionamento dall’ambiente principale a un ambiente di riserva preparato.
Può essere:
-
un server di riserva,
-
una seconda zona di disponibilità,
-
una seconda regione,
-
una replica del database,
-
un ambiente standby,
-
un’infrastruttura alternativa pronta per l’avvio.
Nel modello più semplice l’applicazione funziona in un unico luogo e, in caso di guasto, avviamo l’ambiente di riserva. Nelle soluzioni più avanzate una parte dell’infrastruttura funziona in parallelo ed è pronta a prendere in carico il traffico.
Non esiste però una strategia unica adatta a tutti.
Backup e restore sono di solito più economici, ma possono comportare tempi di ripristino più lunghi. Soluzioni come warm standby o ridondanza attiva possono ridurre notevolmente il recovery, ma richiedono investimenti maggiori e un’infrastruttura più complessa.
Anche il failover va testato
Qui emerge un altro problema.
L’azienda può avere un ambiente di riserva, ma non lo ha usato per due anni;
- Funziona ancora?
- La configurazione corrisponde alla produzione?
- Ha prestazioni sufficienti?
- Tutti i servizi sono disponibili?
- I certificati sono aggiornati?
- Il DNS passerà correttamente?
- L’applicazione si connetterà al database?
- Il meccanismo di autorizzazione funzionerà?
- Il team sa esattamente cosa deve fare?
Solo un test risponde a queste domande.
AWS raccomanda di testare regolarmente il failover proprio per verificare il funzionamento del percorso di ripristino e controllare se gli effettivi RTO e RPO corrispondono alle ipotesi.
Un ambiente di disaster recovery che non è mai stato testato è solo in parte una realtà, in parte un’ipotesi.
Il disaster recovery non è solo infrastruttura
È facile guardare al DR solo attraverso la lente dei server.
È un errore.
Il recovery comprende anche:
- Dati
Tutti i dati rilevanti sono protetti? - Applicazione
Abbiamo la versione corretta del codice e la possibilità di distribuirla? - Configurazione
Sappiamo quali impostazioni servono per avviare il sistema? - Segreti e certificati
Abbiamo accesso sicuro a chiavi, token e certificati? - Dipendenze esterne
Cosa succede se non è disponibile un sistema di pagamento esterno, un’API, un provider di identità o un servizio SaaS? - Infrastruttura
Abbiamo un posto in cui l’applicazione possa essere avviata? - Persone
È chiaro chi prende la decisione di avviare la procedura? - Procedure
Esiste un runbook concreto o il recovery si basa sulla conoscenza di una sola persona?
Quest’ultimo aspetto è particolarmente importante.
Se solo un amministratore sa come ripristinare il sistema, non abbiamo ancora una procedura resiliente. Abbiamo una dipendenza da una persona specifica.
Il momento peggiore per scrivere una procedura di recovery
È il momento in cui il sistema non funziona più.
Allora arrivano la pressione del tempo, lo stress, le telefonate dei clienti e le domande del management.
Per questo la procedura dovrebbe essere preparata in anticipo.
Dovrebbe definire, tra le altre cose:
-
quando avviamo il disaster recovery,
-
chi prende la decisione,
-
quali sistemi hanno la massima priorità,
-
dove si trovano i backup,
-
come ripristinarli,
-
quali dipendenze devono essere avviate,
-
come avviene il failover,
-
come verificare il corretto funzionamento,
-
come comunicare il guasto,
-
quando si può iniziare il failback,
-
chi approva il ritorno all’ambiente primario.
In caso di guasto grave non dovrebbe esserci spazio per la domanda: „Cosa facciamo adesso?”
La procedura dovrebbe aver già risposto a questo.
Il DR dovrebbe essere testato come una funzionalità dell’applicazione
Un buon approccio è trattare il recovery in modo simile ai test del software. Non basta preparare la procedura una sola volta.
Il sistema cambia.
Il database cresce.
Le dipendenze cambiano.
Si aggiunge nuova infrastruttura.
Le versioni dell’applicazione cambiano.
Compaiono nuove integrazioni.
Cambia il sistema dei permessi.
Per questo anche la strategia di recovery richiede verifiche continue.
Il test può iniziare da uno scenario semplice: „Il database è andato perso. Ripristiniamolo dall’ultima copia.”
In seguito si può passare a scenari più complessi:
- „Il server dell’applicazione non funziona.”
- „L’intero ambiente di produzione non è disponibile.”
- „I dati sono stati criptati.”
- „Non funziona la regione principale dell’infrastruttura.”
- „Non abbiamo accesso all’amministratore principale.”
Ogni test di questo tipo può far emergere problemi che non si vedono durante il normale funzionamento del sistema.
Ogni applicazione ha bisogno di un disaster recovery avanzato?
No.
E anche questo è importante.
Progettare un’infrastruttura resistente a ogni possibile scenario può essere sproporzionatamente costoso.
Se un guasto di un’applicazione interna può significare un’ora di disagi, non abbiamo necessariamente bisogno di un’infrastruttura active-active in più regioni. Se però un guasto del sistema significa blocco delle vendite, della produzione, dell’assistenza clienti o di un processo business critico, la situazione è completamente diversa.
Prima bisogna determinare l’impatto del guasto sul business.
Solo dopo scegliere la tecnologia.
Questo può portare a soluzioni diverse:
Backup + restore
Soluzione più semplice ed economica per sistemi meno critici.
Warm standby
L’ambiente di riserva è parzialmente preparato e può essere avviato rapidamente.
Hot standby
L’ambiente di riserva funziona in larga misura in parallelo ed è pronto a prendere in carico il carico di lavoro.
Active-active
Due ambienti possono gestire contemporaneamente il traffico, riducendo la dipendenza da un singolo punto di guasto.
La scelta della soluzione dovrebbe derivare da RTO, RPO, criticità del sistema, costo del fermo e possibilità tecniche.
Checklist: la tua applicazione è pronta per un guasto?
Vale la pena rispondere ad alcune domande semplici.
1. Abbiamo un backup?
È solo l’inizio.
2. Il backup è conservato in modo da proteggerlo anche da un guasto dell’ambiente di produzione?
3. Abbiamo mai eseguito un ripristino completo?
4. Quanto tempo richiede davvero il restore?
5. Conosciamo l’RTO?
6. Conosciamo l’RPO?
7. Siamo in grado di ripristinare non solo i dati, ma anche l’applicazione e la sua configurazione?
8. Abbiamo una procedura di recovery?
9. Più di una persona è in grado di eseguirla?
10. Abbiamo testato il failover?
11. L’ambiente di riserva è aggiornato?
12. Dopo le ultime modifiche al sistema abbiamo testato di nuovo il recovery?
Se a diverse domande rispondiamo „non lo so”, è un ottimo momento per esaminare la strategia di disaster recovery.
Il test più importante è: “Mostra”
Nell'IT è molto facile dire:
- “Abbiamo un backup.”
- “Abbiamo un server di riserva.”
- “Abbiamo una procedura.”
- “Abbiamo il disaster recovery.”
- Ma la sicurezza del sistema non dovrebbe basarsi solo sulle dichiarazioni.
La domanda più importante è: Mostra che puoi ripristinarlo.
- Avvia il ripristino.
- Misura il tempo.
- Controlla i dati.
- Testa l'applicazione.
- Esegui il failover.
- Verifica la procedura.
- Ripeti il test dopo cambiamenti significativi.
Solo allora si può dire che la strategia di recovery è stata verificata nella pratica.
Il backup protegge i dati. Il recovery ripristina il business
Questa è probabilmente la differenza più importante.
Il backup risponde alla domanda: “Abbiamo una copia?”
Il disaster recovery risponde a una domanda molto più difficile: “Dopo un guasto siamo in grado di tornare operativi?”
E tra l'uno e l'altro c'è l'intera architettura di ripristino: RPO, RTO, replica, backup, restore, failover, configurazione, procedure, responsabilità e test regolari.
Un sistema ben progettato non presume che il guasto non accadrà. Presume che prima o poi il guasto accadrà e bisognerà sapere cosa fare.
Perché la vera resilienza di un'applicazione non consiste nel fatto che non si rompe mai. Consiste nel fatto che, quando qualcosa va storto, l'organizzazione è in grado di tornare operativa in modo prevedibile, controllato e conforme alle esigenze del business.
Glossario
Disaster Recovery (DR) - strategia e procedure che consentono di ripristinare il funzionamento dei sistemi dopo un grave guasto.
Backup - copia dei dati destinata al loro successivo ripristino.
Restore - processo di ripristino dei dati o del sistema da una copia.
RTO (Recovery Time Objective) - tempo massimo accettabile per il ripristino del sistema.
RPO (Recovery Point Objective) - massima perdita di dati accettabile espressa nel tempo.
Failover - passaggio del funzionamento del sistema dall'ambiente principale a quello di riserva.
Failback - ritorno del funzionamento all'ambiente principale dopo la rimozione della causa del guasto.
Recovery test - test volto a confermare che il sistema possa essere effettivamente ripristinato secondo i presupposti adottati.
Runbook - istruzioni dettagliate su come agire in uno specifico scenario di guasto.
