# 🔄 Disaster Recovery a Business Continuity

## Terminologie

| Zkratka | Význam | Popis |
|---------|--------|-------|
| **RTO** | Recovery Time Objective | Maximální doba od výpadku do obnovení služby |
| **RPO** | Recovery Point Objective | Maximální přípustná ztráta dat (čas od poslední zálohy) |
| **MTD** | Maximum Tolerable Downtime | Celková doba výpadku, kterou organizace přežije |
| **WRT** | Work Recovery Time | Čas potřebný k plnému obnovení provozu po obnovení IT |
| **MTBF** | Mean Time Between Failures | Střední doba mezi poruchami |
| **MTTR** | Mean Time To Repair | Střední doba opravy |
| **SLA** | Service Level Agreement | Smluvní závazek dostupnosti |
| **SLO** | Service Level Objective | Interní cíl dostupnosti |
| **SLI** | Service Level Indicator | Naměřená hodnota dostupnosti |

### Vztah RTO, RPO, MTD, WRT

```
Výpadek ──── RPO ────► Obnova dat ──── RTO ────► Služba běží ──── WRT ────► Plný provoz
             │                      │                            │
             ▼                      ▼                            ▼
       Ztracená data          Čas bez služby               Čas do plného výkonu

       MTD = RTO + WRT (max. doba, kterou firma toleruje)
```

---

## Výpočet uptimu

### Tabulka devítek

| Úroveň | Uptime | Downtime / rok | Downtime / měsíc | Downtime / týden |
|--------|--------|---------------|------------------|------------------|
| 90 % (jedna devítka) | 0.9 | 36,5 dne | 72 h | 16,8 h |
| 99 % (dvě devítky) | 0.99 | 3,65 dne | 7,2 h | 1,68 h |
| 99,5 % | 0.995 | 1,83 dne | 3,6 h | 50,4 min |
| 99,9 % (tři devítky) | 0.999 | 8,76 h | 43,2 min | 10,1 min |
| 99,95 % | 0.9995 | 4,38 h | 21,6 min | 5,04 min |
| 99,99 % (čtyři devítky) | 0.9999 | 52,6 min | 4,32 min | 1,01 min |
| 99,995 % | 0.99995 | 26,3 min | 2,16 min | 30,2 s |
| 99,999 % (pět devítek) | 0.99999 | 5,26 min | 25,9 s | 6,05 s |
| 99,9999 % (šest devítek) | 0.999999 | 31,6 s | 2,59 s | 0,605 s |

### Výpočet

```
Dostupnost = (Celkový čas - Downtime) / Celkový čas × 100 %

Příklad:
  Rok = 365 × 24 × 60 = 525 600 minut
  Cíl: 99,9 % → povolený downtime = 525 600 × (1 - 0,999) = 525,6 minut = 8,76 h

Složená dostupnost (řetězec závislostí):
  A_web = 99,9 % (3 devítky)
  A_api  = 99,99 % (4 devítky)
  A_db   = 99,999 % (5 devítek)

  A_celkem = 0,999 × 0,9999 × 0,99999 = 0,99889 ≈ 99,89 % (méně než 3 devítky!)

Paralelní dostupnost (redundance):
  A_celkem = 1 - (1 - A_1) × (1 - A_2) × ... × (1 - A_n)

  Příklad: 2 servery s 99% dostupností
  A_celkem = 1 - (1-0,99) × (1-0,99) = 1 - 0,01 × 0,01 = 0,9999 (99,99 %)
```

### Kalkulačka

```python
def uptime_percent_to_downtime(pct, period_days=365):
    """Převede procento uptimu na downtime v daném období."""
    total_minutes = period_days * 24 * 60
    allowed_downtime = total_minutes * (1 - pct / 100)
    return allowed_downtime  # minutes

def downtime_to_uptime_percent(downtime_minutes, period_days=365):
    """Převede downtime v minutách na procento uptimu."""
    total_minutes = period_days * 24 * 60
    return (1 - downtime_minutes / total_minutes) * 100

def combined_availability(availabilities):
    """Složená dostupnost (sériově zapojené komponenty)."""
    result = 1.0
    for a in availabilities:
        result *= a
    return result

def redundant_availability(availabilities):
    """Paralelní dostupnost (redundantní komponenty)."""
    result = 1.0
    for a in availabilities:
        result *= (1 - a)
    return 1 - result
```

