Begriff

DRaaS (Disaster Recovery as a Service)

Cloud Security S1

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Erinnerst du dich an Disaster Recovery? (Wenn das Rechenzentrum abbrennt, braucht man ein zweites). Früher mussten Firmen ein zweites Rechenzentrum bauen und leer stehen lassen. Extrem teuer. Mit DRaaS mietest du den Notfall-Parkplatz in der Cloud. Du zahlst (fast) nichts, solange kein Notfall ist. Erst wenn es brennt, drückst du den "Roten Knopf". Dann fahren in der Cloud tausende Server hoch – und du zahlst für die Nutzung. Wenn der Notfall vorbei ist, schaltest du sie ab und zahlst wieder wenig.

Merksatz: Die Auslagerung der Notfallwiederherstellung an einen Cloud-Anbieter, um Kosten für eigene redundante Hardware zu sparen.

1. Continuous Data Protection (CDP) Mechanismen

Alte Backups funktionieren mittels Snapshot (Lese das Laufwerk). Das ist um 12 Uhr mittags fertig und dann passiert nichts mehr, bis Mitternacht. Das gibt ein extrem schlechtes RPO von 12h. Moderne DRaaS-Broker (wie Zerto) nisten sich tiefer ein: direkt in den VMWare/Hyper-V Hypervisor-Kernel. Noch bevor ein Block auf die physischen RAID-Platten geschrieben wird (Block-Level-Interception), krallt sich der Splitter-Agent das I/O-Signal und repliziert es unendlich als Stream ins Cloud-Rechenzentrum ("Journaling"). Das senkt das Recovery Point Objective (RPO) auf wenige Sekunden. Du kannst durch Journal-Rückspulen wie bei einer Zeitmaschine den Zustand der VM "von vor genau 7 Minuten und 12 Sekunden zurückholen" (Sekundengenaue Rettung vor dem Ransomware-Verschlüsselungs-Klick).

2. DNS Geolocation und Automatisiertes Zonen-Flipping

Wenn das Haupt-RZ brennt, wie finden Kunden-Rechner magisch den Weg auf AWS? Manuell die DNS-IP via Hand austauschen dauert Minuten, und das globale "DNS-Propagating" bis alle Provider es wissen, dauert Stunden de facto-Downtime. DRaaS-Setups verknüpfen sich mit Global Traffic Managern (GTMs), oft auf Anycast Basis. Tausende kleine Edge-Node-Prüfer von Akamai oder Cloudflare (Health-Checkers) pingen stur das Haupt-Rechenzentrum aus aller Welt an. Stirbt das RZ, flippt das BGP-Routing automatisch (TTL wird vorab künstlich auf winzige 30 Sekunden getrimmt), und der weltweite Ingress-Traffic schlägt in der Sekunde in die aufgewärmte Cloud-VPC (AWS/Azure) ein.

3. Orchestrierung von Start-Sequenzen (Runbooks)

Bei einem Ausfall ist Chaos die Realität. Eine Enterprise-App ist kein einzelner Server, sondern 30 Systeme, die abhängig sind. Startet man in der Desaster-Cloud stumpf alles zeitgleich (wie oft in billigen Skripten), crasht das System, weil das SAP-Backend versucht Tabellen zu lesen, die die OracleDB (die 3 Min Ladezeit braucht) noch nicht aufgebaut hat. Ausgereiftes DRaaS arbeitet per Automated Recovery Runbooks (Playbooks). Dieses Skript orchestriert wie ein Dirigent: "1. Starte Active Directory Domain Controller -> 2. Warte auf PING OK -> 3. Starte SQL Backend -> 4. Warte bis Port 1433 öffnet -> 5. Starte Web-Tier."

Quick-Check

Ist DRaaS das gleiche wie Cloud-Backup?
Nein. Backup speichert nur Dateien. DRaaS speichert lauffähige Maschinen. Aus einem Backup kannst du nicht arbeiten, du musst es erst zurückspielen. Auf DRaaS kannst du sofort arbeiten.
Brauche ich schnelles Internet?
Ja! Wenn deine Firma "in der Cloud läuft", müssen alle Mitarbeiter über das Internet darauf zugreifen. Wenn dann das Internet ausfällt, hilft dir auch DRaaS nichts.
Ist es billiger?
Ja, extrem (OpEx statt CapEx). Du hast keine Kapitalbindung für ungenutzte Hardware.