Disaster Recovery as Code — automatizovaná obnova po havárii v cloudu

Disaster Recovery as Code (DRaC) je přístup, který přenáší celou strategii obnovy po havárii do verzovaného kódu. Žádné ruční runbooky, žádné zastaralé Wiki stránky — vše je automatizované, testovatelné a reprodukovatelné.

Proč tradiční Disaster Recovery selhává¶

Většina českých firem má DR plán. Na papíře. V SharePointu. Naposledy aktualizovaný před dvěma lety. A nikdo ho nikdy netestoval end-to-end.

Statistiky mluví jasně: podle průzkumu Gartner z roku 2025 selže 76 % DR testů při prvním pokusu. Důvod? Dokumentace neodpovídá realitě. Infrastruktura se od posledního review změnila. Lidé, kteří plán psali, už ve firmě nejsou. Hesla expirovala. Certifikáty nejsou platné.

Tradiční DR trpí fundamentálním problémem: odděluje kód infrastruktury od kódu obnovy. Váš Terraform spravuje produkci, ale DR procedury žijí v Confluence. Tyto dva světy se postupně rozchází — a když přijde havárie, zjistíte to v tom nejhorším možném okamžiku.

Cena výpadku v roce 2026¶

Pro střední českou firmu s online provozem stojí hodina výpadku 150 000–500 000 Kč. Pro banku nebo e-commerce platformu řádově více. A to nepočítáme reputační škody, regulatorní pokuty (NIS2, DORA) nebo ztrátu zákaznické důvěry.

NIS2 direktiva, účinná od října 2024, explicitně vyžaduje testovaný plán obnovy a schopnost demonstrovat jeho funkčnost. Papírový plán už nestačí.

Co je Disaster Recovery as Code¶

DRaC aplikuje principy Infrastructure as Code na celý lifecycle disaster recovery:

1. Deklarativní definice — DR strategie popsaná v kódu (Terraform, Pulumi, Crossplane)
2. Verzování — každá změna v DR plánu je commit v Gitu s review procesem
3. Automatické testování — DR testy běží pravidelně v CI/CD pipeline
4. Idempotence — spuštění DR procesu vícekrát vede ke stejnému výsledku
5. Dokumentace jako kód — runbooky generované z kódu, vždy aktuální

Architektura DRaC¶

Celý systém se skládá z několika vrstev:

Vrstva 1: Infrastructure Definition Terraform nebo Pulumi moduly definující jak produkční, tak DR infrastrukturu. Klíčové je, že obě prostředí sdílejí stejné moduly — liší se pouze parametry (region, sizing, aktivace).

Vrstva 2: Data Replication Asynchronní nebo synchronní replikace dat mezi primárním a DR site. Pro databáze: native replikace (PostgreSQL streaming, MySQL Group Replication). Pro storage: cross-region replication (Azure GRS, AWS S3 CRR). Pro Kubernetes: Velero nebo Kasten K10.

Vrstva 3: Failover Orchestration Automatizovaný failover proces — DNS přepnutí, traffic routing, database promotion, application startup sequence. Implementovaný jako pipeline (GitHub Actions, GitLab CI, Azure DevOps).

Vrstva 4: Validation & Monitoring Automatické smoke testy po failoveru. Health checky. Alerting. Metriky RPO/RTO.

Praktická implementace s Terraform¶

Dual-region setup na Azure¶

Základem je Terraform workspace s dvěma prostředími. Produkce běží v West Europe, DR standby v North Europe:

# modules/app-stack/main.tf
variable "is_dr_active" {
  type    = bool
  default = false
}

variable "region" {
  type = string
}

resource "azurerm_resource_group" "main" {
  name     = "rg-app-${var.region}"
  location = var.region
}

resource "azurerm_app_service_plan" "main" {
  name                = "asp-${var.region}"
  location            = var.region
  resource_group_name = azurerm_resource_group.main.name

  sku {
    tier     = var.is_dr_active ? "Standard" : "Basic"
    size     = var.is_dr_active ? "S2" : "B1"
    capacity = var.is_dr_active ? 3 : 1
  }
}

DR prostředí běží na minimálních zdrojích (warm standby). Při aktivaci se automaticky škáluje na produkční úroveň. Úspora: 60–80 % nákladů oproti hot standby, s failoverem pod 15 minut.

Database failover¶

Pro Azure SQL Database nebo PostgreSQL Flexible Server:

resource "azurerm_postgresql_flexible_server" "primary" {
  name                = "psql-primary"
  location            = "westeurope"
  sku_name            = "GP_Standard_D4s_v3"

  high_availability {
    mode                      = "ZoneRedundant"
    standby_availability_zone = "2"
  }
}

resource "azurerm_postgresql_flexible_server" "replica" {
  name                          = "psql-replica"
  location                      = "northeurope"
  create_mode                   = "Replica"
  source_server_id              = azurerm_postgresql_flexible_server.primary.id
  sku_name                      = "GP_Standard_D2s_v3"
}

Read replica v sekundárním regionu. Při failoveru se promuje na primární server. RPO závisí na replication lag — typicky pod 5 sekund pro asynchronní replikaci v rámci Azure backbone.

Runbooky jako kód¶

Tradiční runbook je Word dokument s kroky typu „Přihlašte se na server X a spusťte příkaz Y”. DRaC runbook je executable kód:

# .github/workflows/dr-failover.yml
name: DR Failover
on:
  workflow_dispatch:
    inputs:
      reason:
        description: 'Důvod failoveru'
        required: true
      confirm:
        description: 'Potvrďte: FAILOVER'
        required: true

jobs:
  pre-check:
    runs-on: ubuntu-latest
    steps:
      - name: Validate confirmation
        run: |
          if [ "${{ inputs.confirm }}" != "FAILOVER" ]; then
            echo "Failover nepotvrzen. Ukončuji."
            exit 1
          fi

      - name: Check DR site health
        run: |
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://dr.app.example.com/health)
          if [ "$STATUS" != "200" ]; then
            echo "DR site není healthy. Status: $STATUS"
            exit 1
          fi

      - name: Snapshot current state
        run: terraform -chdir=infra/production output -json > /tmp/pre-failover-state.json

  failover:
    needs: pre-check
    runs-on: ubuntu-latest
    steps:
      - name: Promote DR database
        run: |
          az postgres flexible-server replica stop-replication \
            --resource-group rg-app-northeurope \
            --name psql-replica

      - name: Scale DR infrastructure
        run: |
          cd infra/dr
          terraform apply -var="is_dr_active=true" -auto-approve

      - name: Update DNS
        run: |
          az network dns record-set a update \
            --resource-group rg-dns \
            --zone-name app.example.com \
            --name "@" \
            --set "ARecords[0].ipv4Address=$DR_IP"

      - name: Smoke tests
        run: |
          sleep 60  # DNS propagation
          ./scripts/smoke-tests.sh https://app.example.com

      - name: Notify team
        run: |
          curl -X POST "$SLACK_WEBHOOK" \
            -d '{"text":"🚨 DR Failover completed. Reason: ${{ inputs.reason }}"}'

  post-failover:
    needs: failover
    runs-on: ubuntu-latest
    steps:
      - name: Validate RPO/RTO
        run: |
          START_TIME=${{ needs.pre-check.outputs.start_time }}
          END_TIME=$(date +%s)
          RTO=$((END_TIME - START_TIME))
          echo "RTO: ${RTO}s"
          if [ $RTO -gt 900 ]; then
            echo "⚠️ RTO exceeded 15min target"
          fi

Každý krok je automatizovaný. Lidský zásah je potřeba pouze pro potvrzení failoveru — zbytek běží sám.

RPO a RTO — jak je reálně dosáhnout¶

Recovery Point Objective (RPO)¶

RPO definuje, kolik dat si můžete dovolit ztratit. Závisí na replikační strategii:

Strategie	RPO	Náklady	Poznámka
Synchronní replikace	~0	Vysoké	Latence penalizace, vhodné pro finance
Asynchronní replikace	1–30s	Střední	Sweet spot pro většinu aplikací
Periodické snapshoty	1–24h	Nízké	Přijatelné pro non-critical data
Backup & Restore	24h+	Nejnižší	Pouze pro archivní data

Doporučení pro české firmy: Asynchronní replikace s RPO pod 30 sekund pokrývá 90 % use cases. Synchronní replikace jen pro finanční transakce a regulatorně citlivá data.

Recovery Time Objective (RTO)¶

RTO definuje, jak rychle musíte být zpět online:

• Hot standby (RTO < 5 min): DR prostředí běží v plném rozsahu, jen přepnete traffic. Nákladné — platíte 2× infrastrukturu.
• Warm standby (RTO 5–30 min): DR prostředí běží na minimálních zdrojích, při failoveru se škáluje. Nejlepší poměr cena/výkon.
• Pilot light (RTO 30–120 min): Pouze datová vrstva replikovaná, compute se provisonuje při failoveru.
• Cold standby (RTO 2–24h): Pouze backupy. Infrastructure se staví from scratch.

Automatické DR testy¶

DR plán, který se netestuje, není DR plán. DRaC umožňuje automatické testování bez dopadu na produkci:

Chaos Engineering pro DR¶

# dr-test-weekly.yml
name: Weekly DR Test
on:
  schedule:
    - cron: '0 3 * * 0'  # Každou neděli v 3:00

jobs:
  dr-test:
    runs-on: ubuntu-latest
    steps:
      - name: Provision test environment
        run: |
          cd infra/dr-test
          terraform apply -auto-approve

      - name: Restore from latest backup
        run: |
          LATEST_BACKUP=$(az backup item show --query "properties.lastRecoveryPoint" -o tsv)
          az backup restore --restore-mode AlternateLocation \
            --target-resource-group rg-dr-test \
            --recovery-point $LATEST_BACKUP

      - name: Run application tests
        run: ./scripts/full-integration-tests.sh https://dr-test.internal

      - name: Validate data integrity
        run: |
          PROD_COUNT=$(psql $PROD_DB -c "SELECT count(*) FROM orders" -t)
          DR_COUNT=$(psql $DR_DB -c "SELECT count(*) FROM orders" -t)
          DIFF=$((PROD_COUNT - DR_COUNT))
          echo "Data difference: $DIFF records (RPO indicator)"

      - name: Cleanup
        if: always()
        run: terraform -chdir=infra/dr-test destroy -auto-approve

      - name: Report
        run: |
          echo "DR Test Results:" >> $GITHUB_STEP_SUMMARY
          echo "- Restore time: ${RESTORE_TIME}s" >> $GITHUB_STEP_SUMMARY
          echo "- Data integrity: ${DATA_DIFF} records delta" >> $GITHUB_STEP_SUMMARY
          echo "- Integration tests: ${TEST_RESULT}" >> $GITHUB_STEP_SUMMARY

Každý týden se automaticky otestuje celý DR proces. Bez lidského zásahu. Výsledky jdou do dashboardu a při selhání se pošle alert.

Multi-cloud DR strategie¶

Pro firmy s regulatorními požadavky (banky, veřejná správa) může být nutný multi-cloud DR — primární provoz na Azure, DR na AWS nebo naopak:

Crossplane pro multi-cloud orchestraci¶

Crossplane umožňuje definovat infrastrukturu cloud-agnosticky:

apiVersion: compute.crossplane.io/v1alpha1
kind: Workload
metadata:
  name: app-dr
spec:
  primary:
    provider: azure
    region: westeurope
    resources:
      compute: 4vCPU/16GB
      storage: 500GB-SSD
  failover:
    provider: aws
    region: eu-central-1
    resources:
      compute: 4vCPU/16GB
      storage: 500GB-SSD
    trigger:
      healthCheck:
        endpoint: https://app.example.com/health
        interval: 30s
        threshold: 3

Výhoda: Vendor lock-in ochrana. Pokud Azure má regionální výpadek (stalo se v lednu 2023), AWS DR site převezme provoz.

Nevýhoda: Komplexita. Musíte udržovat kompatibilitu aplikace s oběma cloudy. Doporučujeme pouze pro Tier 0 služby (core banking, kritická infrastruktura).

Kubernetes-native DR s Velero¶

Pro firmy běžící na Kubernetes je Velero de facto standard pro backup a DR:

# Instalace Velero s Azure provider
velero install \
  --provider azure \
  --plugins velero/velero-plugin-for-microsoft-azure:v1.9.0 \
  --bucket velero-backups \
  --backup-location-config resourceGroup=rg-velero,storageAccount=stvelero \
  --snapshot-location-config resourceGroup=rg-velero

# Pravidelný backup
velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces production \
  --ttl 720h

# DR restore do jiného clusteru
velero restore create --from-backup daily-backup-20260216 \
  --namespace-mappings production:dr-production

Velero zálohuje: - Kubernetes resources (Deployments, Services, ConfigMaps, Secrets) - Persistent Volumes (Azure Disk snapshots, EBS snapshots) - Custom Resources (CRDs, operátory)

Restore do DR clusteru trvá typicky 5–15 minut v závislosti na velikosti PV.

Náklady — kolik stojí DRaC¶

Typická kalkulace pro střední českou firmu (50 zaměstnanců, online produkt):

Položka	Měsíční náklady	Poznámka
Warm standby infra	15 000–30 000 Kč	20–30 % produkčních nákladů
Cross-region replikace	2 000–5 000 Kč	Data transfer + storage
CI/CD pro DR testy	500–2 000 Kč	GitHub Actions minutes
Monitoring & alerting	3 000–8 000 Kč	Datadog/Grafana Cloud
Celkem	20 500–45 000 Kč

Srovnejte s cenou jednodenního výpadku (150 000–500 000 Kč). DR se zaplatí při prvním incidentu.

Optimalizace nákladů¶

• Spot instances pro DR compute — warm standby nemusí být on-demand
• Lifecycle policies — starší snapshoty automaticky do cold storage
• Shared DR infrastructure — více aplikací sdílí jeden DR cluster
• Scale-to-zero — DR compute se provisionuje jen při testu nebo failoveru

Regulatorní kontext — NIS2 a DORA¶

NIS2 (Network and Information Security Directive 2)¶

Od října 2024 platí pro všechny základní a důležité subjekty v EU. Požaduje:

• Plán kontinuity provozu (Business Continuity Plan)
• Pravidelné testování DR procedur
• Notifikaci incidentu do 24 hodin (první varování) a 72 hodin (úplný report)
• Demonstrovatelnou schopnost obnovy

DRaC pokrývá požadavky NIS2 přirozeně — automatické testy generují auditovatelné záznamy, kód v Gitu poskytuje historii změn, a pipeline logy dokazují pravidelné testování.

DORA (Digital Operational Resilience Act)¶

Pro finanční sektor. Od ledna 2025 vyžaduje:

• Threat-Led Penetration Testing (TLPT) včetně DR scénářů
• ICT Risk Management framework s testovaným DR
• Reporting major incidents do 4 hodin

Časté chyby a jak se jim vyhnout¶

1. „DR testujeme jednou ročně” Roční test je audit, ne DR strategie. S DRaC testujete každý týden automaticky. Náklady: minimální. Jistota: maximální.

2. „Máme georeplikaci, jsme v bezpečí” Georeplikace chrání proti hardware failure. Nechrání proti: ransomware (replikuje i šifrovaná data), konfigurační chybě (replikuje i broken config), logickému poškození dat (replikuje i corrupted data). Potřebujete point-in-time recovery vedle replikace.

3. „DR je zodpovědnost IT operations” DR je zodpovědnost celého týmu. Vývojáři musí psát aplikace, které podporují graceful failover — connection retry, circuit breaker, idempotentní operace. DevOps nastavuje infrastrukturu. Byznys definuje RPO/RTO.

4. „Obnovíme z backupu” Backup bez ověřeného restore procesu je jen data na disku. DRaC zahrnuje automatický restore test — každý backup se validuje tím, že se z něj reálně obnoví testovací prostředí.

5. „DNS failover stačí” DNS propagace trvá minuty až hodiny (TTL). Pro RTO pod 5 minut potřebujete anycast routing nebo load balancer na globální úrovni (Azure Front Door, AWS Global Accelerator, Cloudflare).

Implementační plán — 12 týdnů¶

Týden 1–2: Assessment¶

• Inventarizace aplikací a datových toků
• Klasifikace podle kritičnosti (Tier 0/1/2/3)
• Definice RPO/RTO per tier
• Gap analýza stávajícího DR

Týden 3–4: Architektura¶

• Výběr DR strategie per tier
• Design Terraform modulů
• Replikační strategie pro databáze a storage
• Cost estimation

Týden 5–8: Implementace¶

• Terraform moduly pro DR infrastrukturu
• Replikace setup a validace
• Failover pipeline (GitHub Actions / Azure DevOps)
• Smoke testy a health checky

Týden 9–10: Testování¶

• Plný DR test (failover + failback)
• Performance testy DR prostředí
• Validace RPO/RTO proti cílům
• Security review DR přístupů

Týden 11–12: Operacionalizace¶

• Automatický týdenní test v CI/CD
• Dokumentace generovaná z kódu
• On-call runbook integrace (PagerDuty, OpsGenie)
• Training pro tým

Závěr¶

Disaster Recovery as Code není luxus — je to nutnost pro každou firmu, která závisí na digitálních službách. A v roce 2026, v éře NIS2 a DORA, je to regulatorní požadavek.

Klíčové principy:

• Vše v kódu — žádné manuální runbooky, žádné Wiki stránky
• Testujte pravidelně — automaticky, každý týden, bez výjimek
• Warm standby je sweet spot — 20–30 % nákladů, RTO pod 15 minut
• RPO a RTO definuje byznys, ne IT — začněte konverzací o hodnotě
• DR je continuous process — ne jednorázový projekt

České firmy, které implementují DRaC dnes, budou mít měřitelnou konkurenční výhodu: nižší riziko, rychlejší obnovu, jednodušší compliance a klidnější spánek pro celý tým.

Potřebujete pomoc s implementací? CORE SYSTEMS nabízí DR Assessment — 2týdenní analýza vaší infrastruktury s konkrétním implementačním plánem. Kontaktujte nás pro nezávaznou konzultaci.