### Fallacies výpočtu

- **Složená dostupnost není součet** — přidání další závislosti vždy snižuje celkovou dostupnost
- **Redundance není zadarmo** — přidání standby komponenty vyžaduje detekci selhání + failover (MTTR se nezlepší automaticky)
- **SLA není garance** — poskytovatelé často počítají SLA jako měsíční průměr, ne per-incident
- **Měření je klíčové** — bez SLI nelze ověřit SLO; "nedoměřená dostupnost neexistuje"
- **Plánovaná odstávka** — někdy se počítá do uptimu, někdy ne (záleží na definici SLA)

---

## DR scénáře

### Klasifikace

| Kategorie | Scénář | Typický RTO | Typické RPO | Frekvence |
|-----------|--------|-------------|-------------|-----------|
| **Site** | Výpadek celého DC / regionu | hodiny | minuty | Nízká |
| **Infrastructure** | Selhání HW (storage, switch, server) | minuty–hodiny | sekundy | Střední |
| **Software** | Selhání OS, aplikace, DB | minuty | vteřiny | Vysoká |
| **Data** | Poškození dat, delete, cryptolocker | hodiny | okamžik zálohy | Nízká–střední |
| **Human** | Chybný deployment, config change | minuty–hodiny | vteřiny | Střední |
| **Security** | Útok, breach, ransomware | dny | před útokem | Nízká |
| **Network** | Výpadek konektivity, DDoS | minuty–hodiny | N/A | Střední |
| **Cloud provider** | Regionální výpadek (AWS, Azure, GCP) | hodiny | minuty | Velmi nízká |

### Detail scénářů

#### Site / Region failure

| Aspekt | Popis |
|--------|-------|
| **Příčina** | Blackout, požár, povodeň, zemětřesení, výpadek cloud providera |
| **Prevence** | Multi-AZ architektura, multi-region deployment, active-active |
| **Mitigace** | Automatický DNS failover (Route53, Azure Traffic Manager), replica v DR regionu |
| **Testování** | Game day: vypnout primární region, ověřit automatický failover |

#### Data corruption / human error

| Aspekt | Popis |
|--------|-------|
| **Příčina** | Chybný SQL příkaz (DELETE bez WHERE), omylem smazaný bucket, chybná migrace |
| **Prevence** | RBAC, MFA pro destructive operace, change management, peer review SQL |
| **Mitigace** | Point-in-time recovery (PITR), transaction log replay, immutable backups |
| **Testování** | Obnova zálohy do izolovaného prostředí, ověření integrity dat |

#### Ransomware / cyber attack

| Aspekt | Popis |
|--------|-------|
| **Příčina** | Útok na produkční systémy, zašifrování dat, exfiltrace |
| **Prevence** | Immutable backups (object lock), air-gapped backups, network segmentation |
| **Mitigace** | Obnova z čisté zálohy, re-build infrastructure from IaC |
| **Testování** | Pravidelná obnova v izolované síti, ověření že backup není infikován |

---

## Prevence — strategie

### Backup strategie

| Aproach | Popis | Use case |
|---------|-------|----------|
| **3-2-1 pravidlo** | 3 kopie, 2 různá média, 1 off-site | Univerzální |
| **3-2-1-0** | + 0 chyb po obnově (testování) | Enterprise, compliance |
| **GFS (Grandfather-Father-Son)** | Denní, týdenní, měsíční rotace | Dlouhodobý archiv |
| **Incremental forever** | Plná záloha 1×, pak jen změny | Velké objemy dat |
| **Reverse incremental** | Plná + inkrementální, plná je vždy aktuální | Rychlá obnova |

