Der Digital Operational Resilience Act, kurz DORA, ist eine EU-Verordnung für den Finanzsektor. Sie verpflichtet Banken, Versicherungen, Wertpapierfirmen und andere Finanzunternehmen dazu, ICT-Risiken strukturiert zu steuern. Außerdem sollen sie besser darauf vorbereitet sein, ICT-bezogene Störungen zu überstehen, darauf zu reagieren und sich davon zu erholen.
DORA-Konzept für Backup und Recovery bei Finanzinstituten mit Bank, Schutzschild, Servern und Cloud-Speicherments.
DORA betrifft auch die Zusammenarbeit zwischen Finanzinstituten und ICT-Dienstleistern. Verträge, Service Level, Verantwortlichkeiten, Dokumentation, Incident Handling und Exit-Optionen werden Teil der operationellen Resilienz. Für Backup und Recovery ist das direkt relevant. Eine Bank braucht mehr als eine Backup-Richtlinie auf dem Papier. Sie braucht eine resiliente Backup-Lösung, klare Recovery-Prozesse und Servicevereinbarungen, die zu den operativen Anforderungen passen.
Während eines Incidents wird die Frage viel einfacher: Kann das Institut die Daten und Systeme wiederherstellen, die es braucht, und zwar innerhalb der geforderten Zeit?
Backup ist nicht das eigentliche Ziel. Recovery ist es.
Dieser Artikel zeigt, worauf Banken und andere Finanzinstitute achten sollten, wenn sie Backup und Recovery unter DORA organisieren. Dazu gehören sensible Daten, RTO- und RPO-Ziele, Restore-Tests, Dokumentation, Outsourcing-Aspekte, SLA-bezogene Fragen und die Rolle einer resilienten Backup-Lösung.
Daten müssen verfügbar, korrekt und wiederherstellbar bleiben
Banken arbeiten mit Daten, die sensibel, geschäftskritisch oder beides sind. Kundendaten. Kontoinformationen. Zahlungsdaten. Transaktionsdaten. Reporting-Daten. Interne Dokumente. Systemdaten.
Wenn diese Daten verloren gehen, verschlüsselt, beschädigt oder nicht verfügbar sind, bleibt die Auswirkung nicht in der IT. Sie kann den Kundenzugang, Zahlungsprozesse, regulatorisches Reporting, interne Abläufe und Vertrauen betreffen.
Ein erfolgreicher Backup-Job ist nur ein Teil des Prozesses. Der eigentliche Test kommt später.
Können die Daten wiederhergestellt werden?
Kann das richtige System zuerst wiederhergestellt werden?
Kann das Team nachweisen, dass der Prozess funktioniert?
Genau dort wird die Qualität des Backups sichtbar.
Recovery-Zeit ist nicht nur eine Zahl
Nicht jedes Banksystem hat dieselbe Recovery-Priorität. Ein zahlungsrelevanter Dienst, eine Anwendung für Kunden, ein Archiv und ein Testsystem haben nicht dieselbe Rolle im Tagesgeschäft.
Deshalb sollten Recovery-Ziele pro System, Service oder Datenkategorie definiert werden.
RTO beschreibt, wie schnell ein System wiederhergestellt werden soll. RPO beschreibt, wie viel Datenverlust akzeptabel ist. Diese Werte sollten zur echten Backup-Architektur, zum Storage-Design, zum Restore-Ablauf und zum verfügbaren Team passen.
Ein einfaches Beispiel.
Ein kritisches System hat ein kurzes RTO. Der Restore-Prozess ist aber manuell, langsam und wird selten getestet. Auf dem Papier sieht das Ziel gut aus. In der Praxis ist es fragil.
Was macht Backup und Recovery resilient?
Ein resilienter Backup-Prozess ist mehr als eine Liste geplanter Jobs.
Er umfasst klare Entscheidungen darüber, was geschützt wird, wie oft Backups erstellt werden, wo Backup-Daten gespeichert werden, wer darauf zugreifen darf und wie Restore getestet wird.
Mehrere Punkte sind in der Praxis wichtig:
- Backup-Systeme sollten, wo möglich, von der Produktion getrennt und, wo sinnvoll, air-gapped sein
- Restore-Prozesse sollten regelmäßig getestet werden
- Backup-Speicher sollte zum Risikoprofil passen
- fehlgeschlagene Jobs und Warnungen sollten überwacht werden
- Berichte und Logs sollten für Prüfungen verfügbar sein
- Verantwortlichkeiten sollten klar sein
Ohne klare Verantwortung gibt es keinen zuverlässigen Prozess.
Das klingt einfach, aber genau hier werden Backup-Strategien oft schwach. Die Technologie funktioniert vielleicht, aber niemand prüft fehlgeschlagene Jobs. Restore-Tests gibt es, aber nur für unkritische Systeme. Storage ist vorhanden, aber nicht ausreichend von der Produktion getrennt.
Was Procurement-Teams prüfen sollten
Für Banken ist die Auswahl einer Backup- und Recovery-Lösung nicht nur eine technische Entscheidung. Einkauf, ICT-Risikomanagement, Compliance, Security und Operations können alle beteiligt sein.
Eine sinnvolle Bewertung sollte sowohl das Produkt als auch das Betriebsmodell darum herum betrachten.
Wichtige Fragen sind:
- Welche Systeme, Plattformen und Workloads werden unterstützt?
- Sind physische Server, virtuelle Maschinen und Datenbanken abgedeckt?
- Wie werden Restore-Prozesse umgesetzt?
- Können Restore-Tests dokumentiert werden?
- Welche Berichte und Logs sind verfügbar?
- Kann Backup-Speicher von der Produktion getrennt werden?
- Wie werden Verschlüsselung, Zugriffskontrolle und sichere Kommunikation umgesetzt?
- Welches Supportmodell gibt es für den produktiven Einsatz?
- Entsteht durch die Lösung ein starker Vendor Lock-in?
- Können Backup-Daten weiterhin wiederhergestellt werden, wenn die Organisation später die Backup-Software wechselt?
- Wie viel Aufwand wäre nötig, um zu einer anderen Backup-Lösung zu wechseln?
- Passt die Lösung in bestehende ICT-Risiko- und Outsourcing-Prozesse?
Diese Fragen helfen, ein häufiges Problem zu vermeiden: Ein Backup-Tool sieht im Einkauf passend aus, wird später aber schwer zu betreiben, zu testen oder zu dokumentieren.
Wo Bareos Banken unterstützen kann
Bareos kann DORA-bezogene Backup- und Recovery-Prozesse als flexible quelloffene Backup-Plattform für heterogene IT-Umgebungen unterstützen.
Viele Banken betreiben keine einheitliche, saubere Infrastruktur. Sie nutzen eine Mischung aus Systemen: Linux, Windows, virtuelle Maschinen, Datenbanken, Storage-Systeme und ältere Komponenten, die weiterhin wichtig sind. Eine Backup-Lösung sollte mit dieser Realität umgehen können.
Bareos unterstützt physische Systeme, virtuelle Umgebungen, Datenbanken und verschiedene Storage-Ziele. Es kann mit Disk, Tape und Object Storage genutzt werden. Dadurch haben Organisationen Spielraum, Backup-Strategien zu entwickeln, die zu ihrer Infrastruktur, ihren Recovery-Prioritäten und ihren Aufbewahrungsanforderungen passen.
Für Procurement-Teams ist Bareos auch relevant, weil es quelloffene Software mit abonnementbasiertem Zugriff auf gepflegte Pakete, Enterprise-Plugins und professionellen Support kombiniert. Das kann in produktiven Umgebungen wichtig sein, wenn technische Kontrolle, Wartbarkeit, Dokumentation und Support zählen.
Mit klaren Verantwortlichkeiten, Service Levels, Dokumentation und regelmäßigen Restore-Tests kann ein Backup- und Recovery-Prozess auf Basis von Bareos die DORA-Compliance und interne ICT-Risikoanforderungen einer Bank unterstützen.
Bareos ersetzt jedoch keine DORA-Governance, kein ICT-Risikomanagement, kein Outsourcing-Management und keine internen Prozesse. Diese Verantwortung bleibt beim Finanzinstitut.
Bareos kann aber die technische Backup- und Recovery-Schicht bereitstellen, die dokumentierte, getestete und kontrollierte Recovery-Prozesse unterstützt.
Lock-in in der Backup-Architektur vermeiden
Backup-Daten sind langlebige Daten. Sie müssen möglicherweise über Jahre aufbewahrt werden. Und sie werden vielleicht genau im schlechtesten Moment gebraucht.
Deshalb ist Vendor Lock-in ein wichtiges Thema im Backup-Einkauf. Wenn Backup-Daten, Restore-Abläufe oder Storage-Entscheidungen zu stark von einer geschlossenen Umgebung abhängen, werden spätere Änderungen schwieriger.
Bareos folgt einem quelloffenen Ansatz und gibt Organisationen Kontrolle über ihre Backup-Infrastruktur und ihre Backup-Daten. Wenn eine Bank ihr Abonnement, ihr Supportmodell oder ihre Backup-Strategie ändert, werden die Daten nicht in einer geschlossenen Anbieterplattform eingeschlossen. Bestehende Backups bleiben unter der Kontrolle der Organisation und können weiterhin mit Bareos wiederhergestellt werden.
Das gibt Banken mehr Flexibilität bei der langfristigen Recovery-Planung, bei Änderungen von Servicevereinbarungen und bei der Vermeidung von Abhängigkeit von einem proprietären Anbieter.
Fazit
Unter DORA sollten Backup und Recovery als Teil der digitalen operationalen Resilienz betrachtet werden.
Für Banken sind die zentralen Fragen praktisch:
Can critical data be restored?
Können kritische Daten wiederhergestellt werden?
Sind Recovery-Ziele realistisch?
Werden Restore-Prozesse getestet?
Sind Nachweise verfügbar?
Ist die Backup-Architektur flexibel genug für zukünftige Anforderungen?
Ein resilienter Backup- und Recovery-Prozess hängt von Technologie ab, aber auch von Verantwortung, Dokumentation und regelmäßigen Tests.
Bareos kann diese Arbeit mit einer quelloffenen Backup- und Recovery-Plattform für gemischte IT-Umgebungen, flexiblen Storage-Zielen und professionellen Supportoptionen für den produktiven Einsatz unterstützen.
Backup schützt Daten.
Recovery schützt den Betrieb.