k3s Disaster-Recovery-Testing und Edge-Patterns | DevOps

k3s Disaster-Recovery-Testing und Edge-Patterns | DevOps | Tobias Weiss

Disaster Recovery für k3s dreht sich nicht nur um Backups — es geht darum, genau zu wissen, wie lange die Wiederherstellung dauert, und diesen Prozess zu testen, bevor man ihn braucht. Dieser Artikel behandelt k3s-spezifische DR-Testverfahren, Edge-Computing-Patterns und Werkzeuge, die automatisierte Backups und Wiederherstellung vereinfachen.

Geplante Snapshots mit etcd-snapshot-schedule-cron

k3s enthält den Befehl etcd-snapshot-schedule-cron für automatisierte, periodische Backups des eingebetteten etcd.

Grundlegende Cron-basierte Planung

Backups alle 6 Stunden mit einer Aufbewahrung von 7 Tagen planen:

sudo nano /etc/rancher/k3s/config.yaml

# Hinzufügen oder ändern:
etcd-snapshot-schedule-cron: "0 */6 * * *"
etcd-snapshot-retention: 168  # Snapshots 168 Stunden (7 Tage) aufbewahren

k3s neu starten, um die Änderung anzuwenden:

sudo systemctl restart k3s

Geplante Snapshots verifizieren

Prüfen, dass Snapshots erstellt werden:

# Alle Snapshots auflisten
sudo k3s etcd-snapshot ls

# Beispielausgabe:
# /var/lib/rancher/k3s/server/db/snapshots/etcd-snapshot-2026-07-11_06-00-00.db
# /var/lib/rancher/k3s/server/db/snapshots/etcd-snapshot-2026-07-11_12-00-00.db
# /var/lib/rancher/k3s/server/db/snapshots/etcd-snapshot-2026-07-11_18-00-00.db

Erweiterte Planung: Mehrere Cron-Ausdrücke

Für unterschiedliche Backup-Frequenzen (stündlich für das Aktuelle, täglich für längere Aufbewahrung):

etcd-snapshot-schedule-cron: |
  - "0 * * * *"    # Jede Stunde
  - "0 0 * * *"    # Jeden Tag um Mitternacht
etcd-snapshot-retention:
  hourly: 24 # Stündliche Snapshots 24 Stunden aufbewahren
  daily: 30 # Tägliche Snapshots 30 Tage aufbewahren

Hinweis: Diese erweiterte Syntax erfordert möglicherweise k3s v1.30+.

S3-Offload für Remote-Speicherung

Automatischen Upload in S3-kompatiblen Speicher konfigurieren:

# k3s Server-Konfiguration
etcd-snapshot-name: "k3s-server-01"
etcd-snapshot-s3: true
etcd-snapshot-s3-endpoint: "s3.amazonaws.com"
etcd-snapshot-s3-bucket: "k3s-backups"
etcd-snapshot-s3-region: "us-east-1"
etcd-snapshot-s3-skip-ssl-verify: false

AWS-Credentials setzen:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="us-east-1"

k3s neu starten:

sudo systemctl restart k3s

S3-Upload verifizieren:

aws s3 ls s3://k3s-backups/

# Beispielausgabe:
# 2026-07-11 12:00:00    2097152 k3s-server-01-2026-07-11_12-00-00.db
# 2026-07-11 18:00:00    2097152 k3s-server-01-2026-07-11_18-00-00.db

Sicherheitshinweis: etcd-Snapshots enthalten Cluster-Secrets (Service Accounts, Tokens, Zertifikate). Server-seitige S3-Verschlüsselung auf dem Bucket aktivieren (SSE-S3 oder SSE-KMS) und einen dedizierten IAM-User nur auf s3:PutObject/s3:GetObject für das Backup-Präfix beschränken. Ein öffentlicher Backup-Bucket ist ein Data Breach in Wartestellung.

Failover-Testing: Eingebettetes etcd

Failover-Testing des eingebetteten etcd validiert, dass dein k3s-Cluster einen kompletten Control-Plane-Ausfall übersteht.

Test 1: Control-Plane-Wiederherstellung aus dem Backup

Ziel: k3s-Server aus einem etcd-Snapshot wiederherstellen und den Cluster-Zustand verifizieren.

Voraussetzungen:

