Regions- und Provider-übergreifendes Backup#

Die aktuelle openDesk SaaS-Architektur basiert auf STACKIT Managed Kubernetes, STACKIT Managed Services (PostgreSQL, S3, Secrets Manager) und Self-Managed Datenbanken (MariaDB, Cassandra) innerhalb des Clusters. Ein Ausfall einer gesamten Region oder ein vollständiger Providerwechsel stellt ein erhebliches Risiko dar.

Ziel dieses Kapitels ist es, einen Überblick darüber zu geben, wie die Plattform im Falle eines regionalen Ausfalls oder eines erforderlichen Providerwechsels grundsätzlich wiederhergestellt werden kann. Dabei werden zentrale Aspekte wie Datenwiederherstellung, Bereitstellung der Infrastruktur und erneutes Ausrollen der Applikationen betrachtet.

Backups sichern Daten (PVCs, DB-Dumps), sind jedoch allein nicht ausreichend. Erst in Kombination mit der reproduzierbaren Bereitstellung der Infrastruktur (GitOps), geografisch redundanten Backups (S3-Replikation) und automatisierten Restore-Prozessen entsteht ein funktionsfähiges, providerunabhängiges Wiederherstellungskonzept.

Georedundante Replikation der Backups in eine zweite STACKIT-Region#

Für die Absicherung gegen regionale Ausfälle werden Backup-Daten zusätzlich in einer zweiten STACKIT-Region bereitgestellt. Die Replikation erfolgt dabei automatisiert über die bestehende Offsite-Strategie des Object Storage und stellt sicher, dass gesicherte Daten auch außerhalb des primären Standorts verfügbar sind. Dieses Vorgehen ergänzt die lokale Backup-Strategie und bildet die Grundlage für eine Wiederherstellung der Umgebung im Falle eines regionalen Ausfalls.

Technische Umsetzung:

• Integration bestehender Offsite-Strategie:
  • Im bestehenden Offsite-Konzept werden alle produktiven Buckets regelmäßig auf einen zweiten geografischen Standort repliziert.
• Verschlüsselung:
  • Während der Replikation bleiben sämtliche Backup-Daten vollständig clientseitig verschlüsselt. Restic verschlüsselt den gesamten Datenbestand bereits vor der Übertragung, sodass keine ungeschützten Inhalte zwischen den Regionen übertragen oder im Ziel-Storage abgelegt werden.
• Retention:
  • Damit die Aufbewahrungszeiträume einheitlich eingehalten werden, muss die Retention-Policy in beiden Regionen konsistent konfiguriert sein. Die operative Ausführung der Prune-Prozesse erfolgt ausschließlich in der primären Region, um Konflikte und Divergenzen zwischen den Repositories zu vermeiden. (Best Practice)

Wiederherstellung bei einem Wechsel zu einem anderen Provider/On-Premises#

Während die georedundante Replikation in Kapitel 8.1 den Betrieb innerhalb der STACKIT-Plattform absichert, muss ein vollständiges Exit-Szenario auch die Wiederherstellung in einer komplett neuen Infrastruktur berücksichtigen. Dies umfasst sowohl die Migration zu einem anderen Cloud-Provider als auch den Betrieb in einer On-Premises-Umgebung.

Wiederherstellung bei einem Wechsel zu einem anderen Cloud-Provider#

Ein providerübergreifender Wechsel – beispielsweise zu AWS, Azure oder einer anderen Public Cloud – ist grundsätzlich umsetzbar, erfordert jedoch eine umfangreichere Anpassung der Infrastrukturkomponenten. Da GitOps providerunabhängig funktioniert und sämtliche Kubernetes-Ressourcen deklarativ vorliegen, können sie in einem neu bereitgestellten Cluster reproduziert werden. Die Bereitstellung des Zielclusters erfolgt über Terraform oder ein anderes Infrastructure-as-Code-Werkzeug, abhängig von der Zielplattform.

Die Backup-Daten sind dank Restic vollständig portabel und können in jedem S3-kompatiblen Storage genutzt werden, wie z.b. AWS S3 oder MinIO. Herausforderungen ergeben sich jedoch durch plattformspezifische Unterschiede. Storage-Klassen, LoadBalancer-Typen, Ingress-Controller, Netzwerkpfade und DNS-Konfigurationen müssen an die Zielumgebung angepasst werden. Der STACKIT Secrets Manager steht in anderen Clouds nicht zur Verfügung, sodass ein alternatives Secret-Management wie HashiCorp Vault, AWS KMS/Secrets Manager oder Azure Key Vault integriert werden muss.

Die Migration der Datenbanken erfolgt unterschiedlich komplex: PostgreSQL und MariaDB lassen sich durch standardisierte Dumps problemlos migrieren, während Cassandra aufgrund seiner Cluster-Topologie und Versionsabhängigkeit eine sorgfältige Planung und identische Schema-Definitionen erfordert. Insgesamt ist ein Providerwechsel realistisch und machbar, jedoch mit höherem Aufwand, größerer Komplexität verbunden.

Wiederherstellung in einer On-Premises-Umgebung#

Eine Wiederherstellung in einer On-Premises-Umgebung stellt die technisch anspruchsvollste Variante dar. Kubernetes kann zwar On-Prem bereitgestellt werden – beispielsweise über Rancher, OpenShift oder Kubeadm-basierte Deployments – jedoch müssen dadurch sämtliche Komponenten, die in STACKIT als Managed Service verfügbar sind, selbst betrieben werden.

GitOps bleibt auch in dieser Umgebung einsetzbar, sodass Applikationen reproduzierbar bereitgestellt werden können. Die Backup-Daten lassen sich über Restic in MinIO-, Ceph- oder andere S3-kompatible Storage-Systeme einspielen. Der operative Aufwand steigt jedoch erheblich, da die gesamte Infrastruktur, inklusive Hardware, Hochverfügbarkeit, Netzwerksegmente und Storage-Pools, selbst aufgebaut und betrieben werden muss.

Insgesamt ist die Wiederherstellung On-Premises möglich, aber mit sehr hohem technischem, organisatorischem und betrieblichen Aufwand verbunden.