336 lines
16 KiB
Markdown
336 lines
16 KiB
Markdown
# 🔄 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* |