Mainframe-Backup und -Wiederherstellung: Moderne Strategien für ausfallsichere Unternehmenssysteme

Wie sieht die aktuelle Landschaft bei Mainframe-Backup und Disaster Recovery aus?

In einer IT-Umgebung – insbesondere in der Unternehmens-IT – bleibt die Mainframe-Sicherung eine der kritischsten und oft unterschätzten Disziplinen.

Finanztransaktionen, Versicherungsdaten und staatliche Programme sind zunehmend auf Mainframes angewiesen, was bedeutet, dass auch die Risiken von Systemausfällen so hoch sind wie nie zuvor. Eine Mainframe-Backup-Lösung muss Anforderungen erfüllen können, für die ein typisches verteiltes Backup-System nie ausgelegt war.

Warum erfordern Mainframes nach wie vor spezielle Backup- und Wiederherstellungsansätze?

Ein Mainframe ist nicht einfach nur ein überdimensionierter Server. Seine Architektur basiert auf den Konzepten der kontinuierlichen Verfügbarkeit, des massiven E/A-Durchsatzes und der Workload-Trennung – Faktoren, die das Design und die Durchführung von Backups grundlegend bestimmen.

Eine z/OS-Umgebung, die Tausende von Transaktionen pro Sekunde verwaltet, kann nicht dieselben Backup-Fenster, dieselben Konsistenzmodelle und dieselben Wiederherstellungsverfahren zulassen wie Linux-Dateiserver.

Mainframe-Backup-Systeme müssen eine Reihe von Konstrukten bewältigen, die für die Plattform einzigartig sind und nirgendwo sonst existieren – VSAM-Datensätze, z/OS-Kataloge, Coupling-Facility-Strukturen und Sysplex-Umgebungen –, die alle ihre eigenen Mechanismen erfordern. Das Erstellen eines Backups eines VSAM-Clusters unterscheidet sich erheblich vom Erstellen eines Backups einer Verzeichnisstruktur, während die Wiederherstellung eines Sysplex in einen konsistenten Zustand eine Koordination erfordert, die weit über die Fähigkeiten generischer Backup-Tools hinausgeht.

Auch die Skalierbarkeit ist ein Thema für sich. Mainframes verwalten regelmäßig Datenmengen im Petabyte-Bereich, wobei strenge SLA-Anforderungen bestehen, die verlangen, dass der Backup-Prozess parallel zum Produktionsbetrieb läuft, ohne dass dies spürbare Auswirkungen hat. Allein diese Einschränkung schließt eine große Anzahl von Standardlösungen aus.

Was sind die häufigsten Bedrohungen und Ausfallarten in Mainframe-Umgebungen?

Obwohl Mainframes von ihrer Konzeption her äußerst zuverlässig sind, sind sie nicht unbesiegbar. Es gibt zahlreiche Arten von Ausfällen, die eine Mainframe-Umgebung gefährden können, und eine geeignete Mainframe-Backup-Strategie muss sie alle berücksichtigen:

• Hardwareausfall – Verschlechterung des Speichersubsystems, Kanalausfälle oder Prozessorfehler, die Daten beschädigen oder unzugänglich machen können, selbst ohne vollständigen Systemausfall
• Menschliches Versagen – Versehentliches Löschen von Datensätzen, falsch konfigurierte JCL-Jobs oder fehlerhafte Katalogaktualisierungen, die einen erheblichen Anteil der tatsächlichen Wiederherstellungsvorgänge ausmachen
• Software- und Anwendungsfehler – Fehler in der Batch-Verarbeitungslogik oder in der Middleware, die falsche Daten schreiben, was möglicherweise erst dann auffällt, wenn die Datensätze bereits weiterverarbeitet wurden
• Ransomware und böswillige Angriffe – Ein zunehmend relevanter Bedrohungsvektor, der im folgenden Abschnitt ausführlich behandelt wird
• Katastrophen auf Standortebene – Stromausfall, Überschwemmung oder Ausfall der physischen Infrastruktur, der ein gesamtes Rechenzentrum betrifft

Keine einzelne Bedrohung ist gegenüber anderen von vorrangiger Bedeutung. Ein Hardware-Failover reicht nicht aus, wenn logisch beschädigte Daten nicht behandelt werden, und umgekehrt, wenn es um die Festlegung der Mainframe-Backup-Strategie geht.

Wie verändern moderne Geschäftsanforderungen die Erwartungen an Backup und DR?

Auch die Definition von „wiederherstellbar“ hat sich im Laufe der Jahre erheblich gewandelt.

Ein RTO-Ziel von 4 Stunden mag vor einem Jahrzehnt für viele Workloads noch angemessen gewesen sein. Heutige Business-Continuity-Teams streben für kritische Anwendungen ein RTO von null (oder nahezu null) an, angetrieben durch den digitalen Handel, Echtzeit-Zahlungsnetzwerke und Vorschriften, die erhebliche Ausfälle als Verstoß gegen regulatorische Compliance statt als betriebliche Unannehmlichkeit behandeln.

Viele dieser Erwartungen sind mittlerweile in regulatorischen Rahmenwerken festgeschrieben. Im Rahmen von Vorschriften wie DORA und PCI DSS sind Unternehmen nun verpflichtet, Wiederherstellungsziele formal zu definieren und regelmäßig zu testen. Das Versäumnis, diese Verpflichtungen festzulegen oder zu erfüllen, wird als Compliance-Verstoß behandelt und entsprechend geahndet.

Für Unternehmen, deren Geschäft auf Mainframes basiert, macht diese regulatorische Dimension die Planung der Notfallwiederherstellung (Disaster Recovery, DR) zu einer Aufgabe der Unternehmensführung und nicht nur zu einer technischen Angelegenheit.

Warum entwickeln sich Mainframe-Backup-Strategien im Zeitalter der Cyberbedrohungen weiter?

Moderne Cyberbedrohungen haben die Anforderungen an Mainframe-Backups verändert. Mainframe-Umgebungen stützten sich lange Zeit auf speziell entwickelte Resilienzfunktionen – Spiegelung, Point-in-Time-Kopien und mehrschichtige Redundanz –, die gegen die Bedrohungsszenarien, für die sie konzipiert waren, äußerst wirksam waren: Hardwareausfälle, menschliches Versagen und Katastrophen auf Standortebene.

Leider hat das Aufkommen komplexer Ransomware- und Lieferkettenangriffe eine neue Art von Problemen mit sich gebracht, bei denen auch die Backups ins Visier genommen werden. Das Auftauchen von Ransomware-Gruppen wie Conti – deren dokumentierte Angriffsstrategien die Identifizierung und Zerstörung von Backups als primäres Ziel vor der Verschlüsselung aufführten – führte ein Bedrohungsmodell ein, für das Unternehmens-Backup-Strategien nicht ausgelegt waren.

Wie greift Ransomware Legacy- und Mainframe-Umgebungen an?

Die Annahme, dass Mainframes aufgrund ihrer Architektur von Natur aus vor Ransomware geschützt sind, war in der Vergangenheit weit verbreitet. Diese Annahme wird jedoch zunehmend in Frage gestellt, da Mainframe-Umgebungen immer stärker in offene Systeme und verteilte Infrastrukturen integriert werden.

Moderne Ransomware-Täter gehen berechnend und methodisch vor; sie scannen und kartieren die Infrastruktur, bevor sie eine Schadfunktion aktivieren, und suchen gezielt nach Backup-Repositorys und -Katalogen, um alle Wiederherstellungsmechanismen zu deaktivieren, bevor sie den Verschlüsselungsprozess einleiten.

Mainframe-Umgebungen bergen aufgrund ihrer Integrationspunkte ein besonderes Risiko. z/OS-Systeme kommunizieren ständig mit verteilten Netzwerken, Cloud-Speicherebenen und Middleware für offene Systeme (von denen jede als Einfallstor dienen kann). Da Mainframe-Umgebungen immer stärker in verteilte Infrastrukturen integriert werden, vergrößert sich die Angriffsfläche: Eine Kompromittierung eines verbundenen Systems könnte in ausreichend flachen Netzwerkarchitekturen einen Weg zu gemeinsam genutzten Speicherebenen eröffnen, auf denen Mainframe-Backup-Datensätze liegen.

