Geschäftskontinuität ist keine Zeile in einem Anbietervertrag — sie ist ein Ergebnis, das Sie belegen können müssen. Disaster Recovery as a Service (DRaaS) auf einer souveränen, selbst betriebenen Plattform bietet synchrone Replikation über Rechenzentren, Backups, die von der Primärumgebung isoliert sind, und eine Wiederherstellung, die geprobt statt angenommen ist. Ænix baut und betreibt diese Plattformen auf Cozystack, sodass Ihre Recovery-Time- und Recovery-Point-Objectives eine Architektur sind, die Ihnen gehört, und Nachweise, die Sie einem Regulator vorlegen können.
Passt zu: Ænix Private Cloud Platform als regulierte Cloud-Basis, auf der DR aufsetzt; DORA-Compliance für die Pflichten zur operationalen Resilienz, die DR erfüllen hilft. Beginnen Sie mit einem Platform Readiness Assessment →. Für Infrastrukturverantwortliche: siehe den Leitfaden für Leiter Infrastruktur.
Was muss DRaaS wirklich garantieren?
Jedes Gespräch über Disaster Recovery läuft auf zwei Zahlen hinaus, und die meisten Anbieterpräsentationen umgehen sie stillschweigend.
- Recovery-Time-Objective (RTO) — wie lange Sie ausfallen dürfen. Das hängt davon ab, wie schnell Sie den zweiten Standort in Betrieb nehmen, nicht davon, wie groß Ihr Backup ist.
- Recovery-Point-Objective (RPO) — wie viele Daten Sie verlieren dürfen, ausgedrückt in Zeit. Nächtliche Backups bedeuten ein RPO von bis zu 24 Stunden; synchrone Replikation zielt für die geschützte Stufe auf ein RPO nahe null.
Eine glaubwürdige DR-Fähigkeit legt sich für jede Workload-Stufe auf beide Zahlen fest und demonstriert sie dann in einer Übung. Auf einer souveränen Plattform liegen Replikationstopologie, Unveränderlichkeit der Backups und Übungsprotokolle in Ihrer Hand und lassen sich prüfen — Sie verlassen sich nicht auf das undurchsichtige SLA eines Hyperscalers, um einen Fehlerfall zu beschreiben, dessen Dokumentation Sie nie zu sehen bekommen.
Wie synchrone Replikation über Rechenzentren funktioniert
Die geschützte Stufe einer souveränen DR-Plattform beruht auf synchroner Block-Replikation: Ein bestätigter Schreibvorgang existiert in mehr als einem Rechenzentrum, bevor die Anwendung den Erfolg gemeldet bekommt.
In der Referenzarchitektur betreibt Cozystack einen Compute-Cluster, der über drei Rechenzentren verteilt ist. Volumes werden synchron mit LINSTOR/DRBD bei Replikationsfaktor drei repliziert — eine Replik pro Standort —, und etcd, der Zustandsspeicher des Kubernetes-Clusters, ist über dieselben drei Standorte verteilt. Da sowohl die persistenten Daten als auch der Zustand der Control Plane an jedem Standort eine Kopie haben, gehen beim Verlust eines Rechenzentrums keine bestätigten Daten verloren. Betroffene VMs und Services an den verbleibenden Standorten wieder in Betrieb zu nehmen, geschieht nicht automatisch, sondern folgt einem dokumentierten, geprobten Runbook. Dieses Multi-Site-Design ist eine Engineering-Leistung im Rahmen des Aufbaus; es ist kein Standard einer Cozystack-Installation an einem Standort.
Das ist offene, an der CNCF ausgerichtete Kubernetes-Infrastruktur statt proprietärer DR-Appliances. Das Storage-Modell von Kubernetes behandelt die replizierten Volumes als gewöhnliche Persistent Volumes, sodass Anwendungen keine eigene DR-Integration brauchen, um von der standortübergreifenden Dauerhaftigkeit zu profitieren.
Warum unveränderliche Backups wichtiger sind denn je
Synchrone Replikation schützt vor Hardware- und Standortausfällen, repliziert aber eine Ransomware-Verschlüsselung genauso zuverlässig. Deshalb sind DR und Backup getrennte Schichten.
Velero-Backups auf Plattform- und Tenant-Ebene erfassen Kubernetes-Objekte und Volume-Snapshots. In einem DR-Aufbau werden sie in Object Storage außerhalb des Clusters geschrieben, den sie schützen, mit S3 Object Lock und Versionierung auf diesem Speicher — ein Angreifer, der die Primärumgebung kompromittiert hat, kann sie innerhalb der Aufbewahrungsfrist weder ändern noch löschen. (Standardmäßig liegt der Backup-Bucket im Cluster; ihn auszulagern, gehört zum Aufbau.) Volume-Verschlüsselung mit LUKS lässt sich pro Storage Class optional aktivieren.
Für Regulatoren zählt diese Unterscheidung: Rahmenwerke zur operationalen Resilienz erwarten zunehmend einen Wiederherstellungsweg, der nachweislich außerhalb der Auswirkungen des primären Vorfalls liegt.
Geprobte statt theoretische Wiederherstellung
Ein DR-Plan, der nie geübt wurde, ist eine Hypothese. Die Plattformen, die Ænix baut, werden tatsächlich geprobt.
In der Fallstudie des Anbieters mit drei Rechenzentren schaltet der Kunde regelmäßig gezielt Nodes ab, um die Resilienz zu testen — so kommen die nicht offensichtlichen Kaskaden ans Licht, die eine reine Planspielübung nie findet. Upgrades werden dokumentiert auf Staging geprobt und dann auf der Produktion wiederholt; nicht deklarative Befehle werden zugunsten von GitOps aufgegeben; und für jedes Szenario gibt es ein fertiges Runbook — DRBD-Recovery, Cluster-Upgrade, Storage-Failover. So wird aus einem RTO eine Zahl, die Sie verteidigen können, statt einer Marketingangabe.
Beleg: 20 Stunden Vorfall, kein Datenverlust
Der klarste Beleg für eine DR-Aufstellung ist ihr Verhalten am schlimmsten Tag. In unserer anonymisierten Fallstudie zur souveränen Public Cloud traf einen mandantenfähigen Anbieter während eines großen Upgrades ein kaskadierender Storage-Ausfall — eine DRBD-Race-Condition, verlorene Patches in einem Zwischenschritt und ein Breaking Change in der Netzwerkschicht. Das Team arbeitete rund 20 Stunden an dem Vorfall und stellte die Cloud ohne Datenverlust wieder her; die zugrunde liegenden Bugs gingen anschließend upstream an LINSTOR und dessen CSI-Treiber. Dasselbe Muster aus Replikation über drei Rechenzentren und geo-verteiltem etcd trug eine echte Produktions-Cloud durch einen echten Vorfall.
Für Einrichtungen im Geltungsbereich von DORA ist das genau die Art von Nachweis, die DORA (Verordnung (EU) 2022/2554) in Art. 11–12 verlangt: getestete Wiederherstellung, dokumentierte Abläufe und Ziele, die Sie zeigen statt behaupten. Was die Plattform standardmäßig nicht leistet, ist auf der Seite mit den DORA-Nachweisen aufgeführt.
Nicht jeder Workload braucht dieselbe Recovery-Stufe
Wer jedes System als geschäftskritisch behandelt, lässt DR-Budgets explodieren und macht Übungen unbeherrschbar. Eine funktionierende DR-Aufstellung stuft die Landschaft zuerst ein.
- Stufe 0 — synchron. Systeme, bei denen ein RPO über nahezu null inakzeptabel ist — Kernbanken-Hauptbücher, Orderbücher, Patientenakten. Sie liegen auf synchroner Replikation über Rechenzentren und sind der Grund, warum es die Topologie mit drei Rechenzentren gibt.
- Stufe 1 — asynchron plus häufige Backups. Wichtig, aber tolerant gegenüber einigen Minuten Datenverlust. Häufige Backups in gesperrten externen Speicher und asynchrone Replikation halten die Kosten im Verhältnis zum Risiko.
- Stufe 2 — Backup und Neuaufbau. Zustandslose oder leicht rekonstruierbare Services, wiederhergestellt aus Backups und Infrastructure as Code, mit einem RTO in Stunden statt Sekunden.
Die Einstufung ist das erste Ergebnis des Assessments, weil sie entscheidet, wohin die teure synchrone Kapazität geht und wo ein günstigerer Wiederherstellungsweg ehrlich ausreicht.
Wie Ænix bei Disaster Recovery arbeitet
Das Projekt läuft als Platform Readiness Assessment mit DR-Schwerpunkt in den Arbeitssträngen: aktuelle RTO/RPO-Lage je Workload-Stufe, Entwurf der Replikations- und Standorttopologie, Unveränderlichkeit der Backups und Isolation gegen Ransomware sowie Reife des Übungsprozesses. Ergebnis ist ein schriftlicher Bericht plus eine Umsetzungs-Roadmap für Phase 2. Wo die DR-Plattform zugleich die Produktionsplattform ist — der Regelfall —, passt sie natürlich zu Datensouveränität und der Ausrichtung an DORA, sodass Kontinuität, Residenz und Compliance gemeinsam entworfen statt nachträglich angeflanscht werden.
Ænix hat Cozystack entwickelt — ein CNCF-Sandbox-Projekt (der Antrag auf CNCF Incubation befindet sich in der Due-Diligence-Prüfung) unter Apache 2.0 — und pflegt es gemeinsam mit Maintainern anderer Unternehmen. Ænix bietet auf dieser Grundlage drei Plattformen an — Public Cloud, Private Cloud und AI. Wir entwerfen Architekturen für Disaster Recovery und Geschäftskontinuität für regulierte Organisationen.