La maggior parte dei diagrammi di architettura assume che l’edificio sia ancora in piedi. Il disaster recovery è la disciplina di chiedersi cosa succede quando non lo è. La region primaria si oscura per sei ore. Il database di produzione viene corrotto da una migrazione cattiva passata pulitamente per la review. Un payload ransomware cifra ogni file su cui il service account di produzione può scrivere. Un vendor da cui dipendi per l’identità ha un’outage globale e il tuo control plane è irraggiungibile.
Questi eventi sono rari. Non sono zero. Una piattaforma abbastanza vecchia da contare ne vedrà almeno uno, e la domanda quel giorno è se il team ha provato la risposta o la sta improvvisando. Improvvisare un recovery alle 4 di mattina con il CEO in conference call è il peggior momento possibile per scoprire che i backup falliscono in silenzio da undici mesi.
Il disaster recovery è una preoccupazione separata dal lavoro day-to-day di reliability che riempie il Modulo 8. SLO e turni di on-call gestiscono i fallimenti che capitano settimanalmente: un crash di un pod, un noisy neighbour, un deploy da rollare indietro. Il DR gestisce i fallimenti che capitano raramente e contano enormemente. La forma del problema è diversa, gli strumenti sono diversi, e la disciplina è diversa.
Due manopole: RTO e RPO
Ogni conversazione DR comincia con due numeri, e gli argomenti che li saltano producono piani che non soddisfano nessuno.
Recovery Time Objective, RTO, è quanto a lungo il business è disposto a stare senza il servizio dopo un disastro. Un RTO di un’ora significa che il servizio deve essere tornato entro un’ora dalla dichiarazione del disastro. Un RTO di un giorno significa che un’intera giornata di downtime è tollerabile, dolorosa ma sopravvivibile. L’RTO è una decisione di business vestita in linguaggio ingegneristico: chiede ai dirigenti quanto costa loro il downtime, e produce un budget che l’architettura deve rispettare.
Recovery Point Objective, RPO, è quanta perdita di dati è accettabile. Un RPO di zero significa che nessuna transazione può andare persa. Un RPO di un’ora significa che puoi perdere fino a un’ora di dati e il business funzionerà ancora. Un RPO di un giorno significa che puoi perdere un giorno, il che suona estremo finché non ti ricordi che un sistema di finanza aziendale probabilmente può.
Le due manopole sono indipendenti. Un servizio può avere un RTO veloce e un RPO lasco: il sito è tornato in cinque minuti ma ha perso l’ultima ora di ordini, che il team ricostruirà dai log. Un servizio può avere un RTO lento e un RPO stretto: il magazzino può stare giù mezza giornata durante il recovery ma nessuna riga ha il permesso di scomparire. Il mix dipende da cosa fa il sistema. Pagamenti e ledger hanno RPO stretto; le piattaforme analytics hanno spesso RPO lasco e RTO moderato; gli strumenti interni hanno di solito tolleranze generose su entrambi.
La versione onesta di una conversazione su RTO e RPO è scomoda, perché la domanda “quanto costa il downtime all’ora?” raramente ha una risposta pulita. Il team sceglie un numero che sembra difendibile, i dirigenti rilanciano, ed emerge un compromesso. Quel numero poi guida ogni successiva decisione architetturale in questa lezione. Senza, il team costruisce qualunque cosa sembri prudente, che di solito è troppo per i piccoli servizi e non abbastanza per quelli critici.
Le quattro DR tier
L’industria ha una tassonomia approssimativa delle strategie DR, ognuna che atterra su un punto diverso del trade-off costo contro RTO/RPO. Chiamarle “tier” rende esplicita la scala: ogni gradino in alto è più costoso di quello sotto, e la domanda è quale gradino corrisponde alla tolleranza del business.
Tier 1: backup and restore. L’opzione più economica. Backup periodici vanno su storage durabile; quando il disastro colpisce, il team ricostruisce il sistema da zero in una nuova region o account, ripristina i dati, e ci punta il traffico. L’RTO è da ore a giorni, a seconda di quanto c’è da ricostruire. L’RPO è l’intervallo di backup, tipicamente ore. Questo è il tier giusto per i sistemi in cui il downtime prolungato è fastidioso ma non esistenziale: dashboard interne, batch reporting, il wiki.
Tier 2: pilot light. Una versione minimale dello stack di produzione gira continuamente in una recovery region: il database sta replicando, ma gli application server sono scalati a zero o quasi. Al disastro, il team scala su l’applicazione, ci punta il traffico, e gira. L’RTO scende a ore. L’RPO scende a minuti, perché il database ha ricevuto aggiornamenti tutto il tempo. Il costo è l’infrastruttura di replica permanente più una piccola impronta di risorse sempre accese.
Tier 3: warm standby. Una copia ridotta dell’intero stack gira nella recovery region, gestendo un po’ di traffico reale o stando solo a riposo. Al failover, lo standby scala a piena capacità e assorbe tutto il traffico. L’RTO è in minuti; l’RPO in secondi. Il costo è significativo: grossomodo metà di un ambiente di produzione che gira continuamente, più il carico operativo continuo di tenere i due lati in sync (config, secret, deploy pipeline, schema migration).
Tier 4: active-active. Entrambe le region sono live e servono traffico. Il failover è solo una decisione di traffic-steering: tagliare il DNS o i pesi del load balancer verso il lato sopravvissuto. L’RTO è in secondi; l’RPO è zero, modulo il modello di consistenza che il team ha scelto per le scritture cross-region. Questo è il tier più costoso e anche il più esigente: ogni servizio dev’essere progettato per girare multi-master, ogni dataset dev’essere replicato con conflict resolution, ogni deploy dev’essere rilasciato a entrambe le region in passo. L’active-active è quello che fanno girare le banche e le ad network perché il costo del downtime è misurato in milioni al minuto. Per la maggior parte delle aziende, è eccessivo.
flowchart LR
BR[Backup and restore<br/>RTO hours-days<br/>RPO hours]
PL[Pilot light<br/>RTO hours<br/>RPO minutes]
WS[Warm standby<br/>RTO minutes<br/>RPO seconds]
AA[Active-active<br/>RTO seconds<br/>RPO zero]
BR --> PL --> WS --> AA
BR -.cheapest.-> AA
AA -.most expensive.-> BRIl piano DR della maggior parte delle aziende è “abbiamo i backup”, che è tier 1, e la maggior parte di queste aziende non ha mai testato il restore. La sezione successiva è sul perché questo è il problema centrale.
Il drill
I piani DR non testati non funzionano. Questa frase è il cuore della lezione e la maggior parte dei team le resiste, perché testare il DR è costoso, dirompente, e raramente produce un deliverable che la roadmap del trimestre successivo premia.
Lo schema è affidabile. Un team scrive un runbook DR tre anni fa. Il runbook dice “in un disastro, ripristina dallo snapshot S3 prod-db-snapshot, riavvia i worker, punta il DNS verso la recovery region”. Passa il tempo. Il bucket S3 viene rinominato. Il provider DNS viene migrato. Il worker pool viene riscritto. Il runbook fa ancora riferimento ai vecchi nomi. Nessuno nel team di on-call l’ha mai letto. Il team che l’ha scritto se n’è andato due anni fa. Il giorno del disastro, il runbook è finzione.
La disciplina che sistema questo è il drill. Una cadenza ragionevole è trimestrale: ogni trimestre, il team sceglie uno scenario (region failure, corruzione del database, ransomware) e percorre il runbook end to end. A volte il drill è un esercizio tabletop in cui il team cammina attraverso gli step verbalmente e conferma che esistono. A volte è una simulazione completa: il team fa effettivamente failover sulla recovery region, ripristina effettivamente da un backup reale in un ambiente reale, cronometra effettivamente quanto ci ha messo. I drill tabletop trovano i peggiori gap a basso costo; le simulazioni complete trovano i gap che si manifestano solo sotto carico.
Ogni drill produce una lista di cose che non hanno funzionato. Il nome del bucket S3 era sbagliato. Il ruolo IAM richiesto per eseguire il restore era stato cancellato. Il runbook diceva “page il database team” e il database team è un team diverso da otto mesi. La lista va nel backlog e il drill successivo verifica i fix. Col tempo, il runbook inizia a essere un documento vivo invece di un artefatto.
L’inquadramento che aiuta il drill ad accadere è semplice: un piano DR che non è stato drillato è approssimativamente buono come nessun piano. Il CFO preferirebbe saperlo in un trimestre tranquillo che durante un disastro vero.
Recuperare il sistema, recuperare i dati
Una distinzione utile. I backup proteggono i dati. I runbook proteggono il tempo.
Una postura DR completa ha bisogno di entrambi. I soli backup lasciano il team con un tarball e nessun modo di usarlo: nulla che gira, nessun DNS, nessun service account con i permessi giusti, nessuna versione del codice applicativo che corrisponda allo schema del backup. I soli runbook, senza backup reali dietro, lasciano il team con un playbook bellissimo che finisce in “e poi i dati tornano in qualche modo”.
I team che fanno DR bene trattano i due artefatti come una coppia accoppiata. Ogni backup ha un runbook corrispondente che descrive come ripristinarlo in un sistema funzionante. Ogni runbook è stato testato contro un backup reale. La coppia è ciò che si drilla.
Questo si collega alla discussione sui backup nella lezione 31: un backup che non è mai stato ripristinato non è davvero un backup, è un’aspirazione. Il drill è la parte che converte l’aspirazione in capacità.
I fallimenti DR comuni
Un breve catalogo di fallimenti che si manifestano nei recovery reali, tutti reali, tutti prevenibili.
Il backup che non si ripristina. Il team fa girare backup giornalieri da anni. Il giorno del disastro, il restore fallisce: il formato del backup è cambiato in un upgrade del database, la chiave di cifratura è stata ruotata, la policy del bucket nega al ruolo di recovery. Il team lo scopre nel giorno peggiore possibile. Prevenzione: test di restore regolari, idealmente automatizzati, che confermano che i backup possono effettivamente essere caricati in un database funzionante.
Il runbook che fa riferimento a servizi che non esistono più. Menzionato sopra. Il fix è il drill. Un runbook che non è stato letto in diciotto mesi è finzione non letta.
Credenziali che nessuno nel team di on-call ha. Il recovery richiede di loggarsi nella console di un vendor con una credenziale che vive nel password manager di una persona, e quella persona è in vacanza in un paese con copertura mobile cattiva. Prevenzione: ogni credenziale necessaria per il recovery sta in uno shared secret store con procedure di break-glass, e le procedure fanno parte del drill.
DNS che punta a server morti. Il runbook dice “fai failover aggiornando il CNAME”. Il CNAME è stato aggiornato. Non succede nulla, perché il TTL è 24 ore e i client stanno ancora risolvendo il vecchio indirizzo. Prevenzione: TTL bassi sui record DNS che partecipano al failover, più un test reale dello swap del CNAME durante il drill.
La recovery region che non ha capacità. Il team ha un warm standby in un’altra region. Al failover, lo standby non riesce a scalare su, perché il cloud provider ha esaurito la capacità per quel tipo di istanza in quella region. Prevenzione: capacity reservation, o una strategia pilot light che non dipenda dallo scaling istantaneo nel peggior momento possibile.
Lo schema in tutto questo è lo stesso: il fallimento è raramente nel design del piano DR e quasi sempre nel gap tra il piano e la realtà. Il drill chiude il gap.
Come il DR si collega al multi-region
La lezione 75 ha coperto il multi-region come topologia di deployment. Il multi-region è un modo specifico di costruire una postura DR: tier 3 o tier 4, a seconda di quanto dello stack è replicato e di quanto attivo è lo standby. Un deployment multi-region active-active è, per costruzione, un piano DR tier 4. Un deployment multi-region active-passive è un warm standby.
Il punto da tenere a mente: il multi-region è uno strumento nel kit DR, non l’intero kit. Un team che gira in una singola region può comunque avere un piano DR serio, costruito sui backup e sul recovery pilot light in una region diversa o anche in un cloud diverso. Un team che gira active-active può comunque essere vulnerabile a disastri che si propagano fra le region: un deploy cattivo che fa crashare entrambi i lati, un bug del software che corrompe il dataset replicato, un payload ransomware che segue il percorso di replica. L’active-active non protegge da questi; solo i backup separati dalle credenziali di produzione lo fanno. Ridondanza geografica e backup separati nel tempo sono controlli complementari, non sostituti.
Cosa significa “fatto bene”
Un team con una postura DR sana ha, come minimo, quanto segue. Numeri RTO e RPO che il business ha approvato. Un DR tier accoppiato a quei numeri. Backup cifrati, durabili, e testati con restore automatizzato almeno mensilmente. Un runbook drillato negli ultimi tre mesi. Una lista di credenziali e procedure di break-glass che il team di on-call ha effettivamente usato nell’ultimo drill. Uno scenario di fallimento documentato, percorso, con i gap dell’ultimo drill nel backlog e i gap del drill precedente chiusi.
Niente di tutto questo è glamour. Niente di tutto questo spedisce feature. Tutto questo è la differenza tra un recovery serio e uno caotico quando arriva il giorno.
La prossima lezione è sull’architettura di sicurezza che previene la maggior parte dei disastri da cui il DR esiste per recuperare: l’IAM, la segmentazione di rete, il secret management, e l’audit logging che mantengono la threat surface abbastanza piccola da rendere il DR raramente la risposta di ultima istanza.
Citazioni e ulteriori letture
- AWS, “Disaster Recovery of Workloads on AWS: Recovery in the Cloud”,
https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html(consultato 2026-05-01). La trattazione canonica del modello a quattro tier usato in questa lezione, con numeri concreti di RTO/RPO per tier. - Google Cloud, “Disaster recovery planning guide”,
https://cloud.google.com/architecture/dr-scenarios-planning-guide(consultato 2026-05-01). La stessa scala concettuale, presentata dalla prospettiva GCP, con esempi lavorati per ogni tier. - Microsoft Azure, “Business continuity and disaster recovery”,
https://learn.microsoft.com/en-us/azure/reliability/concept-business-continuity-high-availability-disaster-recovery(consultato 2026-05-01). L’inquadramento di Azure, comprese definizioni utili di business continuity vs DR. - NIST SP 800-34 Rev. 1, “Contingency Planning Guide for Federal Information Systems”,
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final(consultato 2026-05-01). Il riferimento di livello governativo sulla pianificazione di contingenza, compresa la disciplina del testing.