Files

Stanislav Hubacek b53714113c new files

2026-06-16 15:47:45 +02:00

16 KiB

Raw Blame History

🔄 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

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:

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 DR strategie, AWS/Azure/GCP specific
DATACENTERS.md — DC redundance, Tier klasifikace
MONITORING.md — alerting, SLI/SLO/SLA
CICD.md — deployment strategie, rollback
STORAGE.md — backup storage, replication

Zdroje

Odkazy, knihy a standardy: sources/infrastructure/sources.md

Poslední revize: 2026-06-11

16 KiB Raw Blame History Unescape Escape

🔄 Disaster Recovery a Business Continuity

Terminologie

Vztah RTO, RPO, MTD, WRT

Výpočet uptimu

Tabulka devítek

Výpočet

Kalkulačka

Fallacies výpočtu

DR scénáře

Klasifikace

Detail scénářů

Site / Region failure

Data corruption / human error

Ransomware / cyber attack

Prevence — strategie

Backup strategie

Zálohovací metody

Imunabilita backupů

DR architektury

Multi-AZ (Single region)

Multi-Region

On-prem → Cloud DR (Hybrid)

DR testování

Typy testů

Runbook struktura

Best practices

Související

Zdroje

16 KiB

Raw Blame History