In R/3-Datenbanken befinden sich üblicherweise Daten, die für den Bestand eines Unternehmens von essentieller Bedeutung sind. Datenmengen im Bereich von mehreren hundert GBs sind dabei nichts Außergewöhnliches. Liegt dem SAP-System eine Oracle-Datenbank zugrunde, dann kann der Anwender jetzt die Daten über die von SAP implementierte Schnittstelle mittels Spiegelplatten sichern.
SAP hat in der Schnittstellen-Spezifikation "BC-BRI Backint / Interface for Oracle Databases" von November 1997 die Kriterien beschrieben, an die sich die Hesteller von Backup-Software verbindlich zu halten haben, wenn sie von SAP eine Zertifizierung ihrer Software haben möchten. Diese Spezifikation geht davon aus, dass die Sicherung vom Datenbank-Server vorgenommen wird. In Bereichen, wo es sich um sehr große SAP-R/3-Installationen handelt, die mehr oder weniger rund um die Uhr mit voller Leistung verwendet werden, ist dieses Konzept aber nicht mehr tragbar.
Sollen große R/3-Datenbanken häufig komplett gesichert werden, so müssen vor allem zwei Anforderungen erfüllt sein: Der DB-Server muss von den Sicherungsaktivitäten entlastet werden, und bei einer Online-Sicherung muss die Konsistenz der Datenbank durch das Umschalten in den Backup-Mode gewährleistet sein. Dies führt jedoch zu einer erhöhten Last auf dem Datenbank-Server, da dabei viel mehr Informationen in die Redolog-Dateien geschrieben werden. Dieser Zeitraum des Backup-Modes soll deswegen so kurz wie möglich sein.
Je kürzer der Zeitraum zwischen der letzten Vollsicherung und dem gewünschten Wiederherstellungszeitpunkt ist, desto schneller kann im Notfall das Recovery erfolgen, da weniger Archive-Redolog-Dateien benötigt werden. Bei der herkömmlichen, den Datenbankbetrieb belastenden Sicherungsmethode, war dies nicht möglich.
Die SAP-SpezifikationSAP gibt in der Beschreibung "Spiegelplattensicherung" von Juni 1999 vor, wie R/3-Datenbanken online und offline unter Nutzung von Spiegelplatten gesichert werden können. Das SAP-eigene Sicherungswerkzeug "BRBackup" unterstützt dieses Konzept ab Release 4.5. Die dort beschriebene Vorgehensweise zielt darauf ab, dass die Sicherung der Tablespace- und Online-Redolog-Dateien statt vom Produktivrechner von einem speziellen Datensicherungsrechner erledigt wird, der die Datenbankdateien von abgespalteten Spiegelplatten sichert. Damit wird die Performance eines R/3-Produktiv-Systems nicht mehr beeinträchtigt, während die Sicherung läuft.
Die Backint-Spezifikation und damit auch die Kriterien für die Zertifizierung von Backup-Software gelten aber auch für die Spiegelplattensicherung, da die Sicherung von abgespalteten Spiegelplatten für Backint transparent ist. In der R/3-Konfigurationsdatei init@.sap wurde der Parameterset für die Sicherung von Spiegelplatten entsprechend erweitert.
Die SAP-Definition der Spiegelplatten-Sicherung nimmt auch Stellung zum Offline-Sichern von R/3-Datenbanken. Das Vorgehen ist ähnlich dem Ablauf der Online-Sicherung (siehe Grafik), mit den Unterschieden, dass statt dem Starten und Beenden des Backup-Modes die Datenbank heruntergefahren beziehungsweise wieder hinaufgefahren wird. Durch die Verwendung von Spiegelplatten reicht es aus, die Datenbank nur wenige Minuten offline zu stellen.
Erst durch Spiegelplatten wird es möglich, den Backup-Mode auf wenige Minuten zu reduzieren, da das Abkoppeln der Spiegelplatten wesentlich schneller geht als das Schreiben der Daten auf Band. Mit Spiegelplatten kann eine Kopie der R/3-Datenbankdateien "eingefroren" für die Dauer der Datensicherung aufgehoben werden, während sich schon wieder die Daten der Produktivdatenbank ändern. Dies wird mit Snapshot bezeichnet. Wichtig ist, dass der Snapshot beziehungsweise die Spiegelplatten während der laufenden Datenbankbetriebes abgekoppelt und wieder synchronisiert werden können.
Wie auch in der Definition der Spiegelplattensicherung der SAP erwähnt wird, benötigt die Spiegelung der Daten etwa bei den EMC-Plattensystemen "Symmetrix", aber auch bei einigen anderen Spiegelplatten- oder Snapshot-Konzepten, keine CPU-Leistung, weder auf dem Produktiv- noch auf dem Backup-Rechner.
Die Zeit, die sich die R/3-DB im Backup-Mode befinden muss, hängt direkt von der Zeit ab, die benötigt wird, um die Spiegelplatten abzukoppeln. Natürlich ist es notwendig, dabei zu beachten, dass die Spiegelplatten erst dann abgekoppelt werden dürfen, wenn die Synchronität der Daten sichergestellt ist. Durch Spiegelplatten beziehungsweise Snapshots lässt sich somit die zweite Anforderung (Datenkonsistenz) erfüllen.
Arten von SnapshotsBei den Symmetrix-Speichern von EMC wird die Spiegelung der Daten durch die "Time-Finder"-Software ermöglicht. Die Spiegelplatten nennen sich dabei "Business Continuance Volume" (BCV). Die BCVs sind komplette physikalische Kopien der Originalplatten. Die Übertragung der Daten auf die BCVs geschieht über einen internen Cache-Mechanismus, der dazu führt, dass beim Zugriff auf die Originalplatten im Prinzip keine Performance-Einbußen bemerkbar sind.
Auch bei den abgekoppelten Spiegelplatten der Symmetrix handelt es sich um einen Snapshot, und zwar mit der Besonderheit, dass es sich um eine komplette physikalische Kopie handelt. Darüber hinaus gibt es auch Snapshots, bei denen beim Anlegen nur eine Liste von Zeigern auf die Original-Datenblöcke angelegt wird. Dies geht extrem schnell, da hierbei keine Daten kopiert werden. Die eigentliche Arbeit geschieht bei dieser Art von Snapshots erst, wenn nach dem Erstellen des Snapshots Daten geändert werden. Dann muss vor dem Beschreiben der Platte erst der Datenblock kopiert und der zugehörige Zeiger geändert werden, was zu Performance-Einbußen führen kann.
Platz sparenAls Variante davon gibt es Snapshots, die beim Erzeugen auch nur eine Liste von Zeigern auf die Datenblöcke anlegen, die aber beim Ändern der Blöcke den "eingefrorenen" Block liegen lassen und den neuen Originalblock an einer anderen Stelle ablegen. Das spart Zeit beim Schreiben, führt aber zu einer sehr verteilten Struktur der Datenblöcke. Wenn nicht regelmäßig reorganisiert wird, wird dies zu schlechterem Zeitverhalten des Datenbankbetriebs führen.
Diese beiden letzten Arten von Snapshots haben den Vorteil, dass bei geringem Datenänderungs-Aufkommen für den Snapshot nur wenig zusätzlicher Plattenplatz benötigt wird. Hingegen bieten BCVs, für die der komplette Plattenplatz der Produktivdatenbank ein zweites Mal benötigt wird, den Vorteil, dass deren Performance zu keiner Zeit nachlässt.
Backup-RechnerDurch das Einrichten des Zugriffs auf die Spiegelplatten für einen anderen Rechner, den Backup-Rechner, kann diesem auch die Aufgabe der Sicherung der R/3-Daten übertragen werden. Dafür ist es notwendig, dass der Backup-Rechner die Dateien in dem Format lesen kann, wie sie vom Produktivrechner erzeugt wurden. Es ist zwar nicht notwendig, dass eine identische Datenbank auf dem Backup-Rechner aufgebaut wird, aber der File-System-Typ, der häufig vom Betriebssystem abhängig ist, und die virtuellen Plattensysteme müssen entsprechend vom Backup-Rechner lesbar sein.
Ist dies nicht der Fall, so könnte der Backup-Rechner die Daten nur als "Rohdaten" (Raw-Slices) lesen und sichern. Dies würde aber bedeuten, dass in jedem Fall die komplette Platte gesichert werden muss, auch wenn nur ein Teil davon beschrieben ist, da der Backup-Rechner nicht weiß, wo sich die relevanten Daten befinden. Darüber hinaus könnte beim Recovery auch keine einzelne Datei vom Band gelesen werden, da die gesamten Rohdaten einer Platte als eine Einheit auf dem Band abgelegt würden.
DatenflussDie Datensicherung der R/3-Datenbank besteht aus zwei Teilen: dem Sichern der Tablespace-Dateien, das durch das SAP-BR-Tool "BRBackup" angestoßen wird, und aus der Sicherung der Archive-Redolog-Dateien, die vom BR-Tools "BRAarchive" erledigt wird.
Wie bereits erwähnt, wird die Sicherung der Tablespace-Dateien nicht auf dem Produktiv-Rechner, sondern durch BRBackup auf dem Backup-Rechner ausgeführt. Er liest die Daten von den gemounteten Spiegelplatten und reicht sie an das Sicherungsgerät weiter. Die Übertragung erfolgt im Allgemeinen über Fibre-Channel-Verbindungen oder SCSI, belastet also das LAN nicht.
RecoveryDie Sicherung der Archive-Redolog-Dateien erfolgt bei SAP R/3 mit dem Kommando BRArchive. Die Verwendung von Spiegelplattensicherung ändert daran nichts, so dass die Sicherung der Archive-Redolog-Dateien wie bisher auf dem Produktivrechner getätigt wird.
Für das Recovery gibt sowohl die Möglichkeit, die Daten mit dem BR-Tool "BRRestore" sowohl auf dem Produktiv- als auch auf dem Backup-Rechner wieder herzustellen. Da die SAP-Definition und die BR-Tools keine Möglichkeit vorsehen, die Daten über die Spiegelplatten auf die Platten der Produktivdatenbank zu übertragen, ist es sinnvoll, dass der Produktivdatenbank-Server auch direkt auf die Sicherungsgeräte des Backup-Rechners zugreifen kann. Nur so ist im Notfall ein performantes Wiederherstellen der Daten möglich. Wenn der gemeinsame Zugriff auf die Sicherungsgeräte nicht gegeben ist, würde das bedeuten, dass die Datenwiederherstellung auf den Original-Ablageort über am Backup-Rechner gemountete NFS-Devices erfolgen müsste, was zu Performance-Einbußen führen würde.
Darüber hinaus können die Dateien auf den Spiegelplatten zur Datenwiederherstellung verwendet werden, unabhängig von der SAP-Definition der Spiegelplattensicherung. Das spart unter Umständen Zeit, muss aber manuell erledigt werden und und erfodert gute Kenntnisse der Konfiguration und der Software.
Bei Verwendung eines Datensicherungskonzeptes, welches sich an die Definition der Spiegelplattensicherung der SAP hält, kann die Sicherung der Daten ohne nennenswerte Belastung des Datenbank-Servers und integriert in die normalen SAP Backup- und Recover-Tools (SAP BR-Tools) erfolgen. Neben der von Fujitsu-Siemens Computers angebotenen Lösung "NSR-R/3-EMC" mit "Networker" unterstützen auch die Produkte "Omniback" von HP und "Tivoli" (ADSM) von IBM die Spiegelplatten-Sicherung von SAP-R/3-Datenbanken.
*Holger Gottwald ist Leiter der Entwicklung für DatenbankBackup-Software bei Fujitsu-Siemens Computers.
Erklärungen zur GrafikBRBackup-q: Die Definition weist daraufhin, dass die Zuordnung von Dateinamen zu physikalischen Platten ("Resolving") so lange dauern kann, dass ein Vorziehen dieser Aktivität aus Zeitgründen (Dauer des Backup-Modes) notwendig ist. Neben dem Zuordnen der Dateinamen sollte an dieser Stelle bereits dafür gesorgt werden, dass die Spiegelplatten für das Abspalten vorbereitet, also die gespiegelten Daten vorhanden sind. Dies bedeutet, dass die Plattenspiegelung spätestens an dieser Stelle aktiviert werden muss. Das erledigt ein Programm der Backup-Software, welches durch das Split-Kommando in der Datei init@.sap spezifiziert und von BRBackup-q aufgerufen wird.
Alter TS Begin Backup: Die Datenbank wird in den Backup-Mode gesetzt, so dass Oracle für Konsistenzinformationen während der Datensicherung sorgt.
Split_cmd: Da für die Spiegelung der Daten schon beim BRBackup-q gesorgt wurde, geht dieser Schritt recht schnell. Das split_cmd ist nur noch verantwortlich für das Abspalten der Spiegelplatten. Es wird als Parameter in der Datei init@.sap für den Aufruf von BRBackup konfiguriert und muss von der Backup-Software bereitgestellt werden.
Alter TS End Backup: Nur für den Zeitraum des Abspaltens muss die Datenbank im Backup-Mode sein. Denn nun sind die Daten, wie sie von Oracle konsistent für das Backup bereitgestellt wurden, auf den Spiegelplatten "eingefroren".
Backint-Interface/Backup-Software für R/3-Daten: Die Definition der Spiegelplattensicherung geht davon aus, dass die eigentliche Datensicherung über das Backint-API erfolgt. Dabei handelt es sich um R/3-Backup-Software, wie sie von verschiedenen Firmen angeboten wird und die von der SAP zertifiziert sein sollte.
Resync_cmd: Wahlweise kann von der Backup-Software noch ein Programm zur Aktivierung der Plattenspiegelung bereitgestellt werden, das von BRBackup nach Abschluss der Sicherung aufgerufen werden kann. Aber selbst wenn die Backup-Software dafür ein Programm anbieten sollte, ist es empfehlenswert, zu diesem Zeitpunkt nicht die Spiegelung zu reaktivieren, sondern die Spiegelplatten als Hot-Standby zu nutzen. Das bedeutet, dass die Datenwiederherstellung manuell auf Basis der Daten auf den Spiegelplatten und der Redolog-Dateien möglich ist, was erheblich schneller sein kann als das Lesen der Daten von Bändern.
SicherungssoftwareBei dem Konzept der Spiegelplattensicherung besteht die Konfiguration aus mehreren Softwarestufen, die für die Datensicherung wichtig sind. Bei den einzelnen Stufen wird jeweils ein gängiges Produkt angegeben, so dass die Zusammenhänge für Anwender üblicher Backup-Software klarer werden.
SAP-Kommandos: Über die SAP-BR-Tools BRBackup, BRArchive und BRRestore wird die Datensicherung und Wiederherstellung aufgerufen. Die BR-Tools rufen über die Definition von split_cmd die Synchronisation und Abspaltung der Spiegelplatten auf. Mittels Backint wird die eigentliche Datensicherung vorgenommen.
Backup-Software zur Spiegelplatten-Sicherung: Durch Backup-Software zur Spiegelplatten-Sicherung (etwa NSR-R/3-EMC von Fujitsu-Siemens Computers) werden die Programme für die Vorarbeiten beim Backup -q und das Split_cmd für BRBackup zur Verfügung gestellt. Zu den Aufgaben gehört die Steuerung der Spiegelplatten wie das Synchronisieren der Daten oder das Abkoppeln, das Zugreifbar-machen ("mounten") der Spiegelplatten am Backup-Rechner sowie das Einrichten logischer Plattenstrukturen. Nur wenn dies automatisiert abläuft, kann die nachfolgende Backint-Software die R/3-Daten problemlos aus dem Dateisystem sichern.
Backint-Software: Diese Software benötigt keine Kenntnis der Spiegelplatten. Eine Backint-Software (beispielsweise NSR-R/3) wird von vielen namhaften Backup-Softwarehäusern angeboten. Sie sorgt dafür, dass die von R/3 verwendeten Dateien gesichert beziehungsweise wiederhergestellt werden. Üblicherweise bedient es sich dabei einer Backup-Basis-Software.
Backup-Basis-Software: Die Backup-Basis-Software ist dafür zuständig, die Daten auf dem Sicherungsmedium abzulegen und die Informationen über die Sicherung und die Sicherungsmedien zu verwalten: Wann wurde was auf welchem Band gesichert? Wie lange muss das Band aufgehoben werden?
Aus Sicht des R/3-Datenbank-Servers handelt es sich dabei um "Serverless Backup".
Abb: R/3-Spiegelplattensicherung - online
Das Konzept für eine Online-Sicherung: Beim Offline-Sichern von R73-Daten kommt die Datenbank ins Spiel: Sie muss herunter- beziehungsweise hinaufgefahren werden (siehe Kasten unten). Quelle: Fujitsu-Siemens Corporation