Disaster-Recovery-Architekturdiagramm: RPO, RTO und vier Strategien

Hochverfügbarkeit hält ein System am Laufen, wenn ein Server oder eine Availability Zone ausfällt. Bei Disaster Recovery geht es um die größeren Ausfälle: eine ganze Region weg, eine beschädigte Datenbank, ein gelöschter Account, Ransomware. Der Plan dafür muss existieren, bevor so etwas passiert, und die Architektur entscheidet, wie viele Daten du verlierst und wie lange du ausfällst.

Dieser Artikel definiert die beiden Zahlen, mit denen jedes DR-Design beginnt, geht die vier Standardstrategien mit ihren Kosten durch und zeichnet ein Warm-Standby-Setup über zwei Regionen.

RPO und RTO

• Recovery Point Objective (RPO): wie viele Daten du dir leisten kannst zu verlieren, gemessen in Zeit. Ein RPO von 5 Minuten heißt, dass der Verlust der letzten 5 Minuten an Schreibvorgängen akzeptabel ist.
• Recovery Time Objective (RTO): wie lange der Service ausfallen darf, bevor er wieder läuft.

Beide Werte kommen vom Business, nicht aus der Technik, und beide kosten Geld: Jeder Schritt in Richtung null Datenverlust und null Ausfallzeit vervielfacht Infrastruktur und Betriebsaufwand. Frag, was eine Stunde Ausfall kostet und welche Daten sich nicht wiederherstellen lassen, und wähl dann das günstigste Design, das die Zahlen erfüllt. Verschiedene Teile eines Systems bekommen meist unterschiedliche Ziele: Der Checkout braucht vielleicht Minuten, das Reporting-Datenlager einen Tag.

Vier Strategien

Das Whitepaper von AWS zu Disaster Recovery teilt DR in vier Strategien ein, geordnet nach Kosten und Wiederherstellungstempo. Dieselben Ideen gelten in jeder Cloud und in eigenen Rechenzentren.

Backup and Restore baut alles aus Backups und Infrastrukturcode neu auf. Das reicht für viele interne Systeme, solange die Wiederherstellung getestet ist und sich die Infrastruktur aus Code neu erstellen lässt.

Pilot Light hält die Daten live (replizierte Datenbanken, replizierte Buckets), lässt die Rechenleistung aber aus oder auf null. Wiederherstellung heißt, die Dienste zu starten und zu skalieren.

Warm Standby betreibt eine kleine, aber funktionierende Kopie. Sie kann sofort Traffic mit reduzierter Kapazität bedienen und skaliert während des Failovers hoch. Weil sie ständig läuft, ist sie auch leicht zu testen.

Active/Active bedient Nutzer ständig von beiden Standorten aus. Der Failover ist dann vor allem eine Routing-Änderung, aber Schreibzugriffe in zwei Regionen bringen Konfliktbehandlung oder ein Single-Writer-Design mit sich, und die Kosten sind zwei Produktionsumgebungen.

Auswahl für ein System: ein Beispiel

Ein Onlineshop mit 2.000 Bestellungen pro Stunde verlangt für den Checkout ein RPO von 5 Minuten und ein RTO von 30 Minuten. Backup and Restore verfehlt das RPO: Nächtliche Snapshots können einen Tag an Bestellungen verlieren, und der Wiederaufbau des Stacks dauert Stunden. Pilot Light erfüllt das RPO über Datenbankreplikation, aber Dienste, Caches und Suchindex in einer anderen Region zu starten und aufzuwärmen dauert beim ersten Versuch meist länger als 30 Minuten. Warm Standby erfüllt beides: Die Replika liegt Sekunden zurück, und die verkleinerten Dienste laufen bereits, also besteht der Failover aus Beförderung, Hochskalieren und einer DNS-Umschaltung. Active/Active würde das RTO weiter senken, verdoppelt aber die Kosten und bringt Schreibkonflikte, die der Shop nicht lösen muss. Die Antwort: Warm Standby für den Checkout, Backup and Restore für das Reporting-Datenlager.

Backups braucht es trotzdem

Replikation kopiert auch Fehler. Löscht jemand eine Tabelle oder verschlüsselt Ransomware die Daten, folgt die Replika innerhalb von Sekunden. Halte Point-in-Time-Backups vor, die die Replikation nicht erreichen kann:

• Snapshots und Transaktionslogs, die Tage oder Wochen aufbewahrt werden.
• Kopien in einem separaten Account mit anderen Zugangsdaten, damit ein kompromittierter Account nicht beides löschen kann.
• Unveränderliche oder gesperrte Backups, wo deine Plattform das anbietet.
• Regelmäßige Wiederherstellungstests. Ein Backup, das nie jemand wiederhergestellt hat, ist eine Hoffnung, kein Backup.

Die Failover-Abfolge

Schreib die Schritte auf und halte sie kurz:

