Backup & Notfallwiederherstellung
Um eine zuverlässige Recovery Time Objective (RTO) und Recovery Point Objective (RPO) zu erreichen, nutzt die Architektur eine zweischichtige Notfallwiederherstellungsstrategie: Eine Schicht schützt den aktiven OpenShift-Cluster, die andere schützt die externe VM-Ebene.
Ziele & Abdeckungsmatrix
Die Zielwerte werden pro Kunde angepasst; die folgende Tabelle ist die Referenz-Baseline.
| Komponente | Methode | Häufigkeit | RPO (Baseline) |
|---|---|---|---|
| PostgreSQL | Vollständig + inkrementell + VM-Snapshot | Kontinuierliches WAL + tägliches Voll-Backup | ≤ 5 Min. |
| OpenBao / Secret-Engine | Raft-Snapshot | Stündlich | ≤ 1 Std. |
| Anwendungszustand (PVs) | Velero-CSI-Snapshot | Täglich | ≤ 24 Std. |
| K8s-Manifeste / Konfiguration | Velero-Metadaten-Backup | Täglich | ≤ 24 Std. |
| GitLab (Quellcode) | Integriertes Backup | Täglich | ≤ 24 Std. |
| HSM-Material | Verbleibt im HSM (herstellerseitig repliziert) | n/z | n/z |
| Szenario | Ziel-RTO (Baseline) |
|---|---|
| Ausfall eines einzelnen Pods / Knotens | Automatisch, Sekunden (Selbstheilung) |
| Wiederherstellung einer zustandsbehafteten Komponente | < 1 Stunde |
| Vollständiger Standort-Failover (sekundärer Cluster) | < 4 Stunden |
Lebenszyklus der Notfallwiederherstellung
Schicht 1 — Backup-Betrieb (aktiver Cluster)
- Orchestrierung — der Velero-Operator führt geplante, automatisierte Snapshots innerhalb des OpenShift-Clusters aus.
- Datenzustand — Velero koordiniert sich mit ODF oder dem CSI-Plugin, um absturzkonsistente Block-Snapshots der Volumes zu erstellen, die zustandsbehaftete Workloads sichern.
- Manifeste & Metadaten — Velero erfasst gleichzeitig Kubernetes-API-Objekte: Namespaces, ServiceAccounts und ArgoCD-Anwendungen.
- Ziel — alle Backup-Metadaten und Volume-Nutzdaten werden verschlüsselt und außerhalb des Clusters in S3-kompatiblen Objektspeicher geschrieben.
# Beispiel: ein tägliches geplantes Backup des duokey-Namespace
velero schedule create duokey-daily \
--schedule="0 2 * * *" \
--include-namespaces duokey \
--snapshot-volumes
Schicht 2 — Infrastruktur-Backup (externe VMs)
- OpenBao — wird unabhängig gesichert, indem automatisierte Raft-Speicher-Snapshots ausgelöst werden. Die verschlüsselten Snapshot-Dateien werden knotenextern im Objektspeicher abgelegt.
- GitLab — verwendet seine integrierten Backup-Aufgaben, um Repositories, Datenbanken und Konfiguration im Objektspeicher zu archivieren.
- PostgreSQL — als kritischste Datenschicht nutzt es mehrere ergänzende Methoden: VM-Snapshots plus geplante vollständige und inkrementelle Datenbank-Backups.
# OpenBao-Raft-Snapshot (beispielhaft)
bao operator raft snapshot save openbao-$(date +%F).snap
Wiederherstellungsverfahren (sekundärer / passiver Standort)
Im Falle eines katastrophalen Ausfalls, der den aktiven Cluster betrifft:
- Zielcluster bereitstellen — aktivieren oder initialisieren Sie einen sekundären, minimalen OpenShift-Cluster am Wiederherstellungsstandort / in der Availability Zone.
- Secret-Engine wiederherstellen — die sekundäre OpenBao-Instanz wird entsiegelt und lädt den replizierten Raft-Snapshot, wodurch die Schlüsselfunktionen wiederhergestellt werden.
- Velero-Wiederherstellung ausführen — Velero verbindet sich mit dem replizierten Objektspeicher am Wiederherstellungsstandort und führt eine globale Wiederherstellung durch.
- Volumes wieder aufbauen — der CSI-Treiber stellt Block-Snapshots wieder her und bindet sie an frisch gestartete PostgreSQL- und Redis-StatefulSet-Pods.
- GitOps-Abgleich — ArgoCD verbindet sich erneut über HTTPS/SSH mit GitLab, scannt die Manifeste und gleicht jegliche Abweichung zurück zur Konformität ab.
- PostgreSQL wiederherstellen — Wiederherstellung aus dem neuesten Datenbank-Backup im Objektspeicher oder Rückgriff auf einen vollständigen VM-Snapshot, falls Backups nicht eingespielt werden können.
# Wiederherstellung aus dem neuesten Velero-Backup
velero restore create --from-backup duokey-daily-<timestamp>
Testen Ihres DR-Plans
Warten Sie nicht auf einen echten Notfall
Üben Sie das Wiederherstellungsverfahren in regelmäßigen Abständen (mindestens vierteljährlich). Überprüfen Sie, ob die RTO/RPO-Ziele tatsächlich erreicht werden und die Runbooks aktuell sind.
| Element | Häufigkeit |
|---|---|
| Überprüfen, ob Backups abgeschlossen wurden | Täglich (automatisierte Warnung) |
| Wiederherstellungstest (einzelne Komponente) | Monatlich |
| Vollständige DR-Failover-Übung | Vierteljährlich |
| RTO/RPO-Ziele überprüfen | Jährlich |