Strategie DR e RTO/RPO

1) Principi di base

1. Obiettivi prima dei mezzi. Prima formuliamo RTO/RPO e scenari critici, poi scegliamo la tecnologia.
2. Segmentazione per importanza. Non tutti i servizi richiedono l'oro; suddivisi in termini di criticità aziendale.
3. I dati sono il kernel DR. Consistenza, replica, rilevamento dello strappo e punto di ripristino sono più importanti del ferro.
4. Automazione e convalida. Il Dottor non ha senso, senza test di riabilitazione e di telemetria.
5. Insegnamenti e prove. Un piano senza «game day» regolare è un'illusione di preparazione.
6. Sicurezza e compliance. Crittografia, isolamento, back-up WORM/immutabili, DPA/giurisdizione.

2) Termini e corrispondenze

RTO - Tempo dal momento dell'evento al ripristino del servizio «normale».
RPO è «l'età» dell'ultimo punto di recupero sano.
RLO (Recovery Level Objective) è il livello di funzionalità che è obbligato a ripristinare (servizio minimamente sostenibile).
MTD è la soglia dopo la quale le imprese subiscono danni inaccettabili.
RTA/RPA - Tempo effettivo/punto di ripristino dalla pratica.

Comunicazione RTO ≤ MTD; RPA ≤ RPO. Il divario tra gli obiettivi e i fatti è un oggetto post - mortem e miglioramenti.

3) Classi di strategie DR (livelli di preparazione)

4) Script contro cui difenderci

Perdita della regione/cloud/centro dati (elettricista, rete, provider).
Corruzione dei dati/errore dell'operatore (rimozione, battitura, rottura logica).
Malware/crittografatore (ransomware).
Errore di rilascio/configurazione (outage di massa).
Crollo della dipendenza (KMS, DNS, segreti, provider di pagamenti).
Eventi legali (blocchi, impedimento dell'estrazione dei dati dalla giurisdizione).

Per ogni script, specificare RTO/RPO, livello DR, playbook, responsabili.

5) Strategie dei dati (chiave RPO)

5. 1 Bacapi

Registri transazioni completi + incrementali + (per database).
Archivi immutabili/WORM e copie off-line (air-gapped).
Directory dei bacapi con metadati e criptopodesche Test di ripristino programmati.

5. 2 Replica

Sincrona (RPO basso, ↑latentnost, rischio di distruzione).
Asincrona (bassa influenza su perf, RPO> 0; combinare con un oggetto di rottura).
CDC (Change Data Capture) per la replica in streaming e la ricostruzione dello stato.

5. 3 Protezione contro la rottura logica

Versioning/punti nel tempo (PITR) con finestra ≥ N giorni.
Le firme degli invarianti (bilanci, importi, chexumma) sono il primo dettaglio dei dati.
I canali di replica lenti (delay 15-60 min) sono un buffer contro la rottura istantanea.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) Applicazione, stato, cache

Staitless - Scalabile e riavviabile in qualsiasi regione (immagine/elenco/manifesto in Git).
Stato (BD/cache/kew): la sorgente della verità è uno dei database; la cache e gli indici sono surrogabili.
Idampotenza e re-drive - La nuova consegna degli eventi è consentita; usate outbox/inbox, deadup e versioni.

7) Rete e punto di ingresso

Failover GSLB/DNS: latency/health-based, TTL brevi alla finestra dell'incidente.
Anycast/L7-proxy: unico IP, routing per la salute delle regioni.
Domini regionali e criteri di giurisdizione (geo-pinning per PII).
Feelover certificati/KMS - catene di riserva, dual-key.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) Modello operativo e automazione

IaC/GitOps: infrastruttura della seconda regione = codice, installazione «monouso».
Policy as Code: gate «Nessun manifesto DR/bacap/alert - nessun rilascio».
Runbooks - istruzioni passo-passo e «pulsante rosso» identiche a entrambe le regioni.
I segreti sono crediti a breve termine, la Federazione OIDC, un piano di compromissione/ritiro.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) Esercitazioni e test (Game Days)