1. Entscheiden. Wer darf einen Disaster-Fall ausrufen, und auf welches Signal hin? Automatischer Failover für eine ganze Region ist riskant; viele Teams automatisieren die Erkennung und behalten eine menschliche Entscheidung bei.
2. Die Datenbank-Replika befördern: In der Standby-Region wird sie zur primären.
3. Rechenleistung hochskalieren: die Standby-Region auf volle Kapazität bringen.
4. Traffic umleiten, indem du DNS-Failover-Einträge oder die Gewichte eines globalen Load Balancers umstellst. Berücksichtige DNS-TTLs und Clients, die zwischenspeichern.
5. Prüfen mit synthetischen Checks, dann ankündigen.
6. Den Rückweg planen. Der Failback ist eine zweite Migration und braucht dieselbe Sorgfalt.

Das Architekturdiagramm

So liest du es:

• Oben: Nutzer erreichen das DNS-Failover-Routing. Heute schickt es den gesamten Traffic an die primäre Region; die gestrichelte Kante zeigt, wohin der Traffic nach einem Failover geht.
• Links, die primäre Region: ein Load Balancer, sechs App-Instanzen, Objektspeicher und die primäre Datenbank.
• Rechts, die Standby-Region: dieselbe Form in kleinerem Maßstab: zwei App-Instanzen, eine Replika-Datenbank, die per asynchroner Replikation gespeist wird, und replizierte Objekte. Gestrichelte Kanten markieren die Pfade, die erst nach einem Failover Traffic tragen.
• Unten: Tägliche Snapshots gehen in einen Backup-Vault in einem anderen Account, der Schutz gegen Beschädigung und Löschung, den Replikation nicht bieten kann.
• Der Markdown-Block nennt die Ziele, die das Design erfüllen soll.

Testen

DR-Pläne scheitern an Details: ein abgelaufenes Zertifikat in der Standby-Region, ein fest codierter Endpunkt, ein fehlendes Secret, eine DNS-TTL von einem Tag. Die einzige Abhilfe ist, den Failover tatsächlich auszuführen. Plane Übungen, fang mit einem einzelnen Service an und miss das echte RTO gegen das Ziel. Ein Warm Standby macht das günstig, und das ist einer seiner größten Vorteile gegenüber Pilot Light.

Was in ein DR-Diagramm gehört

• Beide Standorte, mit dem, was jeweils läuft, und in welchem Maßstab.
• Replikationspfade und ihr Modus, synchron oder asynchron, denn das bestimmt das RPO.
• Der Traffic-Schalter, und ob er automatisch arbeitet.
• Backups außerhalb des Explosionsradius, einschließlich der Account-Grenze.
• Die Ziele, direkt neben dem Design notiert.

Zur Netzwerkseite über mehrere Regionen siehe das AWS-Multi-Region-Architekturdiagramm. Das Diagramm zur Datenbankreplikation erklärt Replikationsverzögerung und Failover genauer, und das Incident-Response-Flussdiagramm behandelt das Ausrufen und Abarbeiten des Incidents selbst.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Cloud-Pack zwei Cloud-Region-Rahmen hinzu, einen für die primäre und einen für die Standby-Region.
3. Füge in jede einen Cloud-Lastverteiler, eine Recheninstanz für die App, einen Objektspeicher-Node und eine Verwaltete Datenbank ein. Schreib die Instanzanzahl in die Beschriftungen.
4. Füge über den Regionen eine Person aus dem C4-Modell-Pack und einen DNS-Node aus dem Netzwerk-Pack hinzu, darunter einen weiteren Objektspeicher-Node für den Backup-Vault.
5. Zeichne die Replikation zwischen den Regionen, stell die Pfade, die nur beim Failover genutzt werden, gestrichelt dar und füge einen Markdown-Block aus dem Basis-Pack mit RPO und RTO hinzu.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen RPO und RTO? Das RPO gibt an, wie viele Daten du verlieren kannst, gemessen in Zeit vor dem Ausfall. Das RTO gibt an, wie lange es dauert, bis der Service danach wieder läuft.

Ist Hochverfügbarkeit dasselbe wie Disaster Recovery? Nein. Hochverfügbarkeit fängt Ausfälle von Komponenten und Zonen automatisch und laufend ab. Disaster Recovery behandelt größere Ereignisse wie den Ausfall einer Region oder beschädigte Daten, oft mit einem bewusst ausgelösten Failover.

Brauche ich noch Backups, wenn ich in eine andere Region repliziere? Ja. Replikation kopiert Löschungen und Beschädigungen fast sofort. Backups in einem separaten Account schützen davor.

Welche Disaster-Recovery-Strategie soll ich wählen? Die günstigste, die das RPO und RTO erfüllt, das das Business für dieses System braucht. Warm Standby ist ein verbreiteter Mittelweg, weil es bezahlbar und leicht zu testen ist.

Wie oft sollte ich Disaster Recovery testen? Oft genug, dass das Runbook stimmt, bei kritischen Systemen häufig quartalsweise, und nach jeder größeren Architekturänderung.

Kostenlos starten — ein Seat, keine Kreditkarte.