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:
| Komponente | Failure-Mode | Impact | Detection-Signal |
|---|---|---|---|
| Object Storage (S3/GCS) | Regional Outage | Lake nicht verfügbar | CloudWatch/Cloud-Monitoring |
| Warehouse | Compute-Failure | Query-Outage (Daten ok) | Health-Endpoint |
| Kafka-Broker | Broker-Loss | Consumer-Lag, Message-Loss-Risiko | Lag-Monitoring |
| Orchestrator (Airflow) | Metadata-DB-Failure | Keine neuen Pipeline-Runs | Heartbeat |
| ETL-Compute (Spark/Databricks) | Cluster-Provisioning-Failure | Pipeline-Backlog | Job-Queue-Depth |
| Schema-Registry | Unavailability | Producer/Consumer-Serialisierung failt | Registry-Health |
| Catalog / Lineage | Outage | Discovery-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:
- Versehentliches DROP TABLE → Time Travel
- Korruption durch bad ETL → Snapshots + Time Travel
- 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-Typ | Frequenz | Scope | Erfolgskriterium |
|---|---|---|---|
| Tabletop | Monatlich | Team liest Runbook | Alle Schritte verstanden, Owner pro Schritt |
| Component-Restore | Quartalsweise | Non-kritisches Dataset restoren | RTO erfüllt, Daten verifiziert |
| Regional Failover Drill | Halbjährlich | Full DR-Region aktivieren | RTO erfüllt, Consumer geswitcht |
| Chaos-Injection | Quartalsweise | Failure in Staging | Self-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
- DR-Plan als PDF. Runbooks müssen ausführbare Skripte sein, version-controlled.
- Backups mit Prod-Keys verschlüsseln. Bei Key-Kompromiss sind beide weg.
- KMS-Keys nicht cross-region. Du kannst Daten in DR nicht entschlüsseln.
- Replikations-Health nicht monitoren. Replikation kann silent stehen bleiben.
- 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.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische 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.