Überblick
Die SAP-HANA-Datenbank erfordert aufgrund ihrer In-Memory-Architektur eine andere Strategie als klassische Ansätze zur Datenbanksicherung. HANA-Daten- und Log-Backups werden über den Savepoint-Mechanismus und eine Delta-Backup-Struktur organisiert. Eine falsch konfigurierte Backup-Richtlinie führt dazu, dass der Log-Bereich vollläuft, das System ausfällt oder die erwartete Wiederherstellungszeit im Katastrophenfall überschritten wird.
Das SAP-Backint-Interface ist eine Standardschnittstelle zur Integration von Backup-Lösungen von Drittanbietern mit HANA. Enterprise-Backup-Plattformen wie Commvault, Veeam und NetBackup können HANA-Backups über Backint direkt in Object Storage oder auf Band schreiben. Diese Integration konsolidiert das Backup-Management auf der bestehenden Backup-Plattform des Unternehmens und macht die Verwaltung separater Werkzeuge überflüssig.
Point-in-Time Recovery (PITR) gehört zu den kritischen Wiederherstellungsfunktionen von SAP HANA. Dank Log-Backups ist die Rückkehr zu einem bestimmten Zeitpunkt (minuten- oder sekundengenau) möglich. Diese Funktion ermöglicht es, Datenverluste infolge menschlicher Fehler, fehlerhafter DML-Operationen oder Anwendungsfehler mit minimalem Verlust auszugleichen. Die Wirksamkeit von PITR steht in direktem Verhältnis zur Häufigkeit der Log-Backups und zur Aufbewahrungsdauer.
Die Bedrohung durch Ransomware hat die SAP-Backup-Strategie aus Sicht der Cybersicherheit neu geprägt. Ransomware mit Zugriff auf das Produktivsystem kann auch das angebundene Backup-Ziel verschlüsseln. Immutable-Storage-Ziele und eine Air-Gap-Kopierstrategie sind zu unverzichtbaren Komponenten geworden, um SAP-Backups vor Ransomware-Angriffen zu schützen.
In der SAP-Welt wird das Thema Backup häufig als operative Aufgabe des Infrastrukturteams betrachtet; tatsächlich ist es jedoch die wichtigste Absicherung der Geschäftskontinuität. Denn SAP-Systeme speichern nicht einfach nur Daten; sie enthalten Finanzbuchungen, Produktionspläne, Versandinformationen, Kundenbewegungen und regulatorisch relevante historische Daten. Ein Scheitern der SAP-Wiederherstellung bedeutet daher weit mehr als ein technisches Problem: Es geht um Reputation, rechtliche Risiken und operativen Stillstand. Deshalb sollte SAP Backup & Recovery losgelöst von der alltäglichen Datensicherung und mit einem disziplinierteren Ansatz behandelt werden.
Die In-Memory-Struktur von HANA unterscheidet sich so stark, dass sie sich nicht mit klassischen Datenbankgewohnheiten verwalten lässt. Die im Arbeitsspeicher laufende Daten-Engine reagiert deutlich empfindlicher auf die Kontinuität des Log-Stroms, das Savepoint-Verhalten und die Konsistenz der Speicherschicht. Ist die Backup-Richtlinie falsch konzipiert, verlängern sich nicht nur die Wiederherstellungszeiten; im laufenden Betrieb können auch Probleme wie Log-Überlauf, Leistungseinbußen oder eine fehlerhafte Backup-Kette auftreten. Deshalb plant Indexline das Backup-Design nicht nur im Hinblick auf die Aufbewahrungsdauer, sondern stellt das Verhalten von HANA in den Mittelpunkt.
Ein weiteres kritisches Thema ist, dass Backups nicht losgelöst von der übergreifenden Disaster-Recovery- und Cybersicherheitsstrategie des Unternehmens betrachtet werden können. Backups allein sind nicht wertvoll; ebenso wichtig ist, wie schnell die Wiederherstellung erfolgt, bis zu welchem Zeitpunkt zurückgesprungen werden kann, in welcher Umgebung getestet wird und wie nach einem Angriff verifiziert wird, dass die Daten sauber sind. Gerade bei Ransomware-Angriffen bietet nicht die bloße Existenz von Backups echte Sicherheit, sondern der Besitz von Backups, die vom Angriff nicht betroffen, getestet und zuverlässig wiederherstellbar sind.
Auch die Governance-Dimension ist im SAP-Backup-&-Recovery-Service von Bedeutung. Es muss im Voraus festgelegt werden, welches System wie häufig gesichert wird, wie lange die Backups aufbewahrt werden, welche Daten gesetzlichen Aufbewahrungspflichten unterliegen, welche Teams Wiederherstellungen freigeben und wann Restore-Tests durchgeführt werden. Fehlt diese Struktur, gibt es zwar Backups, aber niemand weiß wirklich, was in welcher Zeit und mit welcher Genauigkeit wiederhergestellt werden kann. Um diese Unsicherheit zu beseitigen, konzipiert Indexline den technischen Plan gemeinsam mit dem Prozessplan.
Im Unternehmensmaßstab sind auch die Kosten des SAP-Backups ein wichtiger Parameter. Alle Daten mit derselben Geschwindigkeit und derselben Aufbewahrungsrichtlinie vorzuhalten, ist meist unnötig teuer. Werden häufig genutzte kurzfristige Backups, langsamere, aber wirtschaftliche Schichten für die Langzeitaufbewahrung und Immutable-Ziele kombiniert, lässt sich ein sowohl sicheres als auch rationales Modell aufbauen. So entsteht selbst unter Kostendruck eine nachhaltige Backup-Architektur, ohne Abstriche beim Schutzniveau.
Letztlich ist SAP Backup & Recovery die konkrete Antwort auf die Vorbereitung eines Unternehmens auf den „schlimmsten Tag“. Eine richtig konzipierte Strategie mag im Alltag unsichtbar sein; doch bei Datenverlust, einer fehlerhaften Transaktion oder einem Sicherheitsvorfall zeigt sie innerhalb von Minuten, wie gut das Unternehmen vorbereitet ist. Deshalb betreibt Indexline Backups nicht als passive Hintergrundaufgabe, sondern als aktiv verifizierte und kontinuierlich verbesserte Schutzschicht.
So funktioniert es
Design der Backup-Strategie: Durch Analyse von RPO-Ziel, Aufbewahrungsdauer, Backup-Fenster und Speicherkapazität wird die Backup-Richtlinie konzipiert.
Backint-Integration: Die HANA-Backint-Schnittstelle wird mit der Backup-Plattform eines Drittanbieters integriert.
Daten- & Log-Backup: Ein Zeitplan für vollständige, inkrementelle und differenzielle Daten-Backups wird eingerichtet. Die Häufigkeit der Log-Backups wird am RPO-Ziel ausgerichtet.
Speicherkonfiguration: Disk für schnelle Wiederherstellung und Band/Object Storage für die Langzeitaufbewahrung werden in Schichten konfiguriert.
Immutable Backup: Zum Schutz vor Ransomware wird ein unveränderliches Backup-Ziel konfiguriert.
Restore-Test: In einer von der Produktion isolierten Umgebung werden regelmäßige Restore-Tests durchgeführt und die RTO verifiziert.
Monitoring: Erfolg/Misserfolg der Backups sowie Dauer- und Größenmetriken werden überwacht. Fehlgeschlagene Backups werden per Alarm gemeldet.
Wichtigste Funktionen
HANA-Backint-Integration
Über die branchenübliche Backint-Schnittstelle wird eine reibungslose Integration mit Enterprise-Backup-Plattformen erreicht.
Inkrementelles Backup
Mit einer inkrementellen und differenziellen Backup-Strategie werden Backup-Fenster und Speichernutzung optimiert.
Automatisierung der Log-Backups
Die Häufigkeit der Log-Backups wird automatisch am RPO-Ziel ausgerichtet. Die Verwaltung des Log-Bereichs wird automatisiert.
Point-in-Time Recovery
Wiederherstellung auf einen bestimmten Zeitpunkt mit minutengenauer Präzision. Schnelle Wiederherstellung nach menschlichen Fehlern und fehlerhaften DML-Operationen.
Immutable Backup
Mit einem unveränderlichen Backup-Ziel bleiben die Backups auch bei einem Ransomware-Angriff geschützt.
Multi-Tier-Speicher
Häufig genutzte neue Backups liegen auf Disk; ältere Backups werden automatisch in wirtschaftlichen Object Storage oder auf Band verschoben.
Automatisierter Restore-Test
Regelmäßige Restore-Übungen werden durchgeführt; die Wiederherstellungszeit wird gemessen und mit dem RTO-Ziel verglichen.
SAP-HANA-Cockpit-Integration
Der Backup-Status wird über SAP HANA Cockpit und die zentrale Monitoring-Plattform in einer einzigen Konsole überwacht.
Vorteile & Nutzen
SAP-Daten werden bei Ausfall- oder Angriffsszenarien im Rahmen der RPO/RTO-Ziele vollständig wiederhergestellt.
Immutable Backups garantieren bei einem Ransomware-Angriff einen verlässlichen Wiederherstellungspunkt für SAP-Daten.
Mit PITR werden durch menschliche Fehler verursachte Datenverluste innerhalb von Minuten und mit minimalem Datenverlust behoben.
Die Integration des Backup-Managements in die bestehende Enterprise-Plattform beseitigt den Aufwand für die Verwaltung separater Werkzeuge.
Regelmäßige Restore-Tests belegen nicht nur, dass Backups erstellt wurden, sondern dass sie sich wiederherstellen lassen.
Mit Multi-Tier-Speicher werden die Kosten der Langzeitsicherung optimiert.
Da Wiederherstellungsszenarien im Voraus getestet werden, sinken Unsicherheit und Entscheidungsdruck in der Krise.
Für gesetzliche Aufbewahrungspflichten, Audits und interne Kontrollen entsteht eine besser nachvollziehbare Datenschutzstruktur.
Da das HANA-spezifische Verhalten beim Schutz von Logs und Daten berücksichtigt wird, sinken die operativen Risiken.
Nach einem Cyberangriff beschleunigt sich der Prozess, einen sauberen Wiederherstellungspunkt zu finden und zu verifizieren.
Anwendungsfälle nach Branche
Fertigung
Nach einer fehlerhaften Dateneingabe wurde SAP ERP per PITR auf den sauberen Stand von vor 45 Minuten zurückgesetzt; es gab keinerlei Betriebsunterbrechung.
Einzelhandel
Bei einem Ransomware-Angriff wurde das SAP-System mithilfe von Immutable Backups innerhalb von 2 Stunden von einem sauberen Wiederherstellungspunkt wiederhergestellt.
Logistik
Die tägliche Backup-Strategie für SAP TM wurde durch stündliche Log-Backups ergänzt; die RPO sank von 24 Stunden auf 1 Stunde.
Finanzwesen
Eine Backup-Übung für SAP FI-CO wurde durchgeführt; dabei zeigte sich, dass die Restore-Dauer doppelt so lang wie das Ziel war, woraufhin die Infrastruktur optimiert wurde.
Energie
Die Löschung einer kritischen Kundendatentabelle in SAP IS-U wurde per PITR innerhalb von 30 Minuten behoben; Auswirkungen auf Kunden wurden minimiert.
Öffentlicher Sektor
Die SAP-Backup-Infrastruktur einer Behörde wurde im Zuge der HANA-Migration modernisiert; gesetzliche Aufbewahrungsfristen wurden mit einem Immutable-Ziel erfüllt.
Der Indexline-Ansatz
Das SAP-Backup ist einer der am häufigsten übersehenen, aber kritischsten Bereiche des IT-Betriebs. Die Lücke zwischen „Wir erstellen Backups“ und „Wir können aus dem Backup wiederherstellen“ schließt sich nur durch regelmäßige Restore-Tests. Indexline definiert Restore-Übungen für jeden Kunden als verpflichtenden Bestandteil des Service.
Die Verwaltung des HANA-Log-Bereichs erfordert Sorgfalt. Sind Log-Backups zu selten, läuft der Log-Bereich voll und das System kann den Betrieb einstellen. Automatisierte Log-Backups und das Monitoring des Log-Bereichs verhindern dieses Risiko.
Die SAP-Backup-Strategie sollte gemeinsam mit der SAP-DR-Strategie geplant werden. Die mit HANA System Replication erreichte Hochverfügbarkeit ersetzt kein Backup; sie ergänzt es beim Datenschutz.
Im Ansatz von Indexline wird der Erfolg eines Backups nicht allein am Job-Status gemessen, sondern anhand von Wiederherstellbarkeit, Zeitzielen und dem Nachweis der Datenintegrität bewertet.
Bei kritischen SAP-Systemen reicht ein einschichtiger Schutz nicht aus. Mit einer Kombination aus schneller lokaler Wiederherstellung, Remote-Kopie, Immutable-Ziel und regelmäßigen Tests bauen wir ein mehrschichtiges Absicherungsmodell auf.
Wir übersetzen Backup-Richtlinien aus der Sprache der Technikteams in ihre geschäftlichen Auswirkungen. So erkennt das Management klarer, welches Maß an Datenverlust akzeptabel ist, und Investitionsentscheidungen werden fundierter getroffen.
Häufig gestellte Fragen
Wie häufig sollte ein HANA-Backup durchgeführt werden?
Daten-Backups sollten täglich (vollständig oder inkrementell) erfolgen, Log-Backups in Abständen von 15–60 Minuten. Das RPO-Ziel bestimmt die Häufigkeit der Log-Backups. Für kritische Produktivsysteme ist ein Log-Backup-Intervall von 15 Minuten gängige Praxis.
Die Backup-Dauer ist zu lang – was können wir tun?
Der Wechsel zu inkrementellen Backups, die Anpassung der Backup-Parallelität und eine Speicheranbindung mit hoher Bandbreite verkürzen die Backup-Dauer. Auch die HANA-Option „save only delta“ ermöglicht schnellere inkrementelle Backups.
Was passiert, wenn der Log-Bereich voll ist?
Ist der Log-Bereich voll, weist HANA neue Schreibvorgänge ab, und das System kann zum Stillstand kommen. Um dies zu verhindern, sind eine Automatisierung der Log-Backups, das Monitoring des Log-Bereichs und eine automatische Richtlinie zur Log-Bereinigung zwingend erforderlich.
Ersetzt HANA System Replication ein Backup?
Nein. HANA System Replication sorgt für HA (Hochverfügbarkeit); bei vorsätzlichem Löschen oder bei Beschädigung von Daten spiegelt die Replik jedoch denselben Schaden wider. In solchen Szenarien ermöglicht erst das Backup die Wiederherstellung.
Unterscheidet sich das Backup von Tenant-Datenbanken?
In einer HANA-MDC-Umgebung (Multi-Datacenter Container) werden die Systemdatenbank und die Tenant-Datenbanken getrennt gesichert. Für jeden Tenant kann eine eigene Backup-Richtlinie definiert werden.
Wie lässt sich die Backup-Größe reduzieren?
Die native HANA-Komprimierung wird während des Backups angewendet. Die Deduplizierungs- und Komprimierungsfunktionen von Backup-Plattformen der Drittanbieter sorgen für zusätzliche Einsparungen. Auch die Verlagerung selten genutzter Daten in eine Warm-/Cold-Schicht mit SAP Data Tiering verbessert die effiziente Speichernutzung.
Ist ein SAP-Tablespace-Backup erforderlich?
In HANA gibt es das klassische Tablespace-Konzept nicht; alle Daten werden in der HANA-Volume-Struktur gehalten. Das Backup erfolgt über den HANA-Backup-Katalog und den Data-Snapshot-Mechanismus. Zusätzlich ist ein separates Backup des SAP-ABAP-Anwendungsservers erforderlich.
Wie häufig sollte ein Wiederherstellungstest aus dem Backup durchgeführt werden?
Empfohlen wird mindestens ein Restore-Test pro Quartal. Für kritische SAP-Systeme sind monatliche Tests angemessen. Der Test sollte eine echte Wiederherstellung in einer isolierten Umgebung einschließlich Messung der RTO umfassen.