In vielen Konfigurationen befinden sich Mainframe-Backup-Kataloge und Steuerungsdatensätze auf derselben Speicherstruktur wie die Daten, die sie schützen – was bedeutet, dass ein Angreifer in günstiger Position oder ein Fehler, der sich über den gemeinsam genutzten Speicher ausbreitet, beide gleichzeitig beeinträchtigen könnte. Es bedarf keiner großen Überlegung, um zu dem Schluss zu kommen, dass ein Backup-Katalog, der sich auf derselben Speicherstruktur wie die Daten selbst befindet, bei demselben Vorfall beschädigt und zerstört werden könnte.

Genau diese Situation muss nun von modernen Mainframe-Backup-Architekturen berücksichtigt werden.

Welche Rolle spielen unveränderliche und luftisolierte Backups für Mainframes?

Dies sind die beiden vorherrschenden architektonischen Ansätze zur Bekämpfung von Ransomware: Unveränderlichkeit und Air-Gapping. Obwohl dies zwei der vorherrschenden Konzepte sind, die im Zusammenhang mit der Bekämpfung von Ransomware diskutiert werden, funktionieren sie tatsächlich auf unterschiedliche Weise.

Die beiden Ansätze schließen sich nicht gegenseitig aus. Eine gut durchdachte Mainframe-Backup-Strategie kann beides umfassen – eine unveränderliche Kopie, um bei logischen Angriffsszenarien eine Wiederherstellung innerhalb kürzester Zeit zu ermöglichen, und eine Air-Gapped-Kopie für die ultimative Wiederherstellung in Fällen, in denen die Unveränderlichkeit auf Speicherebene ebenfalls verletzt wurde (durch die Nutzung privilegierter Administratorkonten oder Angriffe, die direkt auf die Speicherebene abzielen).

Wo die Unveränderlichkeit auf Speicherebene nicht bereits nativ bereitgestellt wird – wie dies beispielsweise bei IBM DS8000 Safeguarded Copy und dem Z Cyber Vault-Framework der Fall ist –, erfordert die Implementierung unter z/OS eine sorgfältige Integration mit bestehenden Backup-Tools, um sicherzustellen, dass Unveränderlichkeitsrichtlinien auf der Speicherebene und nicht nur auf der Anwendungsebene (wo sie potenziell umgangen werden können) durchgesetzt werden.

Wie lassen sich Zero-Trust-Prinzipien auf Mainframe-Backup-Architekturen anwenden?

z/OS hat viele der Prinzipien, die heute mit der Zero-Trust-Architektur assoziiert werden – obligatorische Zugriffskontrollen, strikte Aufgabentrennung und umfassende Prüfpfade –, bereits lange vor dem Aufkommen des Begriffs im Mainstream-Sicherheitsdiskurs umgesetzt. Speziell für Mainframe-Backups geht es daher weniger um die Einführung von Zero-Trust-Konzepten als vielmehr darum, sicherzustellen, dass RACF- oder ACF2-Richtlinien so konfiguriert sind, dass diese Prinzipien konsequent auf die Backup-Umgebung angewendet werden, die manchmal als risikoärmer als die Produktionsumgebung angesehen wird und in der sich im Laufe der Zeit übermäßige Berechtigungen ansammeln können.

Im Zusammenhang mit Mainframe-Backups bedeutet Zero-Trust, dass bei keinem Gerät, Benutzer oder Prozess (selbst bei Backup-Administratoren) davon ausgegangen wird, dass dieser impliziten Zugriff oder die Fähigkeit zur Verwaltung von Backup-Daten besitzt. In der Praxis würde dies eine strikte Aufgabentrennung, eine Zwei-Faktor-Authentifizierung für die Backup-Verwaltungskonsole sowie strenge rollenbasierte Berechtigungen bedeuten, die festlegen, wer Backup-Jobs löschen, ändern oder deaktivieren darf.

Unter z/OS bedeutet dies die Gestaltung von RACF- oder ACF2-Richtlinien, die den Zugriff auf den Backup-Katalog explizit einschränken, kombiniert mit Out-of-Band-Warnmeldungen für jede administrative Aktion, die Aufbewahrungseinstellungen oder Backup-Zeitpläne betrifft. Die Mainframe-Backup-Umgebung sollte selbst als sicherheitskritisches System behandelt werden, sodass sowohl die Zugriffsprüfungszyklen als auch die Prüfpfade denselben Standards entsprechen, die für Produktionsdaten gelten.

Welche Wiederherstellungsziele sollten die Mainframe-Backup-Strategie bestimmen?

Die Wiederherstellungsziele sollten nicht festgelegt und dann ignoriert werden, da sie auf vertraglicher Basis die Grundlage der gesamten Mainframe-Backup-Architektur bilden. Alle Entscheidungen darüber hinaus (bezüglich der Häufigkeit von Backups, der Replikationstopologie und der Wahl der Speicherebenen) müssen sich aus den festgelegten RTOs und RPOs ableiten. Unternehmen, die diesen Schritt überspringen, entdecken ihre Lücken in der Regel erst bei einem tatsächlichen Ausfall – dem ungünstigsten Zeitpunkt dafür.

Was ist der Unterschied zwischen RTO und RPO bei Mainframe-Workloads?

RTO und RPO sind bekannte DR-Konzepte, doch ihre Auswirkungen im Mainframe-Kontext sind erheblich und können eine ganz andere Bedeutung haben als dieselben Kennzahlen in verteilten Systemen.

RPO (Recovery Point Objective), der maximal akzeptable Zeitrahmen für Datenverluste, ist bei Mainframes aufgrund der Beziehungen zwischen Transaktionen besonders schwierig. Ein Mainframe, der Zahlungsvorgänge mit hohem Volumen verarbeitet, kann leicht Millionen von Datensätzen pro Stunde aufweisen, die über eine Reihe von gekoppelten Datensätzen verteilt sind.

RPO ist nicht nur ein Snapshot, der nach einem festgelegten Zeitraum wiederholt aufgenommen wird – es beinhaltet die Erfassung aller gekoppelten Datensätze, Kataloge und Kopplungsstrukturen zu einem bestimmten Zeitpunkt.

RTO (Recovery Time Objective), die maximal für Wiederherstellungsvorgänge vorgesehene Zeit, bringt bei Mainframes eigene Komplexitäten mit sich. Die Wiederherstellung einer z/OS-Umgebung ist nicht gleichbedeutend mit dem Starten einer virtuellen Maschine aus einem Snapshot.

Meistens erkennen Unternehmen ihren tatsächlichen RTO-Wert erst, wenn sie einen Wiederherstellungstest durchführen – und dann kann niemand mehr die Augen vor der Lücke zwischen dem angenommenen und dem tatsächlichen Wiederherstellungszeitraum verschließen.

Beide Ziele müssen pro Workload und nicht pro System definiert werden. Ein einzelner Mainframe kann Anwendungen mit sehr unterschiedlicher Toleranz gegenüber Datenverlust und Ausfallzeiten hosten, und genau dafür ist die Kritikalitätsstufung konzipiert.

Wie sollten Kritikalitätsstufen die Backup-Häufigkeit und -Aufbewahrungsdauer beeinflussen?

Nicht alle auf einem Mainframe ausgeführten Workloads sollten – und können es sich leisten – auf dieselbe Weise geschützt zu werden. Die Einstufung nach Kritikalität ist der Prozess, bei dem die geschäftliche Kritikalität in eine praktische Backup-Richtlinie umgesetzt wird. Dabei werden angemessene Ressourcen für Workloads zugewiesen, bei denen das längste Wiederherstellungsfenster zu erwarten ist, während eine Überdimensionierung des Schutzes für Workloads vermieden wird, bei denen ein größeres Wiederherstellungsfenster toleriert werden kann.

Ein praktisches Tiering-Modell umfasst in der Regel drei Ebenen:

Die Zuordnung zu den Tiers sollte sich eher an der Analyse der geschäftlichen Auswirkungen als an technischer Zweckmäßigkeit orientieren und mindestens einmal jährlich überprüft werden – die Kritikalität von Workloads verschiebt sich mit der Entwicklung der geschäftlichen Prioritäten, und ein Datensatz, der im letzten Jahr noch Tier 2 war, kann heute bereits als Tier 1 gelten.

Wie wirken sich Compliance und SLAs auf Wiederherstellungsziele aus?

Wiederherstellungsrahmenwerke schaffen nicht nur Anreize für eine solide Wiederherstellungsplanung, sondern viele verlangen mittlerweile auch konkrete, überprüfbare Ergebnisse.

