Cloud allgemein

Data Platform Disaster Recovery: RPO, RTO und Runbooks, die wirklich funktionieren

Ein DR-Plan als PDF im Shared Drive ist kein DR-Plan. Wie du RPO/RTO pro Tier setzt, Object Storage und Kafka cross-region replizierst und Drills auswertbar machst.

Harbinger Team3. April 20265 Min. LesezeitAktualisiert 14.5.2026
  • disaster-recovery
  • data-platform
  • rpo-rto
  • multi-region
  • backup
  • resilience
Inhaltsverzeichnis16 Abschnitte

Die meisten DR-Pläne existieren als PDF im Shared Drive, das zuletzt während eines Audits geöffnet wurde. Wenn eine Region down geht und der On-Call ein Recovery ausführen soll, entdeckt er, dass der Runbook auf Systeme verweist, die vor acht Monaten umbenannt wurden, und einen Bastion-Host annimmt, den die Kostenoptimierung dekommissioniert hat.

Dieser Guide ist über DR für Datenplattformen, das funktioniert, wenn du es brauchst.

TL;DR

  • Klassifiziere Daten in Tiers, bevor du Recovery-Mechanismen baust.
  • Repliziere an jedem Layer: Storage, Streaming, Warehouse.
  • Runbooks sind ausführbare Skripte mit echten Commands, keine Prosa.
  • Quartalsweise Drills mit echtem Escalation-Path — sonst ist es kein DR-Plan.
  • DR-Health als kontinuierliches Monitoring, nicht nur Drill-Snapshot.

Failure-Mode-Analysis zuerst

Bevor du irgendeinen Recovery-Mechanismus designst, enumeriere Failure-Modi:

KomponenteFailure-ModeImpactDetection-Signal
Object Storage (S3/GCS)Regional OutageLake nicht verfügbarCloudWatch/Cloud-Monitoring
WarehouseCompute-FailureQuery-Outage (Daten ok)Health-Endpoint
Kafka-BrokerBroker-LossConsumer-Lag, Message-Loss-RisikoLag-Monitoring
Orchestrator (Airflow)Metadata-DB-FailureKeine neuen Pipeline-RunsHeartbeat
ETL-Compute (Spark/Databricks)Cluster-Provisioning-FailurePipeline-BacklogJob-Queue-Depth
Schema-RegistryUnavailabilityProducer/Consumer-Serialisierung failtRegistry-Health
Catalog / LineageOutageDiscovery-Verlust (kein Data-Loss)Catalog-Health

Nicht alle Failure-Modi brauchen DR. Manche (Warehouse-Compute, Orchestrator) sind Availability-Probleme, nicht Recovery — separater Playbook.

RPO und RTO pro Tier

Nicht einen RPO/RTO für die ganze Plattform — Tiers nach Business-Kritikalität:

Tier 1 — Kritisch         | RPO: 1h   | RTO: 2h   | z.B. Customer-Billing
Tier 2 — Wichtig          | RPO: 4h   | RTO: 8h   | z.B. Operational-Dashboards
Tier 3 — Standard         | RPO: 24h  | RTO: 24h  | z.B. Historic Analytics
Tier 4 — Archiv           | RPO: 7d   | RTO: 48h  | z.B. Compliance-Archive

Jedes Dataset im Catalog zu einem Tier zuordnen. Das treibt Replikations-Frequenz, Backup-Retention und Recovery-Priority.

Object Storage Replication

Cross-Region in AWS

resource "aws_s3_bucket" "data_lake_primary" {
  bucket = "company-data-lake-eu-central-1"
  versioning { enabled = true }
}

resource "aws_s3_bucket" "data_lake_replica" {
  provider = aws.eu_west_1
  bucket   = "company-data-lake-eu-west-1"
  versioning { enabled = true }
}

resource "aws_iam_role" "replication_role" {
  name = "s3-replication-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "s3.amazonaws.com" }
    }]
  })
}

resource "aws_s3_bucket_replication_configuration" "data_lake" {
  role   = aws_iam_role.replication_role.arn
  bucket = aws_s3_bucket.data_lake_primary.id

  rule {
    id     = "replicate-tier1-data"
    status = "Enabled"
    filter { prefix = "tier1/" }

    destination {
      bucket        = aws_s3_bucket.data_lake_replica.arn
      storage_class = "STANDARD"
      replication_time {
        status = "Enabled"
        time { minutes = 15 }
      }
      metrics {
        status = "Enabled"
        event_threshold { minutes = 15 }
      }
    }

    delete_marker_replication { status = "Enabled" }
  }
}

Point-in-Time-Recovery mit S3-Versioning

Versioning auf allen Tier-1- und Tier-2-Buckets aktivieren, Lifecycle-Rules für Version-Retention.

#!/bin/bash
BUCKET="company-data-lake-eu-central-1"
PREFIX="tier1/orders/2024/"
TARGET_TIME="2024-03-15T10:00:00Z"
RESTORE_BUCKET="company-data-lake-restore-eu-central-1"

aws s3api list-object-versions \
  --bucket $BUCKET \
  --prefix $PREFIX \
  --query "Versions[?LastModified<='${TARGET_TIME}']|[?IsLatest==\`true\`].[Key,VersionId]" \
  --output text | while read key version_id; do
    aws s3api copy-object \
      --copy-source "$BUCKET/$key?versionId=$version_id" \
      --bucket $RESTORE_BUCKET \
      --key "$key"
    echo "Restored: $key (version: $version_id)"
done

Kafka Disaster Recovery

Kafka ist die höchste Risiko-Komponente — Message-Loss während Broker-Outage ist ohne Replikation permanent.

MirrorMaker 2

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: mm2-dr-replication
  namespace: kafka
spec:
  version: 3.7.0
  replicas: 3
  connectCluster: dr-region

  clusters:
    - alias: primary
      bootstrapServers: kafka.primary-region.internal:9093
      tls:
        trustedCertificates:
          - secretName: primary-cluster-ca-cert
            certificate: ca.crt
      authentication:
        type: tls
        certificateAndKey:
          secretName: mm2-primary-user
          certificate: user.crt
          key: user.key

    - alias: dr-region
      bootstrapServers: kafka.dr-region.internal:9093

  mirrors:
    - sourceCluster: primary
      targetCluster: dr-region
      sourceConnector:
        tasksMax: 10
        config:
          replication.factor: 3
          offset-syncs.topic.replication.factor: 3
          replication.policy.class: org.apache.kafka.connect.mirror.IdentityReplicationPolicy
      checkpointConnector:
        config:
          checkpoints.topic.replication.factor: 3
          sync.group.offsets.enabled: "true"
          sync.group.offsets.interval.seconds: "60"
      topicsPattern: "tier1.*|tier2.*"

IdentityReplicationPolicy preserved Topic-Namen ohne Prefix — kritisch für Consumer-Group-Offset-Sync bei Failover.

Kafka-Failover-Runbook

#!/bin/bash
set -euo pipefail

echo "=== KAFKA FAILOVER RUNBOOK ==="
echo "Timestamp: $(date -u)"

# 1. MirrorMaker2 Offset-Sync prüfen
kubectl exec -n kafka deploy/kafka-toolbox -- \
  kafka-consumer-groups.sh \
    --bootstrap-server kafka.dr-region.internal:9092 \
    --group data-platform-consumer \
    --describe | grep -E "TOPIC|LAG"

read -p "Lag akzeptabel? (y/n): " lag_ok
[[ $lag_ok != "y" ]] && echo "ABORT: Lag zu hoch" && exit 1

# 2. Producer auf primary stoppen
curl -X PATCH https://config.internal/v1/features/kafka_producer_enabled \
  -d '{"region":"primary","value":false}'

# 3. In-Flight Messages replizieren lassen
sleep 60

# 4. Consumer-Offsets übersetzen
kubectl exec -n kafka deploy/kafka-toolbox -- \
  kafka-groups.sh \
    --bootstrap-server kafka.dr-region.internal:9092 \
    --reset-offsets \
    --group data-platform-consumer \
    --from-file /checkpoints/primary.data-platform-consumer.offsets \
    --execute

