Business-Continuity-Fragebögen fragen nach RPO, RTO, Redundanz und Übungen. Hier sind die Antworten – getrennt nach dem, was die Technik heute leistet, und dem, was wir vertraglich zusagen.
Vier Szenarien
| Szenario | Was geschieht | Datenverlust |
|---|---|---|
| Die Anwendung stürzt ab | Die Gesundheitsprüfung fällt auf Rot, die Plattform startet den Container automatisch neu. Nachrichten in der Warteschlange und geplante Aufträge sind dauerhaft gespeichert und laufen nach dem Neustart weiter | keiner |
| Eine Auslieferung ist fehlerhaft | Nach dem Ausrollen prüft die Pipeline die Gesundheit; bei Rot rollt sie automatisch auf das zuletzt laufende Image zurück | keiner |
| Daten werden beschädigt oder versehentlich gelöscht | Die Datenbank lässt sich auf jeden Zeitpunkt der letzten 14 Tage zurücksetzen (Point-in-Time-Recovery). Dokumente: gelöschte Blobs sind sieben Tage wiederherstellbar; vor Ablauf ihrer Aufbewahrungsfrist lassen sich Dokumente in der Plattform ohnehin nur archivieren, nicht endgültig löschen; das Änderungsprotokoll zeigt, was wann geändert wurde | bis zum gewählten Zeitpunkt – für die Datenbank auf Minuten eingrenzbar |
| Die Azure-Region fällt aus | Dokumente (RA-GRS) und Audit-Archiv (GRS) sind in einer zweiten Region repliziert; die Datenbanksicherung liegt in der Region. Ein Wiederanlauf in einer anderen Region ist ein manueller Vorgang aus der Infrastruktur-Beschreibung heraus | Datenbank: seit der letzten Sicherung |
Was das in Kennzahlen heißt
- RPO (wie viel Arbeit verloren gehen kann): Für die Datenbank Minuten, weil jeder Zeitpunkt innerhalb der Aufbewahrung wiederherstellbar ist. Dokumente liegen innerhalb der Region dreifach synchron und werden in die zweite Region asynchron repliziert – bei einem Regionsausfall entspricht der Verlust dem Rückstand dieser Replikation (in der Regel Minuten).
- RTO (wie lange es dauert): In der Übung vom 22.09.2026 stand der auf einen Zeitpunkt zurückgesetzte Datenbankserver nach rund sieben Minuten bereit, alle Tabellen vollständig bis zum gewählten Wiederherstellungspunkt; das Umschalten der Anwendung auf den neuen Server kommt hinzu. Gemessen wurde in der Entwicklungsumgebung. Eine Zusage machen wir daraus erst, wenn dieselbe Übung in der Produktivumgebung gelaufen ist – eine Zahl aus einer anderen Umgebung ist eine Messung, keine Zusage.
Wer geweckt wird
Überwacht und alarmiert werden Verfügbarkeit, Fehlerquote, Datenbank und Warteschlange; ein Alarm geht per E-Mail an zwei Personen auf Betreiberseite. Die Alarmierung ist Teil der Infrastruktur-Beschreibung und mit einem Testalarm erprobt. Geplante Wartung kündigt die Plattform als Hinweis über der Anwendung an.
Was mit dem Produktivstart kommt
- dieselbe Wiederherstellungsübung in der Produktivumgebung – erst danach wird aus der gemessenen Zeit eine Zahl, über die man reden kann
- ein Notfallhandbuch mit Rollen, Wegen und Fristen – und darauf aufbauend die vertraglichen Zusagen zur Information bei Vorfällen. (Die Support-Reaktionszeiten stehen unter Betrieb und Standorte; sie gelten für Anfragen, nicht für Störungsmeldungen.)
Wenn OpexGuard selbst ausfällt
Die Frage gehört in jeden Fragebogen, und wir beantworten sie: Sie erhalten Ihre Daten jederzeit: Ihr Mandanten-Admin lädt selbst einen Gesamtexport Ihrer Organisation herunter – ein ZIP mit jeder Liste als CSV, jedem Dokument mit allen Versionen und dem Änderungsprotokoll samt Archiv als JSON, dazu ein Manifest mit der Prüfsumme jeder Datei. Die Plattform lässt sich als dedizierte Instanz oder On-Premises betreiben (siehe Betrieb und Standorte); damit hängt Ihr After-Sales nicht an unserem Rechenzentrum. Frist und Ablauf der Datenrückgabe nach Vertragsende regelt der Vertrag zur Auftragsverarbeitung.