La tabella degli scenari è la perdita di database, i dati «battuti», l'interruzione di KMS, la caduta della regione, il limite di egress improvviso.
Frequenza: trimestrale per missione-critici; Ogni sei mesi, per gli altri.
Metriche esercitazioni: RTA/RPA vs obiettivi, quota di passi automatici, numero di interventi manuali, errori playbook.
Chaos-smoke nelle release: la degradazione delle dipendenze non deve «rompere» i percorsi DR.

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) Playbook (modello canonico)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) Metriche di osservabilità DR

Replica lag (secondi), RPO-drivt (differenza tra RPO target e RPO effettivo).
Restore SLI: tempo di ripristino freddo/caldo per ambienti.
Coverage:% di servizi con playbook/backap/PITR-N giorni.
Drill score: quota di passaggi automatici, distribuzione RTA, frequenza di errori.
Immutabilità:% backup in WORM/air-gapped.
Metriche di evento: lunghezza delle code/velocità re-drive dopo il feelover.

12) Costi e compromessi

CapEx/OpEx: lo stand caldo è più economico di Active/Active, ma più costoso di Pilot Light.
Egress: la replica interregionale/trasversale costa denaro; cache/compressione/unità locali.
RTO/RPO vs $: ogni nove disponibilità e un secondo RPO costano il doppio - concordare con il business.
Finestre verdi: replica batch - in orologi economici/verdi.

13) Sicurezza e compliance

Crittografia «in pace» e «in transito», domini KMS separati per regione.
Bap immutabili, protezione da ransomware: «3-2-1» (3 copie, 2 supporti, 1 off-line), MFA-delete.
Giurisdizione: geo-pinning per PII, localizzazione dei backup, Legale Hold sopra TTL.
Disponibili in base al tempo: ruoli temporanei per le operazioni DR, registro di verifica.

14) Anti-pattern

«Scriviamo un piano più tardi», dottor senza esercitazioni.
Replicare senza una protezione da una rottura logica può creare un errore.
Una regione di KMS/segreti è impossibile da fare.
I Becap senza ripristini regolari sono il DOTTOR Shredinger.
Transazioni sincroni strettamente correlate tra le regioni - latitanza a cascata/calo.
Nessuna priorità: lo stesso livello DR per tutto (costoso e inutile).

15) Assegno-foglia architetto

1. RTO/RPO/RLO definiti per servizi e script?
2. Dati classificati: origine verità, PITR/finestra, WORM/immutabile?
3. È stato selezionato il livello DR (Backup/Restore, Pilot, Warm, A/P, A/A) per il servizio?
4. Rete: GSLB/Anycast, certificati/chiavi di riserva, bandiere «read-only»?
5. Idampotenza, outbox/inbox, transazioni compensative?
6. IaC/GitOps/Policy as Code, un click per la seconda regione?
7. Roadmap, KPI RTA/RPA, post-training?
8. Monitoraggio: lag, RPO-drivt, restore-SLI, drill-score, backap immutabili?
9. Sicurezza/Compilation: domini KMS, giurisdizione, Legale Hold?
10. Costo: budget egress, finestre verdi, livello ragionevole?

16) Mini-ricette e sketch

16. 1 PITR per Postges (idea):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 Protezione contro la rottura logica (replica ritardata):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 Cambio di traffico (pseudo-API GSLB):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 Verifica degli invarianti dopo il feelover (pseudocode):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

Conclusione

Il DR è la capacità di prendere decisioni tecniche e organizzative più velocemente di un aumento dei danni. Definire RTO/RPO realistici, scegliere un livello di preparazione adeguato, automatizzare l'infrastruttura e i controlli, allenarsi regolarmente e misurare RTA/RPA effettivi. Allora l'incidente non si trasformerà in un disastro, ma in un incidente gestito con esito prevedibile.