# 5. DNS updaten
vault kv put secret/kafka/bootstrap \
  servers="kafka.dr-region.internal:9093" \
  region="dr" \
  failover_time="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

echo "=== FAILOVER COMPLETE ==="

Warehouse Recovery

Bei BigQuery, Snowflake, Redshift ist Compute-Recovery typisch automatisch. Data-Recovery-Concerns:

  1. Versehentliches DROP TABLE → Time Travel
  2. Korruption durch bad ETL → Snapshots + Time Travel
  3. Regional-Outage → Cross-Region-Backup-Exports

BigQuery Snapshot-Export

#!/bin/bash
TABLES=("orders" "customers" "products" "transactions")
PROJECT="company-prod"
DATASET="analytics"
DR_BUCKET="gs://company-bq-dr-europe-west4"
DATE=$(date +%Y/%m/%d)

for TABLE in "${TABLES[@]}"; do
  bq extract \
    --destination_format PARQUET \
    --compression SNAPPY \
    "${PROJECT}:${DATASET}.${TABLE}" \
    "${DR_BUCKET}/${TABLE}/${DATE}/${TABLE}_*.parquet"
  echo "Exported ${TABLE} to ${DR_BUCKET}/${TABLE}/${DATE}/"
done

DR-Plan testen

Ein nicht getesteter DR-Plan ist kein DR-Plan. Quartalsweise Drills mit echtem Escalation-Path:

Test-TypFrequenzScopeErfolgskriterium
TabletopMonatlichTeam liest RunbookAlle Schritte verstanden, Owner pro Schritt
Component-RestoreQuartalsweiseNon-kritisches Dataset restorenRTO erfüllt, Daten verifiziert
Regional Failover DrillHalbjährlichFull DR-Region aktivierenRTO erfüllt, Consumer geswitcht
Chaos-InjectionQuartalsweiseFailure in StagingSelf-Healing oder Alert in SLA

Jeden Drill dokumentieren. Ein DR-Plan, der wiederholt seinen RTO trifft, hat Stakeholder-Vertrauen verdient.

DR-Dashboard

Operationale Visibility kontinuierlich, nicht nur in Drills:

  • Replikations-Lag (S3, Kafka, DB)
  • Last-Successful-Backup-Timestamp pro Dataset
  • Time-Travel-Window verbleibend
  • Cross-Region-Connectivity-Health

DACH-Kontext

eu-central-1 (Frankfurt) ↔ eu-west-1 (Irland) ist Standard. DSGVO-konform bleiben beide Regionen in der EU. Für strengere Datenresidenz-Anforderungen (z.B. öffentliche Verwaltung): eu-central-1 ↔ eu-central-2 (Zürich). KMS-Multi-Region-Keys nicht vergessen, sonst kannst du in der DR-Region nicht entschlüsseln.

Häufige Fehler

  1. DR-Plan als PDF. Runbooks müssen ausführbare Skripte sein, version-controlled.
  2. Backups mit Prod-Keys verschlüsseln. Bei Key-Kompromiss sind beide weg.
  3. KMS-Keys nicht cross-region. Du kannst Daten in DR nicht entschlüsseln.
  4. Replikations-Health nicht monitoren. Replikation kann silent stehen bleiben.
  5. Drill mit "trockenem Lauf". Echte Escalation-Wege üben, nicht nur Skripte ausführen.

FAQ

Wie oft DR testen? Component-Restore quartalsweise, Full Regional Failover halbjährlich.

Wie viel kostet DR typisch? 20–40 % Aufschlag auf Storage + Egress, plus Engineering-Aufwand für Runbooks.

Reicht S3-Cross-Region-Replication für DSGVO? Solange Replica auch in EU bleibt, ja.

Was, wenn die DR-Region selbst ausfällt? Tier-1-Daten in dritte Region replizieren (3-2-1-Backup-Regel).

Stand: 14. Mai 2026.

H

Geschrieben von

Harbinger Team

Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastruktur­kritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.

Hat dir das geholfen?

Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.

Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.