• Die DORA-Verordnung schreibt vor, dass Finanzinstitute Wiederherstellungsfähigkeiten anhand vordefinierter Kennzahlen definieren und testen müssen
• PCI DSS legt spezifische Anforderungen an die Verfügbarkeit und Integrität von Systemen fest, die auf Karteninhaberdaten zugreifen
• Die HIPAA-Verfügbarkeitsregel legt Verpflichtungen zur Aufrechterhaltung des Zugriffs auf PHI unter bestimmten Umständen fest

In der Praxis bedeutet dies, dass die Wiederherstellungsziele einer regulierten Workload nicht mehr allein von einer internen Ermessensentscheidung abhängen. Wann immer sich SLA- und regulatorische Anforderungen überschneiden, wird die strengste Anforderung gewählt. Daher muss die Mainframe-Backup-Lösung so konzipiert, getestet und dokumentiert werden, dass sie sowohl den Anforderungen externer Auditoren als auch den internen Erwartungen gerecht wird.

Welche On-Site-Backup-Optionen gibt es für Mainframes?

Die Mainframe-Sicherung vor Ort stützt sich auf drei unterschiedliche Technologiekategorien:

• Bandbasierte Sicherung (physisch und virtuell)
• Disk-to-Disk-Backup
• Point-in-Time-Kopien

Jede dieser Optionen erfüllt unterschiedliche Wiederherstellungsanforderungen und betriebliche Vorgaben. Das Wissen darüber, wo jeder Ansatz am besten passt, ist die Grundlage jeder gut durchdachten Mainframe-Backup-Strategie.

Wie funktionieren DASD-basierte Backups (Bandemulation, virtuelle Bänder) auf Mainframes?

Backups über Direct Access Storage Devices sind seit vielen Jahren Teil von Mainframe-Umgebungen, doch die eigentliche Technologie hat sich im Laufe der Zeit erheblich verändert.

Virtuelle Bandbibliotheken (VTLs) werden in Mainframe-Umgebungen häufig als Leistungsschicht vor physischen Bändern eingesetzt. Sie stellen eine Bandschnittstelle für z/OS bereit, während die Daten zunächst auf Festplattenspeicher geschrieben werden, bevor sie zur längerfristigen Aufbewahrung auf physische Bänder migriert werden. Aus Sicht der Mainframe-Software verhält sich eine VTL wie ein physisches Bandgerät, schreibt die Daten jedoch auf Festplattenspeicher.

Dadurch kann ein JCL oder ein Automatisierungsskript, das für Backups auf physische Bänder geschrieben wurde, mit geringen bis gar keinen Änderungen für VTL-Backups wiederverwendet werden, was zu einer besseren Leistung führt, ohne dass die gesamte Backup-Infrastruktur geändert werden muss.

Physische Bänder sind bis heute in den meisten Mainframe-Umgebungen das primäre Backup-Medium, wobei VTLs als leistungsoptimierte Zwischenstufe dienen, die bandbasierte Arbeitsabläufe beibehält und gleichzeitig den mechanischen Aufwand reduziert sowie den Backup-Durchsatz verbessert.

Wann sollten Disk-to-Disk-Backups gegenüber bandbasierten Lösungen bevorzugt werden?

Die Entscheidung, ob Sie für Ihre Mainframes Disk-to-Disk- oder Band-Backups implementieren, ist nicht nur technischer Natur, sondern wird oft durch eine Kombination aus Wiederherstellungsanforderungen, geschäftlichen Gegebenheiten und wirtschaftlichen Überlegungen bestimmt.

Disk-to-Disk-Backups sind die bessere Wahl, wenn:

• Die Wiederherstellungsgeschwindigkeit Priorität hat – diskbasierte Wiederherstellungen sind in einem Bruchteil der Zeit abgeschlossen, die zum Auffinden, Einbinden und Lesen eines Bandvolumes benötigt wird, was sich direkt auf die Erreichung der RTO auswirkt
• Die Backup-Fenster eng sind – Disk-Ziele mit hohem Durchsatz können Backup-Daten schneller aufnehmen als Band, wodurch das Risiko verringert wird, dass Jobs ihr zugewiesenes Zeitfenster überschreiten
• Häufige Wiederherstellungstests erwartet werden – bandbasierte Wiederherstellungen verursachen einen betrieblichen Mehraufwand, der regelmäßige DR-Tests erschwert, während Festplattenziele Testwiederherstellungen zur Routine machen
• Eine granulare Wiederherstellung erforderlich ist – die Wiederherstellung eines einzelnen Datensatzes oder einer kleinen Anzahl von Datensätzen von der Festplatte ist wesentlich praktischer als das Durchsuchen von Bandvolumes, um bestimmte Daten zu finden

Bänder eignen sich nach wie vor für Anwendungen, bei denen Langzeitspeicherung, gesetzliche Archivierungspflichten oder die externe Archivierung die Kosten effektiv machen. Für Workloads mit strengen RTO-Anforderungen oder häufigen Wiederherstellungstests kann Disk-to-Disk jedoch als Ergänzung zur bandbasierten Primärsicherung einen bedeutenden betrieblichen Vorteil bieten.

Welche Rolle spielen Snapshot- und Point-in-Time-Technologien auf dem Mainframe?

Snapshots nehmen innerhalb der Mainframe-Backup-Landschaft eine ganz eigene Rolle ein; sie sind keine Alternative zum Backup, sondern eine Ergänzung zu bestehenden Backup-Funktionen. Sie erweisen sich vor allem dann als besonders wertvoll, wenn herkömmliche Einschränkungen hinsichtlich des Backup-Fensters oder Anforderungen an die Wiederherstellungsgranularität über die Möglichkeiten hinausgehen, die geplante Jobs allein bieten können.

Unter z/OS erstellen Point-in-Time-Kopiertechnologien eine sofortige abhängige Kopie eines Datensatzes oder Volumes, ohne den Produktions-I/O zu unterbrechen – wobei IBM FlashCopy die bekannteste Option auf dem Markt ist. Zu den wichtigsten Merkmalen, die bestimmen, wie diese Technologien in eine Mainframe-Backup-Strategie passen, gehören:

• Konsistenzanforderungen – Ein Snapshot eines einzelnen Volumes ist unkompliziert, doch die Erfassung eines konsistenten Point-in-Time-Images über mehrere miteinander verbundene Volumes hinweg in einer stark ausgelasteten OLTP-Umgebung erfordert sorgfältige Koordination, um zu vermeiden, dass Daten mitten in einer Transaktion erfasst werden
• Wiederherstellungsgranularität – Snapshots ermöglichen eine schnelle Wiederherstellung auf einen kürzlich bekannten fehlerfreien Zustand, werden jedoch in der Regel kürzer aufbewahrt als herkömmliche Backup-Kopien, wodurch sie als alleiniger Wiederherstellungsmechanismus ungeeignet sind
• Speicher-Overhead – Abhängige Kopien beanspruchen zusätzliche Speicherkapazität, und die Beziehung zwischen Quell- und Zielvolumes muss sorgfältig verwaltet werden, um Auswirkungen auf die Produktionsleistung zu vermeiden

Bei richtiger Verwendung dienen Snapshots als Schnellewiederherstellungsschicht in einem mehrstufigen Mainframe-Backup-Design, wo sie häufige, aktuelle Wiederherstellungsszenarien abdecken, während herkömmliche Backups die langfristige, externe Speicherung übernehmen.

Welche Offsite- und Remote-Disaster-Recovery-Architekturen stehen zur Verfügung?

In der Offsite-DR-Architektur sind Mainframe-Backup und Business-Continuity-Planung am stärksten miteinander verknüpft. Die spezifischen Entscheidungen in der Offsite-DR-Architektur – der Replikationsmodus, die Standorttopologie, die Vaulting-Strategie – beeinflussen nicht nur das Potenzial für eine Wiederherstellung auf Standortebene, sondern auch deren Geschwindigkeit und Vollständigkeit unter realen Bedingungen.

Wie wirkt sich die synchrone gegenüber der asynchronen Replikation auf die Wiederherstellbarkeit aus?

Der Replikationsmodus ist wahrscheinlich eine der wichtigsten architektonischen Entscheidungen für eine Mainframe-Disaster-Recovery-Konfiguration, da er tatsächlich die theoretische Mindestdatenmenge festlegt, deren Verlust sich Unternehmen in jedem Failover-Szenario leisten können.