Funktionierender k3s-Server mit eingebettetem etcd
Gültiger etcd-Snapshot (via k3s etcd-snapshot ls)

Vorgehen:

Testszenario erstellen — Datenänderung simulieren:

# Test-Namespace und Deployment erstellen
kubectl create namespace dr-test
kubectl create deployment nginx-test --image=nginx -n dr-test
kubectl get pods -n dr-test

# Snapshot vor dem Fehler erstellen
sudo k3s etcd-snapshot save --name "pre-failure-test"

Fehler simulieren — k3s stoppen und etcd beschädigen:

# k3s stoppen
sudo systemctl stop k3s

# Beschädigtes etcd sichern (für den Wiederherstellungsversuch)
sudo cp /var/lib/rancher/k3s/server/db/etcd /var/lib/rancher/k3s/server/db/etcd.corrupted

# etcd-Daten beschädigen
sudo rm /var/lib/rancher/k3s/server/db/etcd

Aus dem Snapshot wiederherstellen:

# Aus dem Snapshot wiederherstellen
sudo k3s server \
  --cluster-reset \
  --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/pre-failure-test.db

# k3s starten
sudo systemctl start k3s

# Cluster-Gesundheit verifizieren
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -n dr-test

Erwartetes Ergebnis:

k3s startet erfolgreich
Nodes melden Ready
nginx-test-Pod existiert und läuft
Alle k3s-Komponenten (traefik, metrics-server) betriebsbereit

Wiederherstellungszeit messen:

# Zeit vom Fehlerbeginn bis zum Abschluss der Wiederherstellung
# Typischer RTO: 2-5 Minuten für eingebettetes etcd auf kleinen Clustern

Test 2: Multi-Server-HA-Failover

Ziel: etcd-HA-Failover in einem 3-Server-k3s-Cluster testen.

Voraussetzungen:

3-Node-k3s-Cluster mit eingebettetem etcd-HA
Alle Server gesund und synchron

Vorgehen:

Aktuellen Cluster-Zustand verifizieren:

# Alle Nodes prüfen
kubectl get nodes -o wide

# etcd-Member prüfen
sudo k3s etcd-snapshot status

# Konsistenz der k3s-Cluster-ID über alle Server prüfen
sudo k3s kubectl get configmap -n kube-system cluster-config -o yaml

Ausfall von Server 1 simulieren:

# Auf Server 1
sudo systemctl stop k3s

# Auf Server 2 oder 3 (überlebender Server)
kubectl get nodes
# Erwartet: server1 zeigt NotReady, server2 und server3 Ready

# etcd-Quorum verifizieren
sudo k3s etcd-snapshot status
# Erwartet: 2/3 Member gesund (Quorum bleibt erhalten)

Cluster-Operationen während des Failovers testen:

# Test-Ressource erstellen
kubectl create namespace failover-test
kubectl run test-pod --image=nginx -n failover-test

# Pod-Scheduling verifizieren
kubectl get pods -n failover-test -o wide
# Erwartet: Pod auf überlebendem Node geplant

Server 1 wiederherstellen:

# Auf Server 1
sudo systemctl start k3s

# Wiederbeitritt des Clusters verifizieren
kubectl get nodes
# Erwartet: Alle 3 Nodes Ready

# etcd-Mitgliedschaft verifizieren
sudo k3s etcd-snapshot status
# Erwartet: 3/3 Member gesund

Failover-Zeit messen:

# Zeit vom Stopp von server1 bis zum erhaltenen Cluster-Quorum
# Typischer RTO: 30-90 Sekunden für eingebettetes etcd-HA

Failover-Testing: Externes PostgreSQL

Für k3s-Cluster, die statt eingebettetem etcd externes PostgreSQL verwenden.

Test 1: Ausfall des PostgreSQL-Primary

Ziel: k3s-Verhalten testen, wenn das PostgreSQL-Primary ausfällt.

Voraussetzungen:

k3s-Cluster mit externem PostgreSQL konfiguriert
PostgreSQL-HA (Patroni oder Ähnliches) konfiguriert
Gültiges PostgreSQL-Backup

Vorgehen:

Aktuellen Zustand verifizieren:

# k3s-Cluster-Gesundheit prüfen
kubectl get nodes
sudo k3s kubectl get pods -A