### Zálohovací metody

| Metoda | RPO | RTO | Úložiště | Vhodné pro |
|--------|-----|-----|----------|------------|
| **Full backup** | Poslední full | Doba obnovy full | Velké | Malá data, weekly |
| **Incremental** | Poslední inkrement | Full + všechny inkrementy | Malé | Velká data, daily |
| **Differential** | Poslední diff | Full + poslední diff | Střední | Kompromis |
| **Snapshot** | Okamžik snapshotu | vteřiny | Copy-on-write | VM, storage array |
| **Continuous (CDC)** | < 1 s | Sekundy | Log stream | DB (binlog, WAL) |
| **PITR** | Libovolný bod v čase | Dle objemu | Full + WAL | RDS, PostgreSQL, SQL Server |

### Imunabilita backupů

Klíčová ochrana proti ransomwaru:

| Technika | Popis |
|----------|-------|
| **Object Lock (WORM)** | Backup nelze smazat ani přepsat po defined retention period (S3 Object Lock, Azure Blob Immutable) |
| **Air gap** | Backup je fyzicky oddělený od produkční sítě (offline disk, tape, cloud bez VPN) |
| **Isolated backup network** | Backup traffic jde přes dedikovanou síť bez přístupu z produkční VLAN |
| **Out-of-band access** | Backup management console není dostupná z produkční sítě |

---

## DR architektury

### Multi-AZ (Single region)

```
Region ┌────────────────────────────────────┐
       │  AZ-1              AZ-2            │
       │  ┌──────────┐     ┌──────────┐     │
       │  │  App      │     │  App      │     │
       │  └─────┬────┘     └─────┬────┘     │
       │        │                │          │
       │  ┌─────▼────────────────▼─────┐    │
       │  │  Load Balancer (cross-AZ)  │    │
       │  └─────────────┬──────────────┘    │
       │                │                   │
       │  ┌─────────────▼──────────────┐    │
       │  │  DB Primary (AZ-1)         │    │
       │  │  DB Standby (AZ-2)         │    │
       │  │  Synchronous replication   │    │
       │  └────────────────────────────┘    │
       └────────────────────────────────────┘
```

- RTO: minuty (automatický failover)
- RPO: 0 (sync replication)
- Ochrana: proti selhání AZ, nikoliv regionu

### Multi-Region

```
Region A (Primary)                    Region B (DR)
┌─────────────────────┐              ┌─────────────────────┐
│  ┌───────────────┐  │              │  ┌───────────────┐  │
│  │  App + DB     │  │              │  │  App + DB     │  │
│  │  Active       │──┼──Async───────┼─►│  Standby      │  │
│  └───────────────┘  │   replikace  │  └───────────────┘  │
│         │           │              │         │           │
│  ┌──────▼───────┐  │              │  ┌──────▼───────┐  │
│  │  DNS / GSLB  │  │              │  │  DNS / GSLB  │  │
│  └──────┬───────┘  │              │  └──────┬───────┘  │
└─────────┼──────────┘              └─────────┼──────────┘
          │                                    │
          └──────────── Traffic Manager ───────┘
```

| Varianta | RTO | RPO | Náklady | Failover |
|----------|-----|-----|---------|----------|
| **Active-Passive** | minuty–hodiny | sekundy | Střední | Manuální / auto |
| **Active-Active** | sekundy | < 1 s | Vysoké | Automatický (DNS) |
| **Pilot Light** | desítky minut | minuty | Nízké | Manuální škálování |
| **Warm Standby** | minuty | sekundy | Vysoké | Auto (zmenšená kopie) |
| **Backup & Restore** | hodiny | 24 h | Nízké | Manuální |

### On-prem → Cloud DR (Hybrid)