In den meisten Fällen handelt es sich hierbei nicht um eine einfache, binäre Entscheidung. Viele Mainframe-Systeme nutzen zur Gewährleistung der Geschäftskontinuität eine synchrone Replikation an einen benachbarten sekundären Standort, gepaart mit einer asynchronen Replikation an einen weiter entfernten tertiären Standort für den Fall katastrophaler Ausfälle. Auf diese Weise können sie einen größeren RPO für die geografische Trennung des Backups akzeptieren, da eine synchrone Verbindung über große Entfernungen einfach nicht praktikabel wäre.

Was sind die Vor- und Nachteile von Active-Active- gegenüber Active-Passive-DR-Standorten?

Die Standorttopologie – also die Beziehung des sekundären Standorts zur Produktion im Normalbetrieb – bestimmt sowohl das Kostenprofil als auch das Wiederherstellungsverhalten der gesamten DR-Architektur.

Bei einer Aktiv-Aktiv-Konfiguration werden die Produktions-Workloads an beiden Standorten gleichzeitig ausgeführt. Die Workload-Verteilung erfolgt in diesem Fall über den Sysplex. Der Hauptvorteil dieser Architektur besteht darin, dass das Failover kein isoliertes Ereignis ist, da am DR-Standort bereits Kapazitäten vorhanden sind und der Übergang vom eingeschränkten zum vollen Betrieb deutlich kürzer ist als bei jedem Cold-Start-Szenario. Backups und Replikation für den Mainframe werden stets genutzt und liegen nicht brach, weshalb Ausfälle innerhalb der DR-Struktur während des normalen Betriebs auftreten und nicht erst bei einer tatsächlichen Katastrophe.

Hier stehen Kosten und Komplexität im Abwägungsprozess. Active-Active erfordert an beiden Standorten eine vollständige Infrastruktur auf Produktionsniveau mit kontinuierlichem Workload-Balancing und sorgfältigem Anwendungsdesign, um die verteilte Konsistenz bei Transaktionen zu gewährleisten. Vor diesem Hintergrund kann Active-Active für Unternehmen, deren Mainframe-Workloads eng miteinander integriert oder schwer zu partitionieren sind, mehr Risiken mit sich bringen, als es beseitigen kann.

In Active-Passive-Umgebungen wird ein Backup-Standort warm gehalten und inaktiv gelassen, was die Hardwarekosten erheblich senkt. Dies setzt voraus, dass die Mainframe-Backup-Lösungen für diesen Standort die passive Umgebung aktuell genug halten, um die RTO-Anforderungen zu erfüllen – eine Herausforderung, die zunimmt, je mehr sich der Aktualitätsgrad zwischen Primär- und Sekundärstandort auseinanderentwickelt. Unumgänglich bei Active-Passive ist die Tatsache, dass ein Failover eine tatsächliche Übergangsphase bedeutet und dass diese Phase regelmäßig getestet werden muss, um sicherzustellen, dass sie innerhalb akzeptabler Grenzen liegt.

Wann ist Remote-Tape-Vaulting oder cloudbasiertes Tape-Backup sinnvoll?

Bänder – ob physisch oder cloudbasiert – bleiben ein zentrales Element der Mainframe-Backup-Architektur und erfüllen Anforderungen, die festplattenbasierte Alternativen nicht immer erfüllen können, darunter die Anforderungen an Air-Gap und die physische Aufbewahrung von Medien, die in Rahmenwerken wie PCI DSS ausdrücklich gefordert werden. Bänder sind unter bestimmten Bedingungen weiterhin geeignet:

• Langfristige gesetzliche Aufbewahrungspflichten – wenn Vorschriften eine Datenaufbewahrung über Jahre oder Jahrzehnte vorschreiben und die Kosten für die Speicherung dieser Daten auf Festplatte oder in aktivem Cloud-Speicher unerschwinglich sind
• Air-Gap-Anforderungen – wenn Richtlinien oder Vorschriften eine Kopie der Backup-Daten verlangen, die physisch oder logisch von der gesamten netzwerkzugänglichen Infrastruktur getrennt ist
• Selten aufgerufene Archiv-Workloads – wenn die Wahrscheinlichkeit einer Wiederherstellung so gering ist, dass die Latenz beim Abruf ein akzeptabler Kompromiss für die Speicherkosten darstellt
• Ergänzender Schutz für aktive Backup-Ebenen – wenn Band als nachgelagerte Kopie von festplattenbasierten Backups dient und nicht als primärer Wiederherstellungsmechanismus

Was Tape-Vaulting nicht sein sollte, ist die primäre Mainframe-Backup-Lösung für Workloads mit einer bedeutenden RTO-Anforderung. Der operative Aufwand für das Auffinden, den Versand und das Einlegen physischer Medien – oder das Abrufen und Bereitstellen von Cloud-basierten Bändern – macht es strukturell ungeeignet für zeitkritische Wiederherstellungsszenarien.

Wie wirken sich Datenmobilität und plattformübergreifende Integration auf die Mainframe-Wiederherstellung aus?

Die Mainframe-Wiederherstellung erfolgt nicht isoliert. Die Unternehmensinfrastruktur ist heute sehr eng vernetzt; Mainframe-Transaktionsengines füllen verteilte Datenbanken, Open-Systems-Anwendungen rufen Mainframe-Daten ab und verarbeiten sie in Echtzeit, und API-Schichten integrieren Plattformen nahtlos und nahtlos – wodurch viele gegenseitige Abhängigkeiten entstehen, die bei der Planung der Notfallwiederherstellung oft übersehen werden.

Die Behandlung von Mainframe-Backup und -Wiederherstellung als eigenständigen Vorgang – die Wiederherstellung von Datensätzen, Katalogen und Subsystemen ohne Berücksichtigung der Konsistenz abhängiger verteilter Systeme – führt mit ziemlicher Sicherheit zu einem technisch wiederhergestellten Mainframe, mit dem der Rest der Geschäftsumgebung nicht sinnvoll interagieren kann.

Wie lassen sich Mainframe-Daten für die Notfallwiederherstellung in verteilte und offene Systeme integrieren?

In einer modernen Unternehmenslandschaft ist es ungewöhnlich, dass Mainframe-Workloads in ihren eigenen isolierten Umgebungen ausgeführt werden. Mainframe-Transaktions-Engines melden Daten an Feeds, die in nachgelagerte Analyseanwendungen einfließen, während z/OS-Transaktions-Engines an verteilte Datenbanken melden, die von webfähigen Anwendungen in Echtzeit genutzt werden.

Im Falle einer Mainframe-Wiederherstellung geht es nicht um die Fähigkeit, den Mainframe wiederherzustellen, sondern darum, ob das gesamte abhängige System parallel dazu wieder in einen konsistenten Betriebszustand versetzt werden kann. Mögliche Integrationstechniken, die dies unterstützen, reichen von API-gesteuerter Datenreplikation bis hin zu Speicher-Sharing-Architekturen, bei denen Mainframe und verteilte Systeme auf dieselben Datenpools zugreifen können.

Die richtige Wahl hängt maßgeblich von der akzeptablen Latenz, dem Datenvolumen und der Kritikalität der Konsistenzanforderungen zwischen den beiden Systemen ab. Entscheidend für den Mainframe-Backup-Prozess ist, dass diese Integrationspunkte explizit abgebildet und in die DR-Planung einbezogen werden, anstatt als Problem eines anderen behandelt zu werden.

Welche Herausforderungen ergeben sich bei der Synchronisierung von Mainframe- und Nicht-Mainframe-Workloads?

Bei der plattformübergreifenden Synchronisation scheitern heterogene DR-Pläne am häufigsten. Die technischen und betrieblichen Herausforderungen sind spezifisch genug, um besondere Aufmerksamkeit zu verdienen:

• Fehlausrichtung von Transaktionsgrenzen – Mainframe-Systeme verwalten Transaktionen in der Regel mit ACID-Garantien auf Datensatzebene, während verteilte Systeme möglicherweise andere Konsistenzmodelle verwenden, was es schwierig macht, einen einzigen Wiederherstellungspunkt zu definieren, der gleichzeitig für beide Umgebungen gültig ist
• Zeitliche Abhängigkeiten – Batch-Jobs, die Mainframe-Daten für die nachgelagerte Verarbeitung extrahieren, erzeugen implizite zeitliche Abhängigkeiten, die selten formell dokumentiert werden. Das bedeutet, dass eine Wiederherstellung, die den Mainframe auf einen Zeitpunkt vor dem letzten Batch-Lauf zurücksetzt, dazu führen kann, dass verteilte Systeme in Bezug auf die Datenaktualität dem Mainframe voraus sind
• Konsistenz von Katalog und Metadaten – Die Wiederherstellung von Mainframe-Datensätzen ohne entsprechende Aktualisierungen der verteilten Metadatenspeicher – oder umgekehrt – kann dazu führen, dass Anwendungen auf Daten verweisen, die nicht mehr existieren oder durch neuere Daten ersetzt wurden
• Unterschiedliche RTO- und RPO-Verpflichtungen – Mainframe- und verteilte Teams arbeiten häufig unter separaten SLAs, was zu Wiederherstellungsmaßnahmen führen kann, bei denen jede Plattform unabhängig wiederhergestellt wird, ohne die für Anwendungen, die beide Bereiche umfassen, erforderliche zeitliche Konsistenz zu koordinieren

Dies sind zudem keine Randfälle. Synchronisationsfehler könnten eine der Hauptursachen für eine Wiederherstellung sein, die technisch zwar erfolgreich ist, aber in Umgebungen, in denen Nicht-Mainframes auf dieselben Daten wie die Mainframes zugreifen oder operativ von den Mainframes abhängig sind, funktional versagt.

Wie verbessern heterogene Backup-Umgebungen die Ausfallsicherheit?

Einer der Hauptantriebe in der Unternehmens-IT ist die Standardisierung: eine Backup-Plattform, ein Toolset, ein Betriebsmodell. Mainframe-Umgebungen hingegen sind genau der Ort, an dem dieser Ansatz möglicherweise überhaupt nicht besser ist.

Eine heterogene Backup-Umgebung (in der Mainframe-native Backup-Lösungen neben Open-Systems-Plattformen mit definierten Integrationspunkten betrieben werden) kann die Ausfallsicherheit auf eine Weise verbessern, die ein Single-Vendor-Ansatz nicht immer bieten kann. Weder herstellerspezifische Sicherheitslücken noch Produktausfälle können sich auf die gesamte Backup-Infrastruktur ausbreiten. Ein natives Mainframe-Backup nutzt native Plattformkonzepte wie VSAM-Dateien, die z/OS-Kataloge und die Sysplex-Integrität, was Open-Systems-Produkte im Allgemeinen nicht leisten können oder nicht gut leisten, während Open-Systems-Produkte die verteilten Komponenten verwalten, für die sie konzipiert wurden.

Heterogenität ist nicht gleichbedeutend mit Fragmentierung. Es geht um beabsichtigte Spezialisierung mit bekannter Integration – nicht nur um das Nebeneinander mehrerer unabhängiger Tools, sondern um eine geplante Architektur, die die jeweiligen Stärken jedes Tools nutzt.

Wie lassen sich hybride und cloudintegrierte Backup-Modelle auf Mainframes anwenden?

Die Cloud-Integration hat sich von einer Randerscheinung zu einer gängigen architektonischen Wahl für Mainframe-Backups entwickelt. Ein solcher Wandel wird vor allem durch wirtschaftlichen Druck, Anforderungen an geografische Flexibilität und die Reifung von Cloud-Speicherebenen vorangetrieben, die nun von Anfang an darauf ausgelegt sind, die Größenordnung von Mainframe-Datenmengen zu bewältigen.

Man kann auch mit Fug und Recht sagen, dass sich die verfügbaren Optionen in diesem Bereich in der Praxis weitgehend auf das eigene Produktökosystem von IBM konzentrieren, da die z/OS-Speicherschnittstellen proprietär sind.

Welche Möglichkeiten gibt es für die Integration von Mainframe-Backups in den Public-Cloud-Speicher?

Es gibt eine Reihe von Möglichkeiten, wie Mainframe-Backup-Lösungen in die Public Cloud integriert werden können. Jeder Ansatz weist besondere Merkmale auf und eignet sich für unterschiedliche Arten von Wiederherstellungsanforderungen und Datenmengen. Die am weitesten verbreiteten Ansätze sind:

• Die Cloud als Ersatz für Bandlaufwerke – Backup-Daten werden auf Objektspeicherebenen wie AWS S3 oder Azure Blob geschrieben, wobei Mainframe-kompatible Schnittstellen oder Gateway-Appliances zum Einsatz kommen, die zwischen z/OS-Backup-Formaten und Cloud-Speicher-APIs übersetzen
• Cloud als sekundäres Backup-Ziel – On-Premises-Backup-Jobs werden als Downstream-Kopie in den Cloud-Speicher repliziert und bieten so Offsite-Schutz, ohne die primäre On-Site-Backup-Infrastruktur zu ersetzen
• Cloud-basierte virtuelle Bandbibliotheken – VTL-Lösungen mit nativen Cloud-Backends, die z/OS eine vertraute Bandschnittstelle bieten, während sie in skalierbaren Cloud-Objektspeicher schreiben
• Hybride Replikationsarchitekturen – Mainframe-Daten werden auf in der Cloud gehostete Mainframe-Instanzen oder kompatible Umgebungen repliziert, was eine cloudbasierte DR anstelle von reinem cloudbasiertem Speicher ermöglicht

Das gewählte Integrationsmuster bestimmt direkt, welche Wiederherstellungsszenarien in der Cloud-Ebene ermöglicht werden. Reine Speicherlösungen schützen vor Standortausfällen, beschleunigen jedoch nicht die Wiederherstellung, sodass Rechenressourcen innerhalb der Cloud anstelle von reinen Daten erforderlich sind.

Wie kann cloudbasierte DR-Orchestrierung für die Mainframe-Wiederherstellung genutzt werden?

Das Speichern von Sicherungskopien in der Cloud löst das Problem der Aufbewahrung. Um diese jedoch schnell wiederherzustellen, benötigen Sie eine Orchestrierung – vordefinierte Workflows, die die Abfolge von Aktionen koordinieren, die ab dem Zeitpunkt der Entscheidung für ein Failover bis zum tatsächlichen Laufen des Mainframe-Systems ablaufen.

Die cloudbasierte DR-Orchestrierung für Mainframe-Backup-Lösungen kann Folgendes umfassen:

• Automatische Auslösung des Failovers – Zustandsüberwachung, die einen Ausfall des Primärstandorts erkennt und Wiederherstellungsworkflows ohne manuelles Eingreifen initiiert
• Wiederherstellungssequenzierung – vordefinierte Runbooks, die IPL, Katalogwiederherstellung und Anwendungsneustart in der richtigen Abhängigkeitsreihenfolge ausführen
• Umgebungsbereitstellung – automatisiertes Hochfahren von in der Cloud gehosteten Rechen- und Speicherressourcen, die zum Empfang und zur Ausführung wiederhergestellter Workloads benötigt werden
• Testautomatisierung – geplante, unterbrechungsfreie DR-Tests, die Wiederherstellungsverfahren anhand aktueller Backup-Daten validieren, ohne den Produktionsbetrieb zu beeinträchtigen
• Rollback-Koordination – verwaltete Failback-Verfahren, die Workloads nach der Wiederherstellung des Primärstandorts dorthin zurückführen, ohne Datenverlust oder Konsistenzlücken

Der Reifegrad der verfügbaren Orchestrierungsfunktionen variiert je nach Anbieter erheblich. Auch unterstützen nicht alle Lösungen nativ das gesamte Spektrum der z/OS-spezifischen Wiederherstellungsschritte.

Welche Sicherheits- und Leistungsaspekte sind bei der Kombination von Mainframes mit Cloud-Backups zu berücksichtigen?

Die Auswirkungen einer Ausweitung der Mainframe-Sicherung auf die Cloud sind mit einer Reihe von Nuancen verbunden, da hier zwei völlig unterschiedliche Infrastrukturparadigmen aufeinandertreffen. Es empfiehlt sich, diese Vor- und Nachteile direkt miteinander zu vergleichen:

Weder Sicherheit noch Leistung dürfen in Mainframe-Cloud-Backup-Architekturen als Nebensache behandelt werden – denn eine Beeinträchtigung einer dieser beiden Komponenten würde den Wert der gesamten Integration sofort untergraben.