# PostgreSQL-Cluster-Status prüfen
patronictl -c /etc/patroni/patroni.yml list

Primary-Ausfall simulieren:

# PostgreSQL-Primary stoppen
sudo systemctl stop postgresql

# Auf der PostgreSQL-Replica (jetzt Primary)
# Automatisches Failover verifizieren
patronictl -c /etc/patroni/patroni.yml list

# Erwartet: Neues Primary gewählt, Replica befördert

k3s-Operationen während des Failovers testen:

# Test-Deployment erstellen
kubectl create deployment test-deploy --image=nginx

# Deployment-Erfolg verifizieren
kubectl get pods
# Erwartet: Pods erfolgreich geplant

Wiederherstellungszeit messen:

# Zeit vom Stopp des PostgreSQL-Primary bis zur Fortsetzung der k3s-Operationen
# Typischer RTO: 1-3 Minuten (abhängig von der Patroni-Failover-Zeit)

Test 2: Vollständige PostgreSQL-Wiederherstellung aus dem Backup

Ziel: PostgreSQL aus dem Backup wiederherstellen und den k3s-Cluster erholen.

Voraussetzungen:

PostgreSQL-Backup (pg_dump oder physisches Backup)
k3s-Cluster heruntergefahren

Vorgehen:

# k3s-Server stoppen
sudo systemctl stop k3s

# PostgreSQL-Datenbank löschen und neu erstellen
sudo -u postgres psql -c "DROP DATABASE IF EXISTS k3s;"
sudo -u postgres psql -c "CREATE DATABASE k3s;"

# Aus dem Backup wiederherstellen
sudo -u postgres psql k3s < /backup/k3s-postgres-backup.sql

# k3s-Server starten
sudo systemctl start k3s

# Cluster-Wiederherstellung verifizieren
kubectl get nodes
kubectl get pods -A

Edge-Computing-DR-Patterns

Edge Computing bringt besondere DR-Herausforderungen mit sich: intermittierende Konnektivität, begrenzte Bandbreite und physisch verteilte Standorte.

Multi-Cluster-DR mit Rancher Fleet

Rancher Fleet verwaltet mehrere k3s-Cluster zentral. DR-Patterns unterscheiden sich von Single-Cluster-Szenarien.

Pattern 1: Zentrales Backup-Repository

Alle Edge-Cluster pushen Backups in ein zentrales Repository für zentrale Recovery-Verwaltung.

Architektur:

Edge Site 1 (k3s) ----\
Edge Site 2 (k3s) ----+--> S3 Central Repository ----> Recovery Workstation
Edge Site 3 (k3s) ----/                          |
                                              Backup Validation

Implementierung:

# Fleet-Cluster-Template für Edge-Standorte
apiVersion: v1
kind: ConfigMap
metadata:
  name: k3s-backup-config
  namespace: cattle-system
data:
  config.yaml: |
    etcd-snapshot-schedule-cron: "0 */4 * * *"
    etcd-snapshot-retention: 96  # 4 Tage
    etcd-snapshot-s3: true
    etcd-snapshot-s3-endpoint: "s3.eu-central-1.amazonaws.com"
    etcd-snapshot-s3-bucket: "edge-k3s-backups"
    etcd-snapshot-s3-region: "eu-central-1"

Ausrollen via Fleet:

# Auf alle Edge-Cluster anwenden
fleetctl apply -f fleet-cluster-template.yaml

# Backups über alle Standorte verifizieren
aws s3 ls s3://edge-k3s-backups/ --recursive

# Beispielausgabe:
# 2026-07-11 08:00:00    2097152 edge-site-01/k3s-etcd-snapshot.db
# 2026-07-11 08:00:00    2097152 edge-site-02/k3s-etcd-snapshot.db
# 2026-07-11 12:00:00    2097152 edge-site-01/k3s-etcd-snapshot.db
# 2026-07-11 12:00:00    2097152 edge-site-02/k3s-etcd-snapshot.db

Pattern 2: Local-First-Backup mit periodischer Synchronisation

Für Edge-Standorte mit intermittierender Konnektivität sorgen lokale Backups mit periodischer Synchronisation für Haltbarkeit.

Implementierung:

#!/bin/bash
# /usr/local/bin/edge-backup-sync.sh

# 1. Lokalen etcd-Snapshot erstellen
sudo k3s etcd-snapshot save --name "$(date +%Y-%m-%d_%H-%M-%S)"

# 2. Konnektivität zum zentralen Repository prüfen
if ping -c 1 central-repo.example.com &> /dev/null; then
  # 3. Aktuelle Snapshots hochladen
  for snapshot in /var/lib/rancher/k3s/server/db/snapshots/*.db; do
    aws s3 cp "$snapshot" "s3://edge-k3s-backups/$(hostname)/" --only-newer
  done
else
  logger "Central repository unreachable, retaining local backups"
fi

# 4. Alte lokale Snapshots aufräumen (24 Stunden behalten)
find /var/lib/rancher/k3s/server/db/snapshots/ -name "*.db" -mtime +1 -delete

Zu cron hinzufügen:

# crontab -e
# Alle 2 Stunden
0 */2 * * * /usr/local/bin/edge-backup-sync.sh

RPO/RTO-Planung für Edge-Szenarien

Edge Computing erfordert sorgfältige RPO- (Recovery Point Objective) und RTO-Planung (Recovery Time Objective) wegen der Konnektivitätsbeschränkungen. Leite die Zielwerte aus Geschäftszahlen ab, nicht aus Defaults: Schätze die Kosten einer Stunde Ausfallzeit, vergleiche sie mit den Kosten häufigerer Snapshots und wähle Zielwerte, die du tatsächlich erfüllen und messen kannst. Als Faustregel erlaubt 99,9 % Verfügbarkeit ~8,8 Stunden Ausfallzeit pro Jahr; 99,99 % erlaubt ~53 Minuten. Die Szenarien unten gehen davon aus, dass Zielwerte gemessen werden, nicht angestrebt sind.

Szenario	Netzwerk	RPO	RTO	Strategie
Urbanes Edge	Glasfaser 1Gbps	15 min	30 min	Häufige Snapshots + S3-Sync
Ländliches Edge	LTE 10Mbps	2 Stunden	4 Stunden	Lokales Backup + täglicher Sync
Offline-Edge	Keine Konnektivität	24 Stunden	Manuell	Lokales Backup + On-Site-Recovery-Kit
Satelliten-Edge	Satellit 2Mbps	4 Stunden	8 Stunden	Komprimierte Backups + geplanter Sync

Disaster Recovery auf Standortebene

Komplette Standortwiederherstellung von Grund auf (Hardware-Ausfall, Naturkatastrophe).

Vorbereitung des Recovery-Kits:

# /opt/dr-recovery-kit/README.md

# Inhalt des Recovery-Kits:
# 1. Aktuelles k3s-Binary und Konfiguration
# 2. etcd-Snapshot aus S3
# 3. Persistent-Volume-Backups (falls vorhanden)
# 4. Netzwerkkonfigurationsskripte
# 5. DR-Runbook mit Schritt-für-Schritt-Verfahren

# Wiederherstellungsablauf:
# 1. Neue Hardware oder VM bereitstellen
# 2. k3s aus dem Recovery-Kit installieren
# 3. etcd aus dem Snapshot wiederherstellen
# 4. Persistent Volumes wiederherstellen (falls vorhanden)
# 5. Cluster-Gesundheit verifizieren
# 6. Anwendungskonnektivität testen

Automatisiertes Recovery-Skript:

#!/bin/bash
# /opt/dr-recovery-kit/recover-site.sh

set -e

SITE_ID="edge-site-01"
K3S_VERSION="v1.30.0+k3s1"
SNAPSHOT_NAME="k3s-latest.db"
S3_BUCKET="edge-k3s-backups"

echo "Starting site recovery for $SITE_ID..."

# 1. Aktuellsten Snapshot herunterladen
aws s3 cp "s3://$S3_BUCKET/$SITE_ID/$SNAPSHOT_NAME" /tmp/

# 2. k3s installieren
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="$K3S_VERSION" sh -

# 3. k3s für die Wiederherstellung konfigurieren
cat <<EOF | sudo tee /etc/rancher/k3s/config.yaml
cluster-reset: true
cluster-reset-restore-path: /tmp/$SNAPSHOT_NAME
EOF

# 4. k3s starten
sudo systemctl start k3s

# 5. Auf k3s warten
until sudo k3s kubectl get nodes &> /dev/null; do
  echo "Waiting for k3s to start..."
  sleep 5
done

# 6. Cluster-Gesundheit verifizieren
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -A

echo "Site recovery complete!"

Restic-Integration für k3s Persistent Volumes

etcd-Snapshots decken nur den Cluster-Zustand ab. Für Anwendungsdaten in Persistent Volumes Restic für Backup und Recovery verwenden.

Restic-Setup für k3s-PVs

# restic installieren
wget https://github.com/restic/restic/releases/download/v0.16.0/restic_0.16.0_linux_amd64.bz2
bunzip2 restic_0.16.0_linux_amd64.bz2
sudo mv restic_0.16.0_linux_amd64 /usr/local/bin/restic
sudo chmod +x /usr/local/bin/restic

# Restic-Repository initialisieren (S3)
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/k3s-pv-backups"
export RESTIC_PASSWORD="your-secure-password"

restic init

# k3s-Systemverzeichnisse ausschließen (kein Backup nötig)
cat <<EOF > /tmp/restic-excludes.txt
/var/lib/rancher/k3s/server/db/etcd
/var/lib/rancher/k3s/agent/containerd/io.containerd.content.v1.content
/var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs
EOF

# k3s Persistent Volumes sichern
restic backup /var/lib/rancher/k3s/agent/pv --exclude-file=/tmp/restic-excludes.txt --tag "pv-backup"

Automatisiertes PV-Backup-Skript

#!/bin/bash
# /usr/local/bin/k3s-pv-backup.sh

set -e

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/k3s-pv-backups"
export RESTIC_PASSWORD="your-secure-password"

# Nur gemountete PVs sichern
for mount in $(findmnt -l | grep /var/lib/rancher/k3s/agent/pv | awk '{print $1}'); do
  pod_name=$(echo "$mount" | cut -d/ -f7)
  pv_name=$(echo "$mount" | cut -d/ -f6)

  echo "Backing up PV: $pv_name (pod: $pod_name)"

  restic backup "$mount" \
    --exclude-file=/tmp/restic-excludes.txt \
    --tag "pv-backup" \
    --tag "pv:$pv_name" \
    --tag "pod:$pod_name"
done

# Alte Backups aufräumen (30 Tage behalten)
restic forget --keep-daily 30 --prune

# Repository-Integrität prüfen
restic check

Tägliche Backups planen:

# crontab -e
0 2 * * * /usr/local/bin/k3s-pv-backup.sh >> /var/log/k3s-pv-backup.log 2>&1

PVs aus dem Restic-Backup wiederherstellen

# Backup-Snapshot finden
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/k3s-pv-backups"
export RESTIC_PASSWORD="your-secure-password"

# Snapshots auflisten
restic snapshots --tag "pv:my-app-pv"

# Bestimmtes PV wiederherstellen
restic restore latest --tag "pv:my-app-pv" --target /var/lib/rancher/k3s/agent/pv/my-app-pv

# Betroffene Pods neu starten, damit sie die wiederhergestellten Daten aufnehmen
kubectl delete pod -l app=my-app --force --grace-period=0

Von der Prozedur zum Beweis: DR-Drills als Chaos Engineering

Die obigen Prozeduren sind nur so gut wie ihre letzte Ausführung. Ein Backup, das du nie wiederhergestellt hast, ist kein Backup. DR-Testing ist Chaos Engineering für Infrastruktur: Du injizierst absichtlich Fehler (den falschen Node stoppen, die falsche Datei beschädigen, das falsche Snapshot ziehen) und beobachtest, ob sich das System erholt. Dieselbe Lektion, die für Software-Engines gilt, gilt hier — Beispielbasiertes Testing findet, woran du gedacht hast; Fehlerinjektion findet, woran du nicht gedacht hast. Ein geplantes Snapshot, das nie wiederherstellungsgetestet wird, ist exakt die „Konfiguration, die existiert, aber nicht durchgesetzt wird"-Falle: Sie erzeugt falsches Vertrauen.

Drill-Design: Geseedet, absichtlich, abwechslungsreich

Seede dein Chaos — ein DR-Drill muss reproduzierbar sein: Dokumentiere, welcher Node ausgefallen ist, welches Snapshot wiederhergestellt wurde und welcher RPO/RTO gemessen wurde. Nicht reproduzierbare Drills lehren nichts.
Variiere das Opfer — rotiere, welcher Server stoppt, aus welchem Backup du wiederherstellst (aktuellstes vs. ältestes vs. nur-S3) und zu welcher Tageszeit der Drill läuft. Der Bug, der sich versteckt, ist der, der nur mit einem alten Snapshot an einem kalten Morgen auftritt.
Beziehe den menschlichen Pfad ein — das Recovery-Kit und das Runbook sind Teil des Systems unter Test. Die Hälfte des Drill-Werts liegt darin, zu entdecken, dass das Runbook veraltet oder im Recovery-Kit ein Schritt fehlt.

Messen statt annehmen

„Typischer RTO: 2-5 Minuten" ist eine Behauptung, keine Tatsache. Messe die tatsächliche Wiederherstellungszeit in deiner Umgebung, auf deiner Hardware, mit deinem Netzwerk:

Jeden Restore-Schritt mit time ausführen und im Runbook dokumentieren
Den RTO/RPO-Trend über Drills hinweg verfolgen — eine Regression der Wiederherstellungszeit ist ein Frühwarnsignal
Jede Performance-Behauptung benchmark-verifizieren; die „typischen" Zahlen in diesem Artikel sind Ausgangspunkte, keine Garantien

Idempotente Restores und Contract-Erhaltung

Eine Restore-Prozedur muss idempotent sein: Sie zweimal auf demselben Host auszuführen, darf den Zustand nicht beschädigen. Wenn ein Restore-Skript von einem sauberen Zustand ausgeht, aber ein vorheriger Restore Artefakte hinterlassen hat, taucht diese Contract-Verletzung um 3 Uhr nachts bei einem echten Incident auf, nicht beim Happy-Path-Drill. Teste den Contract explizit: Führe den Restore aus, führe ihn erneut aus und behaupte beide Male identische Cluster-Gesundheit.

Validierung als CI-artiges Gate

Die Checkliste unten sollte durch Automatisierung durchgesetzt werden, nicht durch Erinnerung:

restic check läuft nächtlich und alarmiert bei Fehlern (Repository-Integrität)
Snapshot-Freshness-Alert: Fehlschlag, wenn das neueste etcd-Snapshot älter ist als der konfigurierte Zeitplan
S3-Offload-Verifikation: Ein geplanter Job listet den Bucket und behauptet die erwarteten Snapshot-Zahlen pro Standort
Das Site-Recovery-Skript läuft regelmäßig gegen eine Sandbox — nicht nur, wenn sich jemand daran erinnert, es zu testen

Die 3×-Regel für die DR-Bereitschaft

Bevor du die DR-Strategie als produktionsreif erklärst, führe den vollständigen Drill dreimal mit drei aufeinanderfolgenden Erfolgen durch — inklusive mindestens eines Restores auf einen frischen Host (nicht dieselbe VM, die du beschädigt hast). Zwei Erfolge können Glück sein; drei sind ein Muster.

Restore-on-a-Schedule: Kontinuierliche Verifizierbarkeit

Quartals-Drills verifizieren deine Prozeduren; ein wöchentlich geplanter Restore verifiziert deine Snapshots. Richte einen Cron-Job ein, der das neueste etcd-Snapshot nimmt, einen Wegwerf-k3s-Cluster (gleiche Version) bereitstellt, hinein wiederherstellt, Health-Checks ausführt und ihn wieder zerstört. Wenn ein Snapshot korrupt ist — Stunden später durch kubectl get nodes in der Sandbox entdeckt — hast du eine Woche Snapshots als Fallback statt eines Quartals falschen Vertrauens. Der Sandbox-Restore ist auch der perfekte Proberaum für recover-site.sh: Jede Woche übt er exakt das Skript, das du bei einem echten Incident ausführen wirst.

DR-Validierungs-Checkliste

Bevor du deine DR-Strategie als produktionsreif erklärst, validiere jede Komponente.

Validierung des eingebetteten etcd

Geplante Snapshots konfiguriert und verifiziert
S3-Offload getestet und verifiziert
Snapshot-Aufbewahrungsrichtlinie konfiguriert
Control-Plane-Recovery aus dem Snapshot getestet
Wiederherstellungszeit gemessen und dokumentiert
Snapshot-Wiederherstellung auf frischer k3s-Installation getestet