```
On-prem DC                              Cloud (DR)
┌─────────────────────┐              ┌─────────────────────┐
│  ┌───────────────┐  │              │  ┌───────────────┐  │
│  │  Aplikace     │  │              │  │  VM / Aplikace│  │
│  │  + DB         │  │              │  │  + DB replica │  │
│  └───────┬───────┘  │              │  └───────┬───────┘  │
│          │          │              │          │          │
│  ┌───────▼───────┐  │  site-to-site│  ┌───────▼───────┐  │
│  │  Backup proxy │──┼────VPN───────┼─►│  Backup store │  │
│  └───────────────┘  │              │  └───────────────┘  │
│                     │              │                     │
│  ┌───────────────┐  │              │  ┌───────────────┐  │
│  │  Tape / NAS   │  │              │  │  Veeam / Zerto│  │
│  └───────────────┘  │              │  └───────────────┘  │
└─────────────────────┘              └─────────────────────┘
```

- **RTO**: desítky minut (závisí na startup VM)
- **RPO**: minuty–hodiny (závisí na replikačním nástroji)
- **Nástroje**: Veeam, Zerto, Azure Site Recovery, AWS MGN, Commvault
- **Use case**: enterprise s on-prem DC, které potřebuje DR bez druhého DC

---

## DR testování

### Typy testů

| Typ | Popis | Frekvence | Riziko |
|-----|-------|-----------|--------|
| **Tabletop exercise** | Manuální procházení scénáře, žádný dopad na produkci | Měsíčně | Žádné |
| **Walkthrough** | Verifikace runbooku, kontrola že všichni ví co dělat | Kvartálně | Žádné |
| **Component test** | Test jedné komponenty (např. obnova jedné DB) | Měsíčně | Nízké |
| **Integrated test** | Test celého stacku v izolovaném prostředí | Kvartálně | Nízké |
| **Full failover test** | Produkční failover do DR site | Ročně | Vysoké |
| **Chaos experiment** | Cílené vnášení poruch do produkce | Průběžně | Střední |

### Runbook struktura

Každý DR scénář by měl mít runbook:

```yaml
scenario: "Region A failure"
triggers:
  - "CloudWatch alarm: Region A health check 5× timeout"
  - "PagerDuty incident P0"
decision_tree: |
  1. Ověřit: je Region A opravdu nedostupný? (check z 3 různých lokací)
  2. Rozhodnout: je RTO v ohrožení? Pokud zbývá < 30 % RTO → failover
  3. Failover: spustit playbook `dr-failover-region-b`
  4. Verifikace: smoke testy v Region B
  5. Komunikace: status page + stakeholders
rollback: |
  1. Po obnovení Region A → replikace změn z B zpět do A
  2. Repoint DNS na A
  3. Ověřit konzistenci dat
  4. Vypnout Region B (nebo ponechat jako hot standby)
contacts:
  primary: "on-call@example.com"
  escalation: "infra-lead@example.com"
  management: "vp-engineering@example.com"
```

---

## Best practices

- **Testuj obnovu, ne zálohu** — backup bez testované obnovy není backup
- **Automatizuj DR** — Terraform / Ansible pro spin-up DR prostředí, DNS failover
- **Dokumentuj runbooky** — každý scénář, kontakt, rozhodovací strom
- **Počítej se selháním** — design for failure, nečekej že všechno poběží
- **Nepodceňuj WRT** — obnova služby neznamená plný provoz (data warming, cache, connections)
- **Slaď RTO/RPO s businessem** — technické možnosti musí odpovídat obchodním požadavkům
- **Monitoruj SLI** — bez dat nelze ověřit SLO
- **DR není jen IT** — komunikace, PR, právní, regulace

---

## Související

- [CLOUD.md](CLOUD.md) — cloud DR strategie, AWS/Azure/GCP specific
- [DATACENTERS.md](DATACENTERS.md) — DC redundance, Tier klasifikace
- [MONITORING.md](MONITORING.md) — alerting, SLI/SLO/SLA
- [CICD.md](CICD.md) — deployment strategie, rollback
- [STORAGE.md](STORAGE.md) — backup storage, replication

## Zdroje

Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)

*Poslední revize: 2026-06-11*