| Stufe (vorgeschlagen) | Verfügbarkeit | Muster | RPO / RTO |
|---|---|---|---|
| Standard | 99,7 % | Multi-Zone-, HA-Datenbank, Air-Gap-Backups | Zone: RPO ≈ 0. Region: Wiederherstellung aus dem Tresor. |
| Live DR | 99,9 % | Eine zweite Region, die live läuft | RPO Sekunden, RTO ≤ 15 Minuten |
| Live DR Premium | 99,95 % | Verkehr in beiden Regionen, 24/7-Priorität | RPO Sekunden, RTO ≤ 5 Minuten |
Der Anteil der Systeme außerhalb der Produktion beträgt 95 %. Die Verfügbarkeit wird monatlich am TRANXACT-Eingang gemessen, wobei das vereinbarte Wartungsfenster (vorgeschlagene 4 Stunden pro Monat) ausgenommen ist.
Die Tier-Konfiguration muss vor der Dimensionierung angepasst werden. Live DR entspricht einer zweiten Region in voller Größe und verdoppelt in etwa die laufenden Infrastrukturkosten; sie sollte als separate Zeile gegenüber den dadurch eingesparten Ausfallkosten dargestellt werden.
Lebe, nicht passiv
Ein passiver Standby-Server verharrt im Leerlauf, wird höchstens einmal jährlich getestet und skaliert im Fehlerfall durch Wiederherstellung und Hochskalierung. Live DR hingegen betreibt einen vollwertigen Cluster und eine kontinuierlich replizierte Datenbank, die rund um die Uhr Lese-, Berichts-, ASK und synthetische Posting-Anfragen verarbeitet. Failover bedeutet Hochfahren – es wird nichts neu erstellt – und die Funktionsfähigkeit wird minütlich überprüft.
| Prüfen | Auswirkungen | Wie oft | Kategorie |
|---|---|---|---|
| Kontinuierliche Verifizierung – synthetische Buchungen, Verzögerungsalarme, regionsübergreifende Ledger-Prüfsumme | Keiner | Jede Minute | Standard (TO_4.10.01) |
| Geplante Übergabeübung – Schreibvorgänge pausieren, befördern, verschieben, überprüfen; Rollen tauschen | Schreibvorgänge für Sekunden angehalten | Vierteljährlich | Standard (TO_4.10.03) |
| Zusätzliche Umschaltübung | Schreibvorgänge für Sekunden angehalten | Auf Anfrage, 2 Wochen im Voraus | Zusätzliche (TO_4.10.04) |
| Isolierter Bohrer – ein umzäunter Klon, bei dem die Integrationen deaktiviert sind | Keine in der Produktion | Auf Anfrage, 2 Wochen im Voraus | Zusätzliche (TO_4.10.05) |
| Reinraum-Wiederherstellungstest | Keine in der Produktion | Jährlich | Standard (TO_4.9.07) |
| Geschäftsvalidierung nach einer Übung | Kundenaufwand | Jede Übung | Ausgeschlossen (TO_4.10.06) |
Backups
| Produktionsdatenbank | Nicht-Produktionsdatenbank | |
|---|---|---|
| Genommen | Tägliche Momentaufnahme + kontinuierliche Protokollierung | Tagesüberblick |
| Wiederherstellen | Jeder Zeitpunkt innerhalb von 30 Tagen | Die letzte Momentaufnahme, vor 14 Tagen |
| Tresorkopie | Täglich, unveränderlich, 90 Tage | Wöchentlich, unveränderlich, 30 Tage |
Dokumente werden fortlaufend versioniert und täglich in den Produktions-Vault kopiert. Infrastruktur als Code und Konfiguration befinden sich ebenfalls im Vault, sodass die Laufzeitumgebung aus dem Code neu erstellt und nicht wiederhergestellt wird.
Warum der Tresor?
Die Replikation schützt vor Ausfällen, nicht vor Datenbeschädigung. Ransomware oder beschädigte Daten werden innerhalb von Sekunden auf das Standby-System und in die DR-Region repliziert. Der Datentresor ist ein separates Konto mit eigenen Identitäten und Schlüsseln, ohne Netzwerkverbindung zur Produktionsumgebung, mit einer einmaligen Aufbewahrungsfrist, die selbst Administratoren nicht verkürzen können, und mit Vier-Augen-Genehmigung zum Löschen. Wiederherstellungen aus dem Tresor erfolgen in einer isolierten Umgebung – Scan, Abgleich und anschließende Übertragung – niemals direkt in die Produktionsumgebung.
Eine Aufbewahrungssperre kann nach ihrer Einrichtung nicht verkürzt werden. Verlängern Sie sie im Voraus, wenn dies für Prüfungs- oder Rechtszwecke erforderlich ist, und bemessen Sie die langfristigen Kopien anhand des Wachstums des Hauptbuchs und des Dokumentenvolumens, nicht anhand der aktuellen Datenbankgröße.
Calderwood entschied sich für Live DR mit 99,9 % Verfügbarkeit in einer zweiten Azure-Region im selben Zuständigkeitsbereich. Vor dem Go-Live sind die erste Umstellungsübung und eine Clean-Root-Wiederherstellung als Bereitschaftsprüfungen geplant. Die Bank- und Gehaltsabrechnungspartner sind in den Umstellungsplan eingebunden, sodass deren Endpunkte dem Traffic Manager folgen.
Probier es aus Ein Batch-Job beschädigt um 14:05 Uhr 4.000 Calderwood-Rechnungen. Live DR funktioniert einwandfrei, mit einer Verzögerung von 2 Sekunden. Ist ein Failover auf die DR-Region die Lösung?
Nein. Die Datenbeschädigung wurde unmittelbar nach ihrem Auftreten sowohl auf das Standby- als auch auf das DR-System repliziert – ein Failover führt zu denselben fehlerhaften Daten. Die Lösung ist eine Wiederherstellung zu einem bestimmten Zeitpunkt (14:04 Uhr) (TO_4.9.05, Standard) oder, falls der Verlauf selbst verdächtig ist, eine vollständige Wiederherstellung aus dem Tresor (TO_4.9.06), wobei der Finanzcontroller die wiederhergestellten Daten freigeben muss (TO_4.9.11).