Welche Software und Tools unterstützen Mainframe-Backup und -Wiederherstellung?

Die Landschaft für Mainframe-Backup-Software ist relativ überschaubar, doch ihre Komplexität ist in Bezug auf die Gesamtkomplexität mit der von verteilten Backup-Lösungen vergleichbar.

Die Liste der verfügbaren Lösungen reicht von tief integrierten Z/OS-nativen Lösungen bis hin zu breiteren Unternehmensplattformen mit Mainframe-Konnektoren. Die etablierten Akteure in diesem Bereich – darunter IBM DFSMS und DFSMShsm, Broadcoms CA Disk und Rocket Softwares Backup for z/OS – werden im Folgenden ausführlich behandelt, zusammen mit den architektonischen Überlegungen, die unabhängig von der Produktwahl gelten.

Die richtige Wahl hängt stark von der bestehenden Umgebung, den Wiederherstellungsanforderungen und dem Betriebsmodell ab.

Wie erleichtern offene Standards und APIs (z. B. IBM-APIs, REST) den Einsatz von Backup-Tools?

Die historisch geschlossene Natur von Mainframe-Backup-Tools beginnt sich in Richtung offenerer Integrationsmodelle zu entwickeln. Die Bereitstellung von z/OS-Verwaltungsfunktionen durch IBM über REST-APIs hat Möglichkeiten für verschiedene Integrationen geschaffen, die von Backup-Anbietern oder internen Entwicklern entwickelt werden können (was zuvor ohne den Einsatz proprietärer Schnittstellen unmöglich war).

Interoperabilität ist hier der praktische Vorteil. Mainframe-Backup-Lösungen, die Standard-APIs unterstützen (bereitstellen oder nutzen), werden einen Platz in umfassenderen Backup-Orchestrierungslösungen für Unternehmen einnehmen – indem sie Statusinformationen an zentrale Überwachungstools liefern, Richtlinienänderungen von einheitlichen Verwaltungsplattformen empfangen oder über Standard-Objektspeicherschnittstellen auf Cloud-Speicher zugreifen.

Der Bedarf an Mainframe-Backup-Spezialisten (mit z/OS-Backup-Fachwissen) wird dadurch nicht vollständig beseitigt, aber die Trennung zwischen Mainframe-Backups und dem übrigen Backup-Bestand des Unternehmens wird verringert.

Welche Rolle spielen Automatisierungs- und Orchestrierungstools in Wiederherstellungsworkflows?

Manuelle Wiederherstellungsverfahren sind ein Risiko. Wenn komplexe, mehrstufige Runbooks unter Zeitdruck ausgeführt werden, steigt die Wahrscheinlichkeit menschlicher Fehler dramatisch an, darunter Reihenfolgefehler, übersehene Abhängigkeiten und andere Verzögerungen.

Die Automatisierung beseitigt all diese Probleme von vornherein. Die Bereiche, in denen die Automatisierung den unmittelbarsten Mehrwert in Mainframe-Backup- und Wiederherstellungs-Workflows bietet, sind:

• Planung von Backup-Jobs und Abhängigkeitsmanagement – Sicherstellung, dass Jobs in der richtigen Reihenfolge mit den entsprechenden Vor- und Nachbearbeitungsschritten ohne manuelles Eingreifen ausgeführt werden
• Katalogüberprüfung – automatisierte Prüfungen, die nach jedem Job die Integrität des Backup-Katalogs bestätigen und Probleme aufdecken, bevor sie zu Überraschungen bei der Wiederherstellung führen
• Alarm- und Eskalations-Workflows – sofortige Benachrichtigung, wenn Backup-Jobs fehlschlagen, ihr Zeitfenster überschreiten oder inkonsistente Ergebnisse liefern, weitergeleitet an die richtigen Teams ohne manuelle Überwachung
• Ausführung von Wiederherstellungs-Runbooks – skriptgesteuerte, sequenzierte Ausführung von Wiederherstellungsschritten, die die kognitive Belastung der Bediener bei Ereignissen mit hohem Stress reduziert und die korrekte Reihenfolge der Abhängigkeiten sicherstellt

Eine umfassendere Automatisierung sorgt für Vorhersehbarkeit und Testbarkeit während Wiederherstellungsprozessen. Ein Wiederherstellungs-Workflow, der bereits hunderte Male automatisch durchgeführt wurde, ist deutlich zuverlässiger als ein Workflow, der nur als Dokument existiert.

Welche kommerziellen Backup-Produkte sind für z/OS und verwandte Plattformen verfügbar?

Der kommerzielle Markt für Mainframe-Backup-Lösungen wird von einer kleinen Gruppe spezialisierter Anbieter dominiert, deren Produkte sich seit vielen Jahren parallel zu z/OS weiterentwickeln. Daher weisen alle diese Lösungen ein gemeinsames Merkmal auf: Sie basieren auf einem nativen Verständnis der z/OS-Konstrukte, das allgemeine Backup-Plattformen ohne erhebliche Kompromisse nicht nachbilden könnten.

Zu den zentralen Funktionskategorien, die Mainframe-Backup-Produkte voneinander unterscheiden, gehören:

• Granularität auf Datensatzebene – die Fähigkeit, einzelne Datensätze statt ganzer Volumes zu sichern, zu katalogisieren und wiederherzustellen, was für praktische tägliche Wiederherstellungsvorgänge unerlässlich ist
• Sysplex-Unterstützung – die Handhabung von Coupling-Facility-Strukturen und gemeinsam genutzten Datensätzen über einen parallelen Sysplex hinweg ohne Konsistenzlücken
• Katalogverwaltung – integrierte Verwaltung des ICF-Katalogs, der selbst eine Wiederherstellungsabhängigkeit darstellt und sorgfältig verwaltet werden muss
• Komprimierung und Deduplizierung – Inline-Reduzierung des Backup-Datenvolumens, was sich direkt auf die Speicherkosten und die Dauer des Backup-Fensters auswirkt

Bei der Auswahl einer Mainframe-Backup-Lösung müssen diese Funktionen gegen die Workload-Zusammensetzung und die Wiederherstellungsanforderungen der Umgebung abgewogen werden. Zu den am weitesten verbreiteten kommerziellen Mainframe-Backup-Lösungen gehören:

• IBM DFSMS und DFSMShsm – IBMs native z/OS-Speicherverwaltung und hierarchischer Speichermanager
• Broadcom ACF2 und CA Disk – seit langem etablierte Tools für die Sicherung und Wiederherstellung auf Datensatzebene mit tiefer z/OS-Integration und breiter Unternehmensakzeptanz
• Rocket Backup for z/OS von Rocket Software – Hochleistungs-Datensatz-Backup mit starken Komprimierungs- und Katalogverwaltungsfunktionen

Diese Lösungen sind nicht direkt austauschbar – jede hat unterschiedliche Stärken in Bereichen wie Sysplex-Unterstützung, Cloud-Integration und Betriebsautomatisierung, weshalb die Bewertung der Funktionen im Hinblick auf spezifische Umgebungsanforderungen wichtiger ist als der Ruf des Anbieters allein.

Wie werden Sicherheit, Compliance und Aufbewahrung bei Mainframe-Backups gehandhabt?

Welche Verschlüsselungs- und Schlüsselverwaltungsoptionen schützen Backup-Daten im Ruhezustand und während der Übertragung?

Hardwarebasierte Verschlüsselung ist in Mainframe-Umgebungen seit Jahrzehnten präsent, beispielsweise mit der IBM Crypto Express-Familie und der z/OS-Datensatzverschlüsselung. Dies ist ein etablierter Vorteil gegenüber vielen verteilten Umgebungen, der auch dann gewahrt bleiben sollte, wenn sich die Backup-Daten außerhalb des Mainframe-Ökosystems befinden. Die Verschlüsselung von Mainframe-Backup-Daten im Ruhezustand und während der Übertragung muss als Voraussetzung und nicht als optionale Funktion betrachtet werden.

Im Ruhezustand erfolgt die z/OS-Datensatzverschlüsselung mit AES-256 implizit auf der Speicherebene, sodass die Verschlüsselung ohne Änderungen an der Backup-Software oder am Anwendungscode erfolgen kann. Während der Übertragung wird die Übertragung an einen externen Standort oder in die Cloud durch TLS-Verschlüsselung geschützt.

In den meisten Fällen steigt die Komplexität beim Schlüsselmanagement. Die Verschlüsselung ist nur so stark wie die Schutzmaßnahmen, die für die Speicherung der Schlüssel gelten. In Mainframe-Backup-Umgebungen müssen diese Schlüssel während der Wiederherstellung zugänglich sein, ohne selbst zu einer potenziellen Schwachstelle zu werden.

Das ICSF-Framework und die Hardware-Sicherheitsmodule von IBM bilden die Grundlage für die unternehmensweite Schlüsselverwaltung unter z/OS. Unternehmen, die ihre Backups auf die Cloud oder verteilte Ziele ausweiten möchten, müssen jedoch sicherstellen, dass sie weiterhin die Kontrolle über die Schlüsselverwaltung behalten (anstatt diese Aufgabe standardmäßig an einen Drittanbieter zu delegieren).

Welche Audit- und Berichtsfunktionen sind für die Compliance-Überprüfung erforderlich?

Die Compliance-Überprüfung für Mainframe-Backups ist nicht allein durch die Existenz der richtigen Richtlinien gewährleistet – sie erfordert nachweisbare Belege dafür, dass diese Richtlinien konsequent umgesetzt werden und dass Ausnahmen erfasst und behoben werden. Zu den Audit- und Berichtsfunktionen, die Mainframe-Backup-Lösungen unterstützen müssen, gehören:

• Protokollierung der Auftragsabwicklung – zeitgestempelte Aufzeichnungen jedes Backup-Auftrags, einschließlich Statusangaben zu Erfolg, Fehler und teilweiser Fertigstellung, die für die Dauer des relevanten Compliance-Zeitraums aufbewahrt werden
• Berichterstattung zur Katalogintegrität – regelmäßige Überprüfung, ob Backup-Kataloge die von ihnen indizierten Daten korrekt widerspiegeln, wobei dokumentierte Ergebnisse für die Audit-Prüfung zur Verfügung stehen
• Zugriffs- und Änderungsaudit – Aufzeichnungen über jede administrative Maßnahme, die die Backup-Konfiguration, Aufbewahrungseinstellungen oder die Backup-Daten selbst betrifft, einschließlich der Identität des Ausführenden und des Zeitstempels
• Dokumentation von Wiederherstellungstests – formelle Aufzeichnungen über die Durchführung von DR-Tests, deren Ergebnisse und etwaige festgestellte Lücken, die von den Aufsichtsbehörden zunehmend als Nachweis für die operative Ausfallsicherheit erwartet werden
• Ausnahme- und Alarmhistorie – dokumentierte Aufzeichnungen über Backup-Fehlschläge, verpasste Zeitfenster und Richtlinienverstöße sowie Nachweise darüber, wie diese jeweils behoben wurden

Selbst das Fehlen einer Audit-Trail-Funktionalität könnte unter einer Reihe von regulatorischen Rahmenbedingungen als Compliance-Mangel gewertet werden; daher ist die Berichtsinfrastruktur rund um Mainframe-Backups keine bloße Erleichterung für die Berichterstattung – sie ist ein Bestandteil der Compliance-Situation.

Wie sollten Aufbewahrungsrichtlinien regulatorische und geschäftliche Anforderungen erfüllen?

Die Gestaltung von Aufbewahrungsrichtlinien für Mainframe-Backups steht am Schnittpunkt von regulatorischen Vorgaben, Anforderungen an die Geschäftskontinuität und dem Management von Speicherkosten. Leider verfolgen diese drei Anforderungen selten dieselben Ziele – Vorschriften verlangen möglicherweise eine Aufbewahrungsfrist von 7 Jahren, Anforderungen an die Geschäftskontinuität sind nach 90 Tagen erfüllt, und die Speicherkosten erfordern ein möglichst kurzes, vertretbares Zeitfenster.

Die regulatorischen Rahmenbedingungen legen für viele Mainframe-Umgebungen unverhandelbare Mindestanforderungen fest:

Aufbewahrungsrichtlinien sollten auf der Grundlage der Datenklassifizierung und nicht systembezogen festgelegt werden. Ein einzelner Mainframe kann Daten hosten, die gleichzeitig mehreren Aufbewahrungsrichtlinien unterliegen, und eine pauschale Aufbewahrungsrichtlinie, die für alle Datensätze die strengsten Anforderungen anwendet, verschwendet Speicherplatz und verkompliziert das Lebenszyklusmanagement unnötig.

Wie erstellt man einen Fahrplan zur Verbesserung der Reife von Mainframe-Backups und Disaster Recovery?

Die Verbesserung der Reife von Mainframe-Backups ist selten ein Einzelprojekt – es handelt sich vielmehr um ein Programm schrittweiser Verbesserungen, das auf eine erreichbare, überprüfbare und kontinuierlich verifizierte DR-Position abzielt. Die Roadmap, die dabei erstellt wird, beginnt mit einer ehrlichen Analyse des aktuellen Stands.

Welche Bewertungsfragen helfen dabei, den aktuellen Reifegrad und die Lücken zu ermitteln?

Bevor Verbesserungen priorisiert werden, benötigen Unternehmen ein klares Bild ihrer aktuellen Mainframe-Backup-Situation. Die folgenden Fragen bilden die Grundlage dieser Bewertung:

• Sind Wiederherstellungsziele formal definiert? Für jede Mainframe-Workload sollten dokumentierte RTO- und RPO-Ziele vorhanden sein, die den Kritikalitätsstufen zugeordnet sind – und nicht nur angenommen oder aus älterer Dokumentation übernommen werden, die in letzter Zeit nicht überprüft wurde.
• Wann wurde der letzte vollständige Wiederherstellungstest durchgeführt? Eine Mainframe-Backup-Strategie, die in den letzten 12 Monaten nicht durchgängig getestet wurde, ist nicht zuverlässig – ungetestete Annahmen häufen sich im Laufe der Zeit unbemerkt an. Unter z/OS bedeutet „durchgängig“, dass die IPL-Sequenzierung, die Wiederherstellung des ICF-Katalogs und die Verfahren zum Neustart von Subsystemen einbezogen werden – nicht nur die Überprüfung, ob Backup-Daten vorhanden sind.
• Werden Backup-Kataloge unabhängig von den Systemen gespeichert, die sie schützen? Der Verlust von Katalogen während eines Wiederherstellungsvorgangs ist eine der häufigsten und vermeidbaren Ursachen für das Scheitern der Wiederherstellung. Unter z/OS umfasst dies sowohl den ICF-Masterkatalog als auch alle Benutzerkataloge sowie DFSMShsm-Steuerungsdatensätze – die alle für sich genommen Wiederherstellungsabhängigkeiten darstellen.
• Sind Backup-Daten vor Insider-Bedrohungen und Ransomware geschützt? Unveränderlichkeitsrichtlinien, Zugriffskontrollen und Air-Gap-Verfahren sollten dokumentiert und überprüfbar sein – man darf nicht einfach davon ausgehen, dass sie existieren, nur weil sie irgendwann in der Vergangenheit implementiert wurden. Unter z/OS bedeutet dies, die Abdeckung von Backup-Datensätzen und -Katalogen durch RACF- oder ACF2-Richtlinien gezielt zu überprüfen, nicht nur die Produktionsdaten.
• Sind plattformübergreifende Abhängigkeiten abgebildet? Jedes verteilte System, jede API oder jede nachgelagerte Anwendung, die von Mainframe-Daten abhängt, sollte dokumentiert werden, wobei die Wiederherstellungsbeziehung zum Mainframe explizit definiert sein muss.
• Erfüllt die Backup-Umgebung die aktuellen Compliance-Anforderungen? Aufbewahrungsfristen, Verschlüsselungsstandards und Audit-Trail-Funktionen sollten anhand des aktuellen regulatorischen Rahmens überprüft werden – nicht anhand des Rahmens, der zum Zeitpunkt der letzten Erstellung der Backup-Richtlinie aktuell war.

Wie sollten schrittweise Verbesserungen priorisiert werden (Quick Wins vs. langfristige Projekte)?

Nicht jede in der Bewertung identifizierte Lücke kann gleichzeitig behoben werden. Ein praktisches Priorisierungsschema reicht von der sofortigen Risikominderung bis hin zur langfristigen Verbesserung der Architektur:

1. Beheben Sie zuerst Schwachstellen im Katalog – wenn Backup-Kataloge nicht unabhängig geschützt sind, stellt diese Lücke ein existenzielles Wiederherstellungsrisiko dar, das in seiner Dringlichkeit alle anderen Verbesserungen übertrifft.
2. Wiederherstellungsziele festlegen oder validieren – ohne dokumentierte RTO- und RPO-Ziele fehlt jeder nachfolgenden Verbesserung ein messbarer Maßstab, auf den hingearbeitet werden kann.
3. Implementieren Sie Unveränderlichkeit und Zugriffskontrollen – Verbesserungen der Ransomware-Resilienz sind wirkungsvoll und relativ einfach ohne größere architektonische Änderungen zu erreichen, was sie zu starken „Early Wins“ macht.
4. Führen Sie einen vollständigen Wiederherstellungstest durch – bevor Sie in neue Tools oder Architekturen investieren, überprüfen Sie, was die aktuelle Umgebung unter realen Wiederherstellungsbedingungen tatsächlich leisten kann.
5. Lücken bei der plattformübergreifenden Synchronisation schließen – sobald die Mainframe-Backup-Situation stabilisiert ist, den Fokus auf verteilte Abhängigkeiten und die Wiederherstellungskoordination über Plattformgrenzen hinweg ausweiten.
6. Bewerten Sie Lücken bei Tools und Automatisierung – mit einem klaren Überblick über Wiederherstellungsanforderungen und aktuelle Fähigkeiten können Entscheidungen zu Tools anhand spezifischer, validierter Kriterien getroffen werden, anstatt sich auf Anbieterangaben zu verlassen.
7. Auf kontinuierliche Validierung hinarbeiten – automatisierte Backup-Verifizierung, geplante DR-Tests und fortlaufende KPI-Verfolgung ersetzen punktuelle Bewertungen durch einen kontinuierlich gepflegten Überblick über die DR-Bereitschaft.

Welche KPIs und Kennzahlen sollten die kontinuierliche Reifung des DR-Programms leiten?

Ein Mainframe-Backup-Programm, das nicht gemessen wird, wird nicht verwaltet. Die folgenden Kennzahlen bieten einen praktischen Rahmen für die Verfolgung der DR-Reife im Zeitverlauf:

• Tatsächliche Wiederherstellungszeit vs. Zielwert – die Differenz zwischen der getesteten Wiederherstellungszeit und dem dokumentierten RTO, gemessen bei jedem DR-Test und als Trend über die Zeit verfolgt.
• Tatsächlicher Wiederherstellungspunkt (Recovery Point) vs. Zielwert – das bei Wiederherstellungstests tatsächlich erzielte Datenverlustfenster im Vergleich zum dokumentierten RPO für jede Workload-Ebene.
• Erfolgsrate der Backup-Jobs – der Prozentsatz der geplanten Mainframe-Backup-Jobs, die innerhalb ihres definierten Zeitfensters erfolgreich abgeschlossen werden; wird wöchentlich verfolgt und untersucht, wenn er unter einen vereinbarten Schwellenwert fällt.
• Mittlere Zeit bis zur Erkennung eines Backup-Fehlers – wie schnell Backup-Fehler nach ihrem Auftreten identifiziert werden, was sich direkt darauf auswirkt, wie lange die Umgebung mit einer unentdeckten Lücke in ihrem Schutz läuft.
• Häufigkeit der Überprüfung der Katalogintegrität – wie oft Backup-Kataloge auf Richtigkeit und Vollständigkeit überprüft werden, wobei die Ergebnisse für Audit-Zwecke dokumentiert werden.
• Abdeckung der Sysplex-Wiederherstellungskoordination – der Prozentsatz der Tier-1-Workloads, für die systemübergreifende Wiederherstellungsabhängigkeiten, einschließlich Coupling-Facility-Strukturen und Beziehungen zwischen gemeinsam genutzten Datensätzen, explizit dokumentiert und getestet werden.
• Häufigkeit und Abdeckung von DR-Tests – die Anzahl der pro Jahr durchgeführten DR-Tests und der Prozentsatz der Tier-1- und Tier-2-Workloads, die in jedem Testzyklus enthalten sind.
• Zeit bis zur Behebung identifizierter Lücken – die durchschnittliche Zeit zwischen der Identifizierung einer Lücke – durch Tests, Audits oder Überwachung – und der Umsetzung einer validierten Korrektur.

Fazit

Mainframe-Backup und -Wiederherstellung sind kein Projekt, das einmal gelöst und dann nie wieder angerührt wird. Die Bedrohungslage entwickelt sich weiter, geschäftliche Anforderungen verschieben sich, regulatorische Rahmenbedingungen verschärfen sich und die Systeme, die von Mainframe-Daten abhängen, werden im Laufe der Zeit immer stärker miteinander vernetzt. Die Mainframe-Backup-Strategie, die vor drei Jahren noch ausreichte, weist heute wahrscheinlich eine Reihe von Lücken auf – nicht weil sie versagt hat, sondern weil sich das Umfeld um sie herum verändert hat, während die Strategie unverändert blieb.

Unternehmen, denen es gelingt, echte DR-Resilienz aufrechtzuerhalten, betrachten Mainframe-Backups als kontinuierliches Programm und nicht als einmaliges Projekt. Definierte Wiederherstellungsziele, getestete Verfahren, durchgesetzte Sicherheitskontrollen und regelmäßig überprüfte Aufbewahrungsrichtlinien sind keine einmaligen Leistungen, sondern operative Gewohnheiten, die darüber entscheiden, ob eine Wiederherstellung möglich ist, wenn es darauf ankommt.

Häufig gestellte Fragen

Können Mainframe-Backup-Daten zur Unterstützung von Analyse- oder Data-Lake-Initiativen genutzt werden?

Mainframe-Sicherungsdaten können als Quelle für Analyseinitiativen dienen, erfordern jedoch einen sorgfältigen Umgang – Sicherungsdatensätze sind für die Wiederherstellung und nicht für Abfragen strukturiert und müssen in der Regel transformiert werden, bevor sie im Kontext eines Data Lake nutzbar sind. Der praktischere Ansatz besteht darin, Mainframe-Sicherungen als sekundäre Datenquelle zu betrachten, die speziell entwickelte Datenextraktionspipelines ergänzt, anstatt sie zu ersetzen. Unternehmen, die versuchen, rohe Backup-Daten direkt für Analysen zu nutzen, stellen oft fest, dass der operative Aufwand für Formatkonvertierung und Konsistenzprüfung den Wert der Daten selbst übersteigt.

Welche Risiken birgt es, sich bei der Notfallwiederherstellung ausschließlich auf Replikation zu verlassen?

Replikation behebt Ausfälle auf Standortebene effektiv, bietet jedoch keinen Schutz vor logischen Beschädigungen – wenn fehlerhafte Daten auf den Primärstandort geschrieben werden, überträgt die Replikation diese fehlerhaften Daten nahezu in Echtzeit auf den Sekundärstandort. Eine Mainframe-Backup-Strategie, die ausschließlich auf Replikation setzt, verfügt über keinen Wiederherstellungspunkt vor dem Ausfallereignis. Das bedeutet, dass logische Fehler, Ransomware-Verschlüsselung und Anwendungsfehler, die fehlerhafte Daten erzeugen, beide Standorte gleichermaßen unbrauchbar machen können. Replikation sollte eine Ebene einer umfassenderen Mainframe-Backup-Architektur sein, nicht die gesamte Strategie.

Wie sollten Mainframe-Backup-Strategien an ESG- und Datenhoheitsanforderungen angepasst werden?

Anforderungen an die Datenhoheit – die vorschreiben, dass bestimmte Daten innerhalb bestimmter geografischer oder rechtlicher Grenzen verbleiben müssen – schränken die Offsite- und Cloud-Backup-Optionen für Mainframe-Umgebungen, die über mehrere Regionen hinweg betrieben werden, direkt ein. Mainframe-Backup-Lösungen müssen anhand der Datenhoheitsanforderungen jeder Rechtsordnung bewertet werden, in der das Unternehmen tätig ist, nicht nur anhand des Standorts des primären Rechenzentrums. ESG-Aspekte fügen eine weitere Dimension hinzu, da der Energieverbrauch der Backup-Infrastruktur – insbesondere großer Bandbibliotheken und der ständig aktiven Replikation – für Unternehmen mit formellen ESG-Verpflichtungen zu einem Faktor in der Nachhaltigkeitsberichterstattung wird.