Validierung des eingebetteten etcd-HA

3-Server-Cluster betriebsbereit
Quorum-Failover getestet (1 Server stoppen)
Split-Brain-Verhinderung verifiziert
Cluster-Wiederbeitritt getestet (gestoppten Server wiederherstellen)
Failover-Zeit gemessen (Ziel: < 90 Sekunden)

Validierung des externen PostgreSQL

PostgreSQL-HA (Patroni) konfiguriert
Primary-Failover getestet
k3s-Operationen während des Failovers verifiziert
Backup des PostgreSQL getestet
Recovery aus dem Backup getestet

Edge-Computing-Validierung

Multi-Cluster-Backup-Repository konfiguriert
Local-First-Backup mit periodischem Sync getestet
RPO/RTO für alle Edge-Szenarien dokumentiert
Standort-Level-Recovery-Kit vorbereitet
Automatisierte Standort-Recovery in der Sandbox getestet

Persistent-Volume-Validierung

Restic-Repository initialisiert
PV-Backup-Zeitplan konfiguriert
Backup-Aufbewahrungsrichtlinie gesetzt
PV-Restore getestet
Restic-Integritätschecks geplant

Integrationstests

Vollständiges DR-Szenario getestet (etcd + PV + PostgreSQL)
End-to-End-Recovery gemessen und Trend über Drills verfolgt
DR-Runbook dokumentiert und reviewed
DR-Drills geplant (quartalsweise empfohlen)
Vollständiger Drill besteht 3× in Folge, inklusive Restore auf frischen Host
Restore-Prozeduren als idempotent nachgewiesen (zweimal ausführen, identisches Ergebnis)
Automatisierte Gates aktiv: restic check nächtlich, Snapshot-Freshness-Alert, S3-Offload-Verifikation
Wöchentlicher Sandbox-Restore beweist, dass Snapshots wiederherstellbar sind (nicht nur Quartals-Drills)
S3-Backup-Bucket verschlüsselt (SSE) mit Least-Privilege-IAM

DR-Runbook-Vorlage

Standardisiere deine DR-Verfahren mit einer Runbook-Vorlage.

# k3s Disaster-Recovery-Runbook

## 1. Incident-Erkennung

**Trigger**:

- k3s-Server down
- etcd-Korruption erkannt
- PostgreSQL-Primary nicht verfügbar
- Kompletter Standortausfall

**Verifikation**:

```bash
sudo systemctl status k3s
sudo k3s kubectl get nodes
sudo k3s etcd-snapshot status
```


## 2. Auswirkungsbewertung

**Geschäftsauswirkung**:

- Betroffene Anwendungen: [Liste]
- Betroffene Nutzer: [Anzahl]
- Geschätzte Ausfallzeit: [RTO]

**Technische Auswirkung**:

- Clustergröße: [Nodes/Pods]
- Gefährdete Daten: [etcd / PV / PostgreSQL]
- Recovery-Quelle: [Snapshot / Backup / von Grund auf]

## 3. Durchführung der Wiederherstellung

### Option A: etcd-Snapshot-Recovery

**RTO**: 2-5 Minuten
**Anwendungsfall**: Eingebettetes etcd, aktuelles Snapshot verfügbar

**Schritte**:

1. [k3s stoppen: `sudo systemctl stop k3s`]
2. [Aus Snapshot wiederherstellen: `sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.db`]
3. [k3s starten: `sudo systemctl start k3s`]
4. [Recovery verifizieren: `kubectl get nodes`]

### Option B: PostgreSQL-Recovery

**RTO**: 5-10 Minuten
**Anwendungsfall**: Externes PostgreSQL, Patroni-Failover fehlgeschlagen

**Schritte**:

1. [k3s-Server stoppen: `sudo systemctl stop k3s`]
2. [PostgreSQL wiederherstellen: `psql k3s < /backup/k3s-backup.sql`]
3. [k3s-Server starten: `sudo systemctl start k3s`]
4. [Cluster verifizieren: `kubectl get pods -A`]

### Option C: Vollständige Standort-Recovery

**RTO**: 30-60 Minuten
**Anwendungsfall**: Kompletter Standortausfall, Hardware-Ersatz erforderlich

**Schritte**:

1. [Neue Hardware bereitstellen]
2. [Recovery-Skript ausführen: `/opt/dr-recovery-kit/recover-site.sh`]
3. [PVs aus Restic wiederherstellen]
4. [Anwendungskonnektivität verifizieren]

## 4. Validierung nach der Wiederherstellung

**Validierungsschritte**:

- [ ] Alle Nodes Ready
- [ ] Alle Pods Running
- [ ] Anwendungskonnektivität verifiziert
- [ ] Datenintegrität geprüft
- [ ] Performance-Baseline verifiziert

## 5. Root-Cause-Analyse

**Incident-Zeitachse**:

- [Zeit]: [Ereignis]

**Root Cause**:

- [Beschreibung]

**Präventivmaßnahmen**:

- [Maßnahmen]

## 6. Kommunikation

**Informierte Stakeholder**:

- [ ] Engineering-Team
- [ ] Produkt-Team
- [ ] Support-Team
- [ ] Kunden (falls kundenseitig sichtbar)

**Kommunikationskanäle**:

- Slack: #dr-incidents
- E-Mail: dr-notifications@example.com
- Statusseite: https://status.example.com

## 7. Lessons Learned

**Was gut lief**:

- [Beobachtungen]

**Was verbessert werden könnte**:

- [Maßnahmen]

**DR-Runbook-Updates**:

- [Dokumentationsänderungen]

## Weiterführende Lektüre

- [k3s in Production: Upgrades, Backup und Disaster Recovery](/content/devops/k3s-production-upgrades-backup-dr/) — Umfassende Produktions-Patterns für k3s
- [Disaster Recovery Self-Hosted](/content/devops/disaster-recovery-self-hosted/) — Generische DR-Patterns für selbst gehostete Infrastruktur
- [Edge-Computing-Patterns mit k3s](/content/devops/edge-computing-patterns-k3s/) — Multi-Cluster-Verwaltung mit Rancher Fleet

---

Regelmäßiges DR-Testing ist der Unterschied zwischen einer kleinen Störung und einem katastrophalen Ausfall. Plane quartalsweise DR-Drills, misse deinen tatsächlichen RTO und aktualisiere dein Runbook mit Lessons Learned.

Stripe Testing Best Practices: From Test Cards to Production Confidence

Stripe-Testing-Best-Practices: Von Testkarten zu Produktionsvertrauen

Edge Computing Patterns with k3s: Multi-Cluster Management, Offline-First Deployments, and Observability at Scale

Geplante Snapshots mit etcd-snapshot-schedule-cron

Grundlegende Cron-basierte Planung

Geplante Snapshots verifizieren

Erweiterte Planung: Mehrere Cron-Ausdrücke

S3-Offload für Remote-Speicherung

Failover-Testing: Eingebettetes etcd

Test 1: Control-Plane-Wiederherstellung aus dem Backup

Test 2: Multi-Server-HA-Failover

Failover-Testing: Externes PostgreSQL

Test 1: Ausfall des PostgreSQL-Primary

Test 2: Vollständige PostgreSQL-Wiederherstellung aus dem Backup

Edge-Computing-DR-Patterns

Multi-Cluster-DR mit Rancher Fleet

Pattern 1: Zentrales Backup-Repository

Pattern 2: Local-First-Backup mit periodischer Synchronisation

RPO/RTO-Planung für Edge-Szenarien

Disaster Recovery auf Standortebene

Restic-Integration für k3s Persistent Volumes

Restic-Setup für k3s-PVs

Automatisiertes PV-Backup-Skript

PVs aus dem Restic-Backup wiederherstellen

Von der Prozedur zum Beweis: DR-Drills als Chaos Engineering

Drill-Design: Geseedet, absichtlich, abwechslungsreich

Messen statt annehmen

Idempotente Restores und Contract-Erhaltung

Validierung als CI-artiges Gate

Die 3×-Regel für die DR-Bereitschaft

Restore-on-a-Schedule: Kontinuierliche Verifizierbarkeit

DR-Validierungs-Checkliste

Validierung des eingebetteten etcd

Validierung des eingebetteten etcd-HA

Validierung des externen PostgreSQL

Edge-Computing-Validierung

Persistent-Volume-Validierung

Integrationstests

DR-Runbook-Vorlage