Quando si parla di backup, la discussione si concentra quasi sempre sullo strumento: quale software, quale storage, quale frequenza. Ma la domanda giusta viene prima e non è tecnica: quanto puoi permetterti di perdere? Due sigle aiutano a rispondere in modo preciso, e da quella risposta discende tutto il resto.
Le due misure
RPO: quanti dati puoi perdere
Il Recovery Point Objective indica la quantità massima di dati che è accettabile perdere, espressa in tempo. Un RPO di 24 ore significa che, dopo un disastro, si può ripartire dai dati di ieri. Un RPO di cinque minuti significa che si accetta di perdere al massimo gli ultimi cinque minuti di lavoro.
L'RPO determina la frequenza delle copie. Con un backup notturno, l'RPO reale è fino a 24 ore, perché un guasto alle 23 fa perdere tutta la giornata.
RTO: quanto tempo puoi restare fermo
Il Recovery Time Objective indica il tempo massimo entro cui il servizio deve tornare operativo. Un RTO di quattro ore significa che, dal momento del guasto, entro quattro ore gli utenti devono poter lavorare di nuovo.
L'RTO determina l'architettura del ripristino: copie pronte all'uso, server di riserva, automazione, procedure documentate.
Ogni servizio ha i suoi obiettivi
L'errore più comune è stabilire un unico obiettivo per tutto, di solito «zero perdite e zero fermi». È un obiettivo irrealistico e costoso. Un'analisi seria parte dall'elenco dei servizi e si chiede, per ciascuno, cosa succede se si ferma.
| Servizio | Impatto di un fermo | RPO ragionevole | RTO ragionevole |
|---|---|---|---|
| Negozio online | Vendite perse subito | Minuti | Un'ora o meno |
| Gestionale ordini | Lavoro bloccato | Un'ora | Poche ore |
| Sito vetrina | Immagine, nessuna perdita diretta | Un giorno | Un giorno |
| Archivio documenti storici | Basso nel breve periodo | Un giorno | Alcuni giorni |
I valori nella tabella sono esempi, non regole: dipendono dal tipo di attività. Il punto è che ogni riga richiede soluzioni diverse, con costi molto diversi.
Dagli obiettivi all'architettura
Più gli obiettivi sono stringenti, più la soluzione è complessa. Le strategie classiche, in ordine crescente di costo, sono quattro.
- Backup e ripristino: copie periodiche conservate altrove. In caso di disastro si ricrea l'infrastruttura e si ripristinano i dati. Costa poco, ma l'RTO si misura in ore o giorni.
- Pilot light: i dati vengono replicati continuamente verso un'altra regione o fornitore, ma i server applicativi sono spenti o ridotti al minimo. In caso di disastro si accendono e si dimensionano. RTO di decine di minuti o qualche ora.
- Warm standby: una copia ridotta ma funzionante dell'intero sistema è sempre attiva altrove. Basta aumentarne le risorse e spostare il traffico. RTO di minuti.
- Attivo-attivo: il sistema gira contemporaneamente in più sedi, ciascuna in grado di reggere il carico. Un guasto di una sede viene assorbito dalle altre. RTO prossimo a zero, ma complessità e costi elevati, soprattutto per mantenere coerenti i dati.
Per l'RPO la logica è simile: dal backup giornaliero si passa al backup orario, poi alla replica continua dei log del database, fino alla replica sincrona, che però rallenta ogni scrittura.
Il piano scritto
Un piano di disaster recovery non è un elenco di buone intenzioni, ma un documento operativo che qualcuno deve poter seguire sotto pressione. Dovrebbe contenere:
- l'elenco dei servizi con i relativi RPO e RTO e le dipendenze tra loro;
- dove si trovano i backup, come vi si accede e dove sono custodite chiavi e password necessarie;
- le procedure di ripristino passo per passo, nell'ordine corretto: prima la rete e il DNS, poi i database, poi le applicazioni;
- chi decide di attivare il piano e chi esegue ciascuna parte, con contatti di riserva;
- come comunicare con utenti e clienti durante l'emergenza.
Il piano va conservato anche fuori dall'infrastruttura che descrive. Un documento salvato solo sul server che si è appena guastato non serve a nessuno.
Provare, misurare, correggere
L'unico modo per sapere se gli obiettivi sono raggiungibili è simulare un disastro. Una prova può essere semplice: ripristinare il database di produzione in un ambiente isolato e cronometrare l'operazione. Oppure più completa: ricreare l'intero servizio in un'altra regione partendo solo dal piano scritto e dai backup.
Le prove rivelano sempre qualcosa. Una password che nessuno ricorda, un passaggio dato per scontato, un ripristino che richiede il doppio del tempo previsto. Nel mio lavoro preferisco una prova imperfetta ogni sei mesi a un piano perfetto mai provato. Dopo ogni prova il documento va aggiornato con ciò che si è imparato.
In sintesi
- L'RPO misura quanti dati puoi perdere e determina la frequenza delle copie.
- L'RTO misura quanto tempo puoi restare fermo e determina l'architettura del ripristino.
- Stabilisci obiettivi diversi per servizi diversi, in base all'impatto reale di un fermo.
- Le strategie vanno da backup e ripristino fino all'attivo-attivo, con costi crescenti.
- Un piano scritto, conservato altrove e provato regolarmente è l'unica garanzia concreta.
