Zum Hauptinhalt springen

Verfügbarkeit & Wiederherstellung

Meetings warten nicht, und der Dienst, der sie dokumentiert, sollte es auch nicht tun. Sally ist so gebaut, dass alltägliche Störungen klein bleiben, Notfälle wiederherstellbar sind und Kundendaten einen schlechten Tag überleben. Die Vorsorge orientiert sich an ISO 22301 und BSI 200-4 und gilt für die Produktionsumgebung sowie die in AVV Anlage 3 genannten Subunternehmer.

Datenstandort
Nur Deutschland
Voll-Backup
Mind. täglich
Point-in-Time Restore
Ja, log-basiert
Wiederherstellungstests
Mind. jährlich

Redundanz auf Infrastruktur-Ebene​

✓
Hardware-Redundanz an der Datenbank
RAID-Speicher und ECC-Arbeitsspeicher verhindern, dass Einzelplatten- oder Bit-Fehler den Dienst stören.
✓
Datenbank-Cluster mit automatischem Failover
Ein replizierter Cluster hält einen warmen Standby bereit. Fällt der Primary aus, springt der Standby automatisch ein.
✓
Lastverteilter, zustandsloser Anwendungs-Tier
Zwei Front-Server hinter einem Load Balancer bedienen die API. Rollierendes Deployment bringt neue Versionen unterbrechungsfrei aus.
✓
Getrennte Backup-Storage in Deutschland
Backups liegen auf einer räumlich getrennten Storage-Instanz in Deutschland und sind mit AES-256 verschlüsselt, die Schlüssel bleiben bei Aliru.

Backups und Point-in-Time-Recovery​

  • Mindestens tägliches Voll-Backup, ergänzt um ein fortlaufendes Transaktionslog-Archiv, das Wiederherstellung auf nahezu jeden Zeitpunkt erlaubt.
  • Restore-Verfahren sind definiert für jeden kritischen Datensatz. Die Priorisierung folgt Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit.
  • Backups verlassen Deutschland nicht. Primärstandort und Backup-Standort liegen beide in der Bundesrepublik.
  • AES-256 im Ruhezustand. Die Regeln aus der Seite zur Schlüsselverwaltung gelten auch hier: Der Infrastrukturanbieter kann Backups nicht entschlüsseln.

Erkennung, Eskalation und Wiederherstellung​

Vorfälle folgen einer dreistufigen Eskalation:

✓
Stufe 1: Störung (begrenzter Impact)
Wird vom Incident Lead im Bereitschaftsdienst behandelt. Ohne Kundenbenachrichtigung, sofern kein Datenschutz betroffen ist.
✓
Stufe 2: Ernster Vorfall (Teilausfall)
BCM-Koordination und Datenschutzbeauftragter werden einbezogen. Betroffene Kunden werden informiert.
✓
Stufe 3: Notfall (Kernservice betroffen oder RTO/RPO gefährdet)
Krisensteuerung aktiviert den DR-Pfad. Bei möglicher Datenschutzverletzung informieren wir Kunden binnen 24 Stunden (AVV § 9).

Das Wiederherstellungs-Playbook folgt immer demselben Muster: eindämmen, Ursache klären, aus dem passenden Backup restaurieren, Integrität vor Freigabe verifizieren, Kapazität stufenweise hochfahren mit engem Monitoring, dann Lessons Learned dokumentieren und die TOMs anpassen.

Tests​

  • Wiederherstellungstests mindestens jährlich. Ein Backup ist erst dann ein Backup, wenn es getestet wurde.
  • Failover-Simulationen halbjährlich oder quartalsweise. Datenbank-Cluster und Anwendungs-Tier werden regelmäßig geprüft.
  • Wirksamkeitsprüfung dokumentiert. Ergebnisse fließen in TOMs und Programm zurück.

Kommunikation bei einer Datenschutzverletzung​

Wenn eine Verletzung des Schutzes personenbezogener Daten möglich ist, informiert Aliru den Kunden unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntnis. Die Meldung enthält: Art und Umfang, betroffene Datenkategorien und (soweit bekannt) Personenzahl, vermutete Ursachen, ergriffene und geplante Maßnahmen und gegebenenfalls eine Empfehlung zur Betroffenen-Information. Die Meldung an die Aufsichtsbehörde nach Art. 33 DSGVO liegt beim Kunden als Verantwortlichem. Aliru unterstützt mit den notwendigen Informationen.

Was beim Kunden liegt​

  • Speicherfristen konfigurieren, damit im Ernstfall nur Daten wiederhergestellt werden müssen, die wirklich noch gebraucht werden.
  • Downstream-Integrationen (Webhooks, CRM-Sync) selbst testen, damit ein Sally-Restore keine veralteten Einträge in eure Systeme spielt.
  • Verdächtige Vorfälle schnell melden. Je früher wir wissen, desto mehr Wiederherstellungsfenster bleibt.

Passende Seiten​