Disaster Recovery as a Service auf einer Plattform, die Sie kontrollieren
Geschäftskontinuität ist keine Zeile in einem Anbietervertrag — sie ist ein Ergebnis, das Sie beweisen können müssen. Disaster Recovery as a Service (DRaaS) auf einer souveränen, selbst betriebenen Plattform liefert Ihnen DC-übergreifende synchrone Replikation, unveränderliche Backups und Failover, das getestet statt angenommen ist. Ænix baut und betreibt diese Plattformen auf Cozystack, sodass Ihre Recovery-Time- und Recovery-Point-Objectives eine Architektur sind, die Sie besitzen, und Nachweise, die Sie einem Regulator übergeben können.
Passt zu: Ænix Private Cloud Platform als regulierte Cloud-Basis, auf der DR aufsetzt; DORA-Compliance für die Betriebsresilienz-Pflichten, die DR erfüllen hilft. Starten Sie mit einem Platform Readiness Assessment →.
Was muss DRaaS wirklich garantieren?
Jedes Disaster-Recovery-Gespräch reduziert sich auf zwei Zahlen, und die meisten Anbieter-Pitches 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 viel Daten Sie verlieren dürfen, ausgedrückt in Zeit. Nächtliche Backups bedeuten ein RPO von bis zu 24 Stunden; synchrone Replikation zielt auf ein RPO nahe null für die geschützte Stufe.
Eine glaubwürdige DR-Fähigkeit verpflichtet sich auf beide Zahlen je Workload-Stufe und demonstriert sie dann in einer echten Notfallübung. Auf einer souveränen Plattform sind Replikationstopologie, Backup-Unveränderlichkeit und Drill-Protokolle Dinge, die Sie halten und einsehen können — Sie vertrauen nicht dem undurchsichtigen SLA eines Hyperscalers, um einen Fehlerfall zu beschreiben, den Sie nie dokumentiert sehen werden.
Wie funktioniert synchrone DC-übergreifende Replikation?
Die geschützte Stufe einer souveränen DR-Plattform basiert auf synchroner Block-Replikation, sodass ein committeter Write in mehr als einem Rechenzentrum existiert, bevor der Anwendung der Erfolg gemeldet wird.
In der Referenzarchitektur betreibt Cozystack einen Compute-Cluster, geo-verteilt über drei Rechenzentren. 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 geo-verteilt. Das Ergebnis ist eine Architektur, die ausgelegt ist, den Verlust eines ganzen Rechenzentrums ohne Datenverlust zu überstehen, weil sowohl die persistenten Daten als auch der Control-Plane-Zustand bereits anderswo liegen.
Das ist offene, CNCF-nahe Kubernetes-Infrastruktur statt proprietärer DR-Appliances. Das Kubernetes-Storage-Modell behandelt die replizierten Volumes als gewöhnliche Persistent Volumes, sodass Anwendungen keine spezielle DR-Integration brauchen, um von standortübergreifender Dauerhaftigkeit zu profitieren.
Warum unveränderliche Backups heute wichtiger sind denn je
Synchrone Replikation schützt vor Hardware- und Standortausfall, repliziert aber ein Ransomware-Verschlüsselungsereignis genauso getreu. Deshalb sind DR und Backup getrennte Schichten.
Backups auf der Plattform werden in Object Storage mit S3 Object Lock und Versionierung geschrieben, was unveränderliche Kopien erzeugt, die ein Angreifer, der die Primärumgebung kompromittiert hat, innerhalb der Aufbewahrungsfrist nicht verändern oder löschen kann. Velero-Backups auf Plattform- und Tenant-Ebene erfassen Kubernetes-Objekte und Volume-Snapshots, und ein Deletion-Protection-Webhook schützt kritische Objekte — Volumes, Namespaces, Load Balancer — vor versehentlicher oder böswilliger Entfernung. LUKS-Verschlüsselung im Ruhezustand und verschlüsselte Inter-DC-Replikation halten die Recovery-Kopien vertraulich und dauerhaft zugleich.
Diese Unterscheidung zählt für Regulatoren: Betriebsresilienz-Rahmenwerke erwarten zunehmend einen Recovery-Pfad, der nachweislich vom Wirkungsradius des Primärvorfalls isoliert ist.
Getestetes Failover, kein Papier-Failover
Ein DR-Plan, der nie geübt wurde, ist eine Hypothese. Die Plattformen, die Ænix betreibt, werden unter realen Ausfallbedingungen geprobt.
Im Referenzprojekt schaltet der Kunde regelmäßig Nodes ab, um Resilienz bewusst zu testen, was die nicht offensichtlichen Kaskaden aufdeckt, die eine Tabletop-Übung nie findet. Upgrades werden auf Staging nachweislich geprobt und dann auf Produktion wiederholt; nicht-deklarative Kommandos werden zugunsten von GitOps fallen gelassen; und jedes Szenario hat ein fertiges Runbook — DRBD-Recovery, Cluster-Upgrade, Storage-Failover. Das verwandelt ein RTO von einer Marketing-Zahl in eine Zahl, die Sie verteidigen können.
Beleg: ein 20-Stunden-Vorfall, null Datenverlust
Der klarste Beweis einer DR-Aufstellung ist ihr Verhalten am schlimmsten Tag. In unserer anonymisierten Sovereign-Public-Cloud-Case-Study traf einen Multi-Tenant-Anbieter ein kaskadierender Storage-Ausfall während eines großen Upgrades — ein DRBD-Race, verlorene Patches an einem Zwischenschritt und ein Breaking Change in der Netzwerkschicht. Das Team arbeitete den Vorfall rund 20 Stunden lang ab und stellte die Cloud mit null Datenverlust wieder her, dann wanderten die zugrunde liegenden Bugs upstream in LINSTOR und dessen CSI-Treiber. Dasselbe Drei-DC-Replikations-, geo-verteilte-etcd- und Immutable-Backup-Muster, das eine Bank oder ein Versicherer einsetzen würde, trug eine echte Produktions-Cloud durch eine echte Katastrophe.
Für DORA-regulierte Einrichtungen ist genau das die Form von Nachweis, die DORA (Verordnung (EU) 2022/2554) erwartet: getestete Resilienz, dokumentierte Wiederherstellung und Ziele, die Sie zeigen statt behaupten.
Nicht jeder Workload braucht dieselbe Recovery-Stufe
Jedes System als geschäftskritisch zu behandeln, ist der Weg, auf dem DR-Budgets explodieren und Notfallübungen unbeherrschbar werden. Eine funktionierende DR-Aufstellung stuft den Bestand zuerst.
- Stufe 0 — synchron. Systeme, bei denen ein RPO über nahezu null inakzeptabel ist — Kern-Banking-Ledger, Orderbücher, Patientenakten. Diese liegen auf synchroner DC-übergreifender Replikation und sind der Grund, warum die Drei-DC-Topologie existiert.
- Stufe 1 — asynchron plus häufige Backups. Wichtig, aber tolerant gegenüber Minuten von Datenverlust. Häufige unveränderliche Backups und asynchrone Replikation halten die Kosten im Verhältnis zum Risiko.
- Stufe 2 — Backup und Rebuild. Zustandslose oder leicht rekonstruierbare Dienste, wiederhergestellt aus unveränderlichen 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 Recovery-Pfad ehrlich ausreicht.
Wie Ænix bei Disaster Recovery arbeitet
Das Engagement läuft als Platform Readiness Assessment mit DR-gewichteten Workstreams: aktuelle RTO/RPO-Lage je Workload-Stufe, Replikations- und Geo-Topologie-Design, Backup-Unveränderlichkeit und Ransomware-Isolation sowie Reife des Drill-Prozesses. Ergebnis ist ein schriftlicher Bericht plus eine Phase-2-Roadmap. Wo die DR-Plattform zugleich die Produktionsplattform ist — der Regelfall — passt sie natürlich zu Data Sovereignty und DORA-Arbeit, sodass Kontinuität, Residenz und Compliance gemeinsam konstruiert statt nachträglich aufgesetzt werden.
Ænix ist das Team hinter Cozystack — einem CNCF-Projekt (heute Sandbox; Incubating erwartet für Spätsommer 2026), Apache 2.0. Ænix kommerzialisiert es als Ænix Platform — drei Plattformen auf einer Engine: Public Cloud, Private Cloud und AI — kombinierbar statt sich gegenseitig ausschließend. Wir bauen souveräne Disaster-Recovery- und Business-Continuity-Plattformen für regulierte Organisationen in der EU und DACH.