Planificarea disaster recovery: RTO, RPO și testele pe care nu le rulează nimeni

Iată o întrebare care ține CTO-ii treji noaptea: dacă datacenter-ul tău principal ar cădea chiar acum — incendiu, pană de curent, fibră tăiată — cât ar dura până când clienții tăi ar putea folosi din nou produsul?

Dacă răspunsul este „nu știu” sau „depinde cine e treaz”, nu ai un plan de disaster recovery. Ai un document de disaster recovery.

Diferența dintre un plan și un document este testarea.

RTO și RPO: cele două numere care contează

Înainte să proiectezi orice, definește-ți țintele:

RTO (Recovery Time Objective): Cât timp poți sta jos?

• 4 ore? Asta e o migrare de weekend.
• 1 oră? Asta e failover automat cu verificare manuală.
• 5 minute? Asta e active-active multi-region.

RPO (Recovery Point Objective): Câte date poți pierde?

• 24 de ore? Backup-urile zilnice sunt suficiente.
• 1 oră? Snapshot-uri orare sau replicare streaming.
• 0? Replicare sincronă între site-uri.

Aceste ținte determină fiecare decizie de arhitectură. Și ar trebui să vină din partea business-ului, nu a inginerilor:

Nivel de serviciu	RTO	RPO	Strategie
Tier 1 (critic pentru venituri)	15 min	0	Active-active, replicare sincronă
Tier 2 (important)	1 oră	15 min	Warm standby, replicare asincronă
Tier 3 (unelte interne)	4 ore	1 oră	Cold standby, snapshot-uri orare
Tier 4 (non-critic)	24 de ore	24 de ore	Doar backup-uri

Strategiile de DR

Backup și restaurare (Cold DR)

Cea mai simplă strategie. Faci backup-uri. Le stochezi offsite. Le restaurezi când e nevoie.

Primary DC ──── Backups ────→ Object Storage (different region)
                (nightly)
                
Disaster: Provision new infra → Restore from backup → DNS switch
Time: 4-24 hours

Potrivit pentru: servicii Tier 3-4, medii de dezvoltare, workload-uri sensibile la cost.

Capcana: RTO-ul tău depinde de cât de repede poți provizona infrastructură nouă ȘI restaura datele. Restaurarea unei baze de date de 2TB durează ore, nu minute.

Warm standby (Pilot Light)

Ții în funcțiune un mediu replică minimal. Infrastructura de bază este pre-provizonată, dar scalată în jos.

Primary DC                    DR Site
┌──────────┐                 ┌──────────┐
│ 8 app    │  async          │ 1 app    │ (scaled down)
│ servers  │  replication    │ server   │
│          │ ──────────────→ │          │
│ DB primary│                │ DB replica│
│ 3 nodes  │                │ 1 node   │
└──────────┘                └──────────┘

Disaster: Scale up DR site → Promote DB replica → DNS switch
Time: 15-60 minutes

Potrivit pentru: servicii Tier 2. Site-ul de DR costă ~20% din producție (rulează, dar minimal). Scalarea în sus este rapidă pentru că infrastructura de bază există deja.

Active-passive (Hot standby)

Mediu replică complet, scalat integral, care primește replicare de date în timp real. Gata să servească trafic imediat.

Primary DC                    DR Site
┌──────────┐                 ┌──────────┐
│ 8 app    │  sync/async     │ 8 app    │ (full scale)
│ servers  │  replication    │ servers  │
│          │ ──────────────→ │          │
│ DB primary│                │ DB replica│
│ 3 nodes  │                │ 3 nodes  │
└──────────┘                └──────────┘

Disaster: Promote DB replica → DNS switch
Time: 5-15 minutes

Potrivit pentru: servicii Tier 1. Costul este ~100% din producție (rulezi două exemplare din tot). Dar failover-ul este rapid.

Active-active (Multi-Region)

Ambele site-uri servesc trafic simultan. Nu e nevoie de failover — dacă un site cade, celălalt absoarbe încărcarea.

          ┌── Load Balancer (Global) ──┐
          │                            │
     Region A                     Region B
   ┌──────────┐               ┌──────────┐
   │ App servers│              │ App servers│
   │ DB node   │←── sync ───→│ DB node   │
   └──────────┘               └──────────┘

Potrivit pentru: servicii Tier 1 care nu au voie să cadă sub nicio formă. Costul este de 2x+ (iar complexitatea de 5x). Trebuie să rezolvi consistența datelor, rezolvarea conflictelor și rutarea scrierilor.

Strategia de backup

Indiferent de nivelul de DR, backup-urile sunt fundația. Strategia noastră de backup:

Regula 3-2-1

• 3 copii ale datelor
• 2 tipuri diferite de stocare
• 1 offsite (altă regiune geografică)

Production DB
  ├── Streaming replica (same DC, different rack)
  ├── Daily snapshot → local NVMe backup server
  └── Daily snapshot → S3-compatible storage (different region)
      └── Retained: 7 daily, 4 weekly, 12 monthly

Testarea backup-urilor

Un backup care nu a fost restaurat nu este un backup. Este o speranță.

Noi testăm restaurările în fiecare lună:

#!/bin/bash
# Monthly backup verification

# 1. Download latest backup from offsite storage
aws s3 cp s3://backups/db/latest.dump /tmp/restore-test/

# 2. Restore to isolated test instance
pg_restore -h test-db -d restore_test /tmp/restore-test/latest.dump

# 3. Run validation queries
psql -h test-db -d restore_test -c "
  SELECT count(*) FROM users;
  SELECT count(*) FROM orders WHERE created_at > now() - interval '24 hours';
  SELECT max(created_at) FROM events;
"

# 4. Compare row counts with production
# 5. Alert if deviation > 0.1%

# 6. Cleanup
dropdb -h test-db restore_test

Dacă pasul 2 eșuează, afli acum — nu în timpul unui dezastru real.

DNS și comutarea traficului

Când lovește dezastrul, trebuie să redirecționezi traficul către site-ul de DR. Opțiuni:

DNS failover

api.kicked.ro → Primary IP (health check: pass)
                 ↓ health check fails
api.kicked.ro → DR IP (automatic switch)

TTL-ul contează. Dacă TTL-ul tău de DNS este 3600 (1 oră), clienții vor continua să lovească primary-ul mort până la o oră după ce ai comutat. Noi setăm TTL-urile serviciilor critice la 60 de secunde.

Anycast

Cu anycast, același IP este anunțat din mai multe locații prin BGP. Traficul se rutează automat către cel mai apropiat site sănătos. Așa gestionăm noi failover-ul pe AS210622 — fără nicio modificare de DNS.

Load balancer global

Cloudflare, AWS Global Accelerator sau similar. Health check-uri + failover automat la marginea rețelei. Cea mai rapidă opțiune pentru trafic HTTP/S.

Testul de DR: Chaos Day

Singurul mod de a ști că DR-ul tău funcționează este să îl testezi. Noi rulăm teste de DR trimestrial:

Procedura de test

1. Anunță testul — Părțile interesate știu că vine (la început)
2. Simulează defecțiunea — Blochează traficul către primary, oprește baza de date etc.
3. Execută runbook-ul — Urmează procedura documentată pas cu pas
4. Măsoară — Înregistrează RTO-ul și RPO-ul reale
5. Restaurează — Fă failback la primary
6. Post-mortem — Ce s-a stricat? Ce a fost mai lent decât te așteptai? Actualizează runbook-ul.

Ce urmărim

Metrică	Țintă	Ultimul test
Timp până la detectarea defecțiunii	< 2 min	1 min 23s
Timp până la inițierea DR	< 5 min	3 min 45s
Timp până la serviciu complet (RTO)	< 15 min	11 min 12s
Pierdere de date (RPO)	< 1 min	0 (replicare sincronă)
Acuratețea runbook-ului	100%	94% (2 pași învechiți)

Ultima metrică — acuratețea runbook-ului — este motivul pentru care testezi. Fiecare test scoate la iveală pași care s-au îndepărtat de realitate.

Eșecuri frecvente pe care le-am văzut

1. TTL de DNS prea mare — TTL de 1 oră înseamnă failover de 1 oră. Setează-l la 60s pentru serviciile critice.
2. Restaurarea din backup niciodată testată — Backup-ul a fost corupt timp de 3 luni. Nimeni n-a știut.
3. Site de DR subdimensionat — „Scalăm când avem nevoie.” Scalarea durează 20 de minute. RTO-ul tău e 15.
4. Credențiale nesincronizate — Site-ul de DR nu se poate conecta la procesatorul de plăți pentru că API key-urile nu au fost replicate.
5. Fără runbook — Singura persoană care știa procedura era în concediu.
6. Backup-uri într-o singură regiune — Backup-uri în același DC cu producția. Cade DC-ul, cad și backup-urile odată cu el.

Începe azi

1. Definește-ți nivelurile — Nu totul are nevoie de active-active. Clasifică-ți serviciile.
2. Implementează backup-uri 3-2-1 — Offsite, testate lunar.
3. Scrie runbook-ul — Pas cu pas, presupunând că cititorul nu a făcut asta niciodată.
4. Testează o dată — Chiar și un singur test va scoate la iveală lipsuri critice.
5. Programează teste trimestriale — Pune-le în calendar. Altfel nu se vor întâmpla.

Ai nevoie de ajutor ca să construiești sau să testezi planul de DR? Am proiectat disaster recovery pentru orice, de la setup-uri cu un singur server până la platforme multi-region. Hai să ne asigurăm că infrastructura ta supraviețuiește celei mai proaste zile.