Disaster Recovery as Code (DRaC) ist ein Ansatz, der die gesamte Disaster-Recovery-Strategie in versionskontrollierten Code überführt. Keine manuellen Runbooks, keine veralteten Wiki-Seiten — alles ist automatisiert, testbar und reproduzierbar.
Warum traditionelles Disaster Recovery scheitert¶
Die meisten tschechischen Unternehmen haben einen DR-Plan. Auf Papier. In SharePoint. Zuletzt vor zwei Jahren aktualisiert. Und niemand hat ihn jemals End-to-End getestet.
Statistiken sprechen eine klare Sprache: Laut einer Gartner-Umfrage von 2025 scheitern 76 % der DR-Tests beim ersten Versuch. Warum? Die Dokumentation entspricht nicht der Realität. Die Infrastruktur hat sich seit dem letzten Review verändert. Die Personen, die den Plan geschrieben haben, sind nicht mehr im Unternehmen. Passwörter sind abgelaufen. Zertifikate sind ungültig.
Traditionelles DR leidet unter einem fundamentalen Problem: Es trennt den Infrastruktur-Code vom Recovery-Code. Ihr Terraform verwaltet die Produktion, aber die DR-Prozeduren leben in Confluence. Diese beiden Welten driften nach und nach auseinander — und wenn eine Katastrophe eintritt, entdecken Sie das im denkbar schlechtesten Moment.
Die Kosten von Ausfallzeiten 2026¶
Für ein mittelständisches tschechisches Unternehmen mit Online-Betrieb kostet eine Stunde Ausfallzeit 150.000–500.000 CZK. Für eine Bank oder E-Commerce-Plattform deutlich mehr. Und das berücksichtigt nicht den Reputationsschaden, regulatorische Strafen (NIS2, DORA) oder den Verlust des Kundenvertrauens.
Die NIS2-Richtlinie, die seit Oktober 2024 gilt, erfordert explizit einen getesteten Wiederherstellungsplan und die Fähigkeit, dessen Funktionalität nachzuweisen. Ein Plan auf Papier reicht nicht mehr aus.
Was ist Disaster Recovery as Code¶
DRaC wendet Infrastructure-as-Code-Prinzipien auf den gesamten Disaster-Recovery-Lebenszyklus an:
- Deklarative Definition — DR-Strategie im Code beschrieben (Terraform, Pulumi, Crossplane)
- Versionierung — jede Änderung am DR-Plan ist ein Commit in Git mit Review-Prozess
- Automatisierte Tests — DR-Tests laufen regelmäßig in der CI/CD-Pipeline
- Idempotenz — mehrfaches Ausführen des DR-Prozesses führt zum gleichen Ergebnis
- Documentation as Code — Runbooks werden aus dem Code generiert, immer aktuell
DRaC-Architektur¶
Das gesamte System besteht aus mehreren Schichten:
Schicht 1: Infrastruktur-Definition Terraform- oder Pulumi-Module, die sowohl die Produktions- als auch die DR-Infrastruktur definieren. Der Schlüssel ist, dass beide Umgebungen dieselben Module teilen — sie unterscheiden sich nur in den Parametern (Region, Dimensionierung, Aktivierung).
Schicht 2: Datenreplikation Asynchrone oder synchrone Datenreplikation zwischen primärem und DR-Standort. Für Datenbanken: native Replikation (PostgreSQL Streaming, MySQL Group Replication). Für Storage: Cross-Region-Replikation (Azure GRS, AWS S3 CRR). Für Kubernetes: Velero oder Kasten K10.
Schicht 3: Failover-Orchestrierung Automatisierter Failover-Prozess — DNS-Umschaltung, Traffic-Routing, Datenbank-Promotion, Anwendungs-Startsequenz. Implementiert als Pipeline (GitHub Actions, GitLab CI, Azure DevOps).
Schicht 4: Validierung & Monitoring Automatisierte Smoke-Tests nach Failover. Health Checks. Alerting. RPO/RTO-Metriken.
Praktische Implementierung mit Terraform¶
Dual-Region-Setup auf Azure¶
Die Grundlage ist ein Terraform-Workspace mit zwei Umgebungen. Die Produktion läuft in West Europe, der DR-Standby in North Europe:
# Disaster Recovery as Code — Automatisierte Wiederherstellung nach Cloud-Ausfällen
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
}
}
Die DR-Umgebung läuft auf minimalen Ressourcen (Warm Standby). Bei Aktivierung skaliert sie automatisch auf Produktionsniveau. Einsparungen: 60–80 % der Kosten im Vergleich zu Hot Standby, mit Failover unter 15 Minuten.
Datenbank-Failover¶
Für Azure SQL Database oder 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 in der sekundären Region. Beim Failover wird sie zum primären Server promoted. RPO hängt vom Replikations-Lag ab — typischerweise unter 5 Sekunden für asynchrone Replikation innerhalb des Azure-Backbones.
Runbooks als Code¶
Ein traditionelles Runbook ist ein Word-Dokument mit Schritten wie „Melden Sie sich auf Server X an und führen Sie Befehl Y aus.” Ein DRaC-Runbook ist ausführbarer Code:
# .github/workflows/dr-failover.yml
name: DR Failover
on:
workflow_dispatch:
inputs:
reason:
description: 'Failover reason'
required: true
confirm:
description: 'Confirm: FAILOVER'
required: true
jobs:
pre-check:
runs-on: ubuntu-latest
steps:
- name: Validate confirmation
run: |
if [ "${{ inputs.confirm }}" != "FAILOVER" ]; then
echo "Failover not confirmed. Terminating."
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 is not 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
Jeder Schritt ist automatisiert. Menschliches Eingreifen ist nur für die Bestätigung des Failovers erforderlich — der Rest läuft automatisch.
RPO und RTO — Wie man sie realistisch erreicht¶
Recovery Point Objective (RPO)¶
RPO definiert, wie viele Daten Sie sich leisten können zu verlieren. Es hängt von der Replikationsstrategie ab:
| Strategie | RPO | Kosten | Hinweis |
|---|---|---|---|
| Synchrone Replikation | ~0 | Hoch | Latenz-Penalty, geeignet für Finanzsektor |
| Asynchrone Replikation | 1–30s | Mittel | Sweet Spot für die meisten Anwendungen |
| Periodische Snapshots | 1–24h | Niedrig | Akzeptabel für nicht-kritische Daten |
| Backup & Restore | 24h+ | Am niedrigsten | Nur für Archivdaten |
Empfehlung für tschechische Unternehmen: Asynchrone Replikation mit RPO unter 30 Sekunden deckt 90 % der Use Cases ab. Synchrone Replikation nur für Finanztransaktionen und regulatorisch sensible Daten.
Recovery Time Objective (RTO)¶
RTO definiert, wie schnell Sie wieder online sein müssen:
- Hot Standby (RTO < 5 Min.): DR-Umgebung läuft auf voller Kapazität, Sie schalten nur den Traffic um. Teuer — Sie zahlen für 2x Infrastruktur.
- Warm Standby (RTO 5–30 Min.): DR-Umgebung läuft auf minimalen Ressourcen, skaliert beim Failover hoch. Bestes Preis-Leistungs-Verhältnis.
- Pilot Light (RTO 30–120 Min.): Nur die Datenschicht wird repliziert, Compute wird beim Failover provisioniert.
- Cold Standby (RTO 2–24h): Nur Backups. Infrastruktur wird von Grund auf aufgebaut.
Automatisierte DR-Tests¶
Ein DR-Plan, der nicht getestet wird, ist kein DR-Plan. DRaC ermöglicht automatisierte Tests ohne Auswirkungen auf die Produktion:
Chaos Engineering für DR¶
# dr-test-weekly.yml
name: Weekly DR Test
on:
schedule:
- cron: '0 3 * * 0' # Jeden Sonntag um 3:00 Uhr
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
Jede Woche wird der gesamte DR-Prozess automatisch getestet. Ohne menschliches Eingreifen. Ergebnisse gehen in ein Dashboard, und bei Fehlern wird ein Alert gesendet.
Kosten — Was kostet DRaC¶
Typische Berechnung für ein mittelständisches tschechisches Unternehmen (50 Mitarbeiter, Online-Produkt):
| Posten | Monatliche Kosten | Hinweis |
|---|---|---|
| Warm-Standby-Infra | 15.000–30.000 CZK | 20–30 % der Produktionskosten |
| Cross-Region-Replikation | 2.000–5.000 CZK | Datentransfer + Storage |
| CI/CD für DR-Tests | 500–2.000 CZK | GitHub Actions Minuten |
| Monitoring & Alerting | 3.000–8.000 CZK | Datadog/Grafana Cloud |
| Gesamt | 20.500–45.000 CZK |
Vergleichen Sie mit den Kosten eines eintägigen Ausfalls (150.000–500.000 CZK). DR zahlt sich beim ersten Vorfall aus.
Regulatorischer Kontext — NIS2 und DORA¶
NIS2 (Netz- und Informationssicherheitsrichtlinie 2)¶
Seit Oktober 2024 für alle wesentlichen und wichtigen Einrichtungen in der EU gültig. Erfordert:
- Business Continuity Plan
- Regelmäßige Tests der DR-Prozeduren
- Vorfallmeldung innerhalb von 24 Stunden (Erstwarnung) und 72 Stunden (vollständiger Bericht)
- Nachweisbare Wiederherstellungsfähigkeit
DRaC erfüllt NIS2-Anforderungen auf natürliche Weise — automatisierte Tests erzeugen auditierbare Aufzeichnungen, Code in Git liefert Änderungshistorie, und Pipeline-Logs belegen regelmäßige Tests.
DORA (Digital Operational Resilience Act)¶
Für den Finanzsektor. Seit Januar 2025 erfordert es:
- Threat-Led Penetration Testing (TLPT) einschließlich DR-Szenarien
- ICT-Risikomanagement-Framework mit getestetem DR
- Meldung schwerwiegender Vorfälle innerhalb von 4 Stunden
Häufige Fehler und wie man sie vermeidet¶
1. „Wir testen DR einmal im Jahr” Ein jährlicher Test ist ein Audit, keine DR-Strategie. Mit DRaC testen Sie jede Woche automatisch. Kosten: minimal. Sicherheit: maximal.
2. „Wir haben Geo-Replikation, wir sind sicher” Geo-Replikation schützt vor Hardware-Ausfällen. Sie schützt nicht vor: Ransomware (repliziert verschlüsselte Daten mit), Konfigurationsfehlern (repliziert fehlerhafte Konfiguration mit), logischer Datenkorruption (repliziert korrupte Daten mit). Sie brauchen Point-in-Time-Recovery neben der Replikation.
3. „DR ist Sache der IT-Abteilung” DR liegt in der Verantwortung des gesamten Teams. Entwickler müssen Anwendungen schreiben, die Graceful Failover unterstützen — Connection Retry, Circuit Breaker, idempotente Operationen. DevOps richtet die Infrastruktur ein. Business definiert RPO/RTO.
4. „Wir stellen aus dem Backup wieder her” Ein Backup ohne verifizierten Wiederherstellungsprozess sind nur Daten auf einer Festplatte. DRaC umfasst automatische Wiederherstellungstests — jedes Backup wird validiert, indem tatsächlich eine Testumgebung daraus wiederhergestellt wird.
5. „DNS-Failover reicht aus” DNS-Propagation dauert Minuten bis Stunden (TTL). Für RTO unter 5 Minuten brauchen Sie Anycast-Routing oder einen Load Balancer auf globaler Ebene (Azure Front Door, AWS Global Accelerator, Cloudflare).
Fazit¶
Disaster Recovery as Code ist kein Luxus — es ist eine Notwendigkeit für jedes Unternehmen, das von digitalen Diensten abhängt. Und im Jahr 2026, in der Ära von NIS2 und DORA, ist es eine regulatorische Anforderung.
Tschechische Unternehmen, die DRaC heute implementieren, haben einen messbaren Wettbewerbsvorteil: geringeres Risiko, schnellere Wiederherstellung, einfachere Compliance und ruhigeren Schlaf für das gesamte Team.
Brauchen Sie Hilfe bei der Implementierung? CORE SYSTEMS bietet ein DR-Assessment — eine 2-wöchige Analyse Ihrer Infrastruktur mit einem konkreten Implementierungsplan. Kontaktieren Sie uns für eine unverbindliche Beratung.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns