Oracle Backup und Recovery: Backupstrategien
Ein wichtiger Punkt bei der Wahl der richtigen Backupstrategie ist natürlich die Verhältnismäßigkeit zwischen den Anforderungen, die an das Recovery gestellt werden und den mit dem geplanten Backupkonzept verbundenen Kosten, Ressourcen und sonstigen Aufwand.
Bei der Planung einer Backupstrategie sollte im Vorfeld ermittelt werden, welche Anforderungen an das Recovery im Fehlerfall gestellt werden und zu welchen Zeiten die Datenbank für ein Offline-Backup beendet werden kann. Folgende Punkte spielen eine Rolle bei der Entscheidung für eine Backupstrategie:
- Wie lange darf die Wiederherstellung dauern?
Ein wichtiges Kriterium bei der Backupstrategie ist die Zeit, die für das Zurückspielen der Dateien vom Backup-Medium und das anschließende Nachfahren der benötigten Daten aus den Redolog-Dateien bis zum Öffnen der Datenbank höchstens in Anspruch nehmen darf. - Kann die Datenbank offline gesichert werden?
Häufig ist dies nur nachts oder am Wochenende möglich. Muss die Datenbank 7x24-Stunden in der Woche zur Verfügung stehen, so kann das Backup nur online erfolgen. Bei vielen Produktiv-Systemen gibt es jedoch vereinbarte Wartungsfenster, in denen ein Offline-Backup durchgeführt werden kann. Außerdem gibt es noch die Möglichkeit eines Split-Mirror-Backup und des Backup einer Standby-Datenbank. - Wie groß ist das zu erwartende Datenvolumen?
Bei sehr großen Datenbanken müssen durchsatzstarke und entsprechend dimensionierte Sicherungsmedien und eine leistungsstarke Hardware (Bandlaufwerk, Netzwerk, CPU, Plattenkontroller, etc.) zum Einsatz kommen, um das große Datenvolumen sowohl beim Backup als auch beim Restore bewältigen zu können.
Backups sollten nie auf den Platten gespeichert werden, auf denen sich die Originale der Daten-Dateien, Redolog-Dateien oder Control-Dateien befinden. Wenn mehr als ein Backup der Datenbank auf Platte gesichert wird, sollten auch diese Backups auf unterschiedlichen Plattenbereichen liegen. Backups sollten zudem regelmäßig auf ihre Konsistenz und Lesbarkeit geprüft werden! Jede Datenbank, die wichtige, sich ändernde Daten enthält, sollte nur im ARCHIVELOG-Modus betrieben werden.
Backuparten
Grundsätzlich wird zwischen zwei Backuparten unterschieden, dem physischen und dem logischen Backup. Wie der Name schon sagt, wird bei einem physischen Backup die auf den Platten vorhandene Blockstruktur 1:1 auf ein Sicherungsmedium kopiert, wohingegen bei einem logischen Backup die logische Struktur und der Inhalt von Datenbank-Objekten in eine binäre Datei geschrieben werden.
Physische wie logische Backups können dabei den gesamten Datenbestand oder nur einen Teil der Datenbank beinhalten. Partielle physische Sicherungen erfolgen dabei auf Datei- beziehungsweise Blockebene, wohingegen bei partiellen logischen Backups nur Teile der logischen Struktur einer Datenbank gesichert werden, also zum Beispiel eine oder mehrere Tabellen.
Das physische Backup lässt sich noch weiter in Vollbackup und inkrementelles Backup unterteilen und kann sowohl offline als auch online erfolgen.
Physische und logische Backups
Physisches Backup
Das physische Backup einer Oracle-Datenbank ist im Produktivbetrieb eine zwingende Notwendigkeit, um im Fehlerfall beispielsweise bei Ausfall des Betriebssystems, einer oder mehrerer Festplatten oder des Rechners einen konsistenten Datenbestand rekonstruieren zu können.
Physische Backups sind Sicherungen der Datenbank-Dateien, wie Daten-Dateien, Control-Dateien und Offline Redolog-Dateien. Dazu gibt es zwei grundsätzliche Sicherungsmöglichkeiten, die hier im Einzelnen beschrieben werden sollen.
- Offline-Backup: Die Datenbank ist beendet. Der Zugriff auf die Daten ist nicht möglich.
- Online-Backup: Die Datenbank ist geöffnet und steht uneingeschränkt zur Verfügung. Die Datenbank muss sich im ARCHIVELOG-Modus befinden!
Ein Online-Backup kann nur dann zur Wiederherstellung der Daten benutzt werden, wenn auch die während des Backups angefallenen Redolog-Dateien zur Verfügung stehen. Die Offline Redolog-Dateien sollten deshalb unabhängig vom Backupzyklus laufend gesichert werden.
Ein Offline-Backup ist oft nötig, wenn mehrere Datenbanken oder Anwendungen, die ändernd auf Daten zugreifen, in einem Systemverbund stehen und ein konsistenter Aufsetzpunkt innerhalb dieses Verbunds sichergestellt werden muss. Dazu müssen alle beteiligten Systeme zur gleichen Zeit konsistent angehalten oder beendet und anschließend gesichert werden. So wird gewährleistet, dass im Fall eines Restore der gesamten Systemlandschaft keine Inkonsistenzen auftreten. Die beiden grundlegenden physischen Sicherungsverfahren Offline- und Online-Backup bieten neben einer Voll-Sicherung noch weitere Möglichkeiten der Datensicherung.
Typen physischer Backups
| Backup-Typ | Beschreibung |
|---|---|
| Offline | Sicherung bei geschlossener Datenbank |
| Online | Sicherung bei geöffneter Datenbank |
| Voll-Sicherung | Sicherung aller für eine Wiederherstellung der Datenbank erforderlichen Dateien |
| Partielle Sicherung | Sicherung einzelner Tablespaces oder Daten-Dateien |
| Inkrementelle Sicherung | Sicherung der seit dem letzten Backup veränderten Datenbank-Blöcke |
Während eines Offline- oder Online-Backups können auch nur Teilbereiche der Datenbank, wie ein oder mehrere Daten-Dateien oder Tablespaces gesichert werden. Je nach Größe und Backup-Zeit der Datenbank kann es durchaus vorkommen, dass innerhalb des zur Verfügung stehenden Zeitrahmens keine Komplettsicherung der Datenbank möglich ist. Bei partiellen Backups muss darauf geachtet werden, dass innerhalb eines Backupzyklus jede zur Datenbank gehörende Datei mindestens einmal gesichert wird.
Bei inkrementellen Backups werden nur die Datenbank-Blöcke gesichert, die seit dem letzten inkrementellen oder vollständigen Backup geändert wurden. Dies kann über die SCN – die System Change Nummer – die in jedem Block einer Daten-Datei steht, bestimmt werden. Ein inkrementelles Backup kann nur durchgeführt werden, wenn diesem und eventuell vorausgegangenen inkrementellen Sicherungen ein vollständiges Backup zugrunde liegt. Die Möglichkeit eines inkrementellen Backups bietet auch der Oracle Recovery Manager, kurz RMAN.
Logische Backups
Im Gegensatz zu physischen Backups werden bei logischen Sicherungen nicht die Daten-Dateien und/oder physischen Blöcke und Strukturen gesichert, sondern die Inhalte der Datenbankobjekte und die dazugehörige logische Struktur. Dabei werden die Definitionen der Objekte – wie Tabellen, Indizes, Kommentare und Constraints – extrahiert und in die Dump-Datei auf Platte oder Band geschrieben. Anschließend werden die Tabelleninhalte ausgelesen und in die Dump-Datei geschrieben.
Mithilfe logischer Backups ist es möglich, logische Strukturen und Inhalte wiederherzustellen, zum Beispiel nach dem versehentlichen Löschen einer Tabelle.
Vollbackup und inkrementelles Backup
Vollbackup und inkrementelles Backup sind zwei Möglichkeiten eines physischen Backups und finden beim logischen Backup keine Anwendung.
Vollbackup
Ein Vollbackup bildet die Grundlage für einen erfolgreichen Restore und ein anschließendes Recovery, da dabei alle zum Backup-Zeitpunkt belegten Blöcke gesichert werden. Vollbackup heißt nicht, dass dabei zwingend die gesamte Datenbank gesichert wird. Ein Vollbackup kann beispielsweise auch aus nur einem Tablespace oder einer einzigen Daten-Datei bestehen.
Ein Vollbackup darf nicht mit einem RMAN full backup verwechselt werden, da bei RMAN sowohl ein full backup wie auch ein inkrementelles Backup Level 0 einem Vollbackup entsprechen.
Inkrementelles Backup
Bei einem inkrementellen Backup werden die seit dem letzten Vollbackup oder inkrementellen Backup geänderten Daten gesichert. Voraussetzung für ein inkrementelles Backup (oder inkrementelles Backup Level 1 bei RMAN) ist daher immer ein Vollbackup oder ein oder mehrere inkrementelle Backups, denen wiederum ein Vollbackup zugrunde liegt.
Wie auch beim Vollbackup, kann ein inkrementelles Backup aus den geänderten Blöcken der ganzen Datenbank oder aus Teilen davon bestehen. Inkrementelle Backups können differentiell oder kumulativ sein. Sie können entweder auf dem vorangegangenen inkrementellen Backup (differentiell) oder auf dem letzten Vollbackup (kumulativ) aufsetzen.
Kumulative inkrementelle Backups haben den Vorteil, dass zusätzlich zum Vollbackup nur ein inkrementelles Backup zurückgesichert werden muss. Der Nachteil besteht darin, dass der Umfang des kumulativen inkrementellen Backups mit wachsendem zeitlichen Abstand zum zugrunde liegenden Vollbackup stetig zunimmt.
Übersicht der Tools
Tools für ein logisches Backup
- Oracle Export und Import Utilities
Bis einschließlich Oracle 9i standen für logische Backups nur der Oracle Export (exp) und Import (imp) zur Verfügung. Mit Oracle 11g wird Export zwar noch ausgeliefert, jedoch nicht mehr unterstützt. - Oracle Data Pump
Seit der Version 10g bietet Oracle zusätzlich das Dienstprogramm Data Pump für den Export und Import. Die Handhabung von Data Pump Export/Import ist ähnlich der des konventionellen Export/Imports. Jedoch bietet Data Pump funktionale Erweiterungen sowie eine verbesserte Performance.
Diese Tools (exp/imp und expdp/impdp) schreiben die Daten beim Export in binäre Dateien. Die Dateien, die von Oracle Data Pump Export erzeugt werden, sind dabei nicht mit denen des ursprünglichen Exports kompatibel.
Tools für ein physisches Backup
- Oracle Recovery Manager (RMAN):RMAN, bereits mit Oracle 8 eingeführt, bietet sehr umfangreiche Möglichkeiten für das Backup, Restore und Recovery.
- Alternativ dazu können Backups auch benutzerverwaltet durchgeführt werden. Das bedeutet, dass die für ein konsistentes Backup benötigten Dateien manuell, skriptgesteuert oder mithilfe von Drittanbietertools gesichert werden.
Aufbewahrungsrichtlinien
Die Aufbewahrungsrichtlinien setzen die Regeln fest, welche Backups erhalten werden müssen, um Anforderungen an ein Recovery zu erfüllen. Die Aufbewahrungsrichtlinien können datenredundanz- oder zeitbasiert sein. Bei datenredundanzbasierten Vorgaben muss eine bestimmte Anzahl unterschiedlicher Backups jeder Datei vorgehalten werden. Dagegen handelt es sich bei zeitfensterbasierten Aufbewahrungsrichtlinien um bestimmte Aufbewahrungsfristen (z. B. eine Woche oder ein Monat). Sie stellen sicher, dass alle nötigen Backups vorhanden sind.
Bei Verwendung beider Richtlinientypen kann mit einem Point-In-Time Recovery jeder Zeitpunkt und damit jeder konsistente Datenbestand seit dem ältesten noch verfügbaren Backup wiederherstellt werden, sofern noch alle Offline Redolog-Dateien zwischen dem Startzeitpunkt des Backups und dem Zielzeitpunkt des Point-In-Time Recovery vorhanden sind.
Zusätzlich müssen meist aus Revisions- oder Archivierungsgründen auch Langzeitsicherungen mit Aufbewahrungsfristen von mehreren Jahren durchgeführt werden.
Backupzyklen
Die Art und Häufigkeit von Backups wird meist durch die Häufigkeit und das Volumen der Datenbankänderungen, wie zum Beispiel das Anlegen und Löschen von Tabellen oder das Ändern der Tabellendaten bestimmt. Je häufiger Daten in der Datenbank verändert werden und je größer das geänderte Datenvolumen ist, desto häufiger sollten Backups gezogen werden, um im Recoveryfall die Ausfallzeiten zu verkürzen.
Wenn zusätzlich zu den Vollsicherungen auch inkrementelle Sicherungen durchgeführt werden, so kann es durchaus ausreichen, einmal wöchentlich den gesamten Datenbestand entweder offline oder online zu sichern. Inkrementelle Backups können beispielsweise mit Hilfe des Oracle Recovery Managers gezogen werden. Auch können häufigere Backups von Tablespaces oder einzelner Daten-Dateien, die sehr vielen Änderungen unterliegen, in manchen Situationen die Recovery-Zeiten verkürzen. Zusätzlich zu den geplanten Backups müssen sämtliche Offline Redolog-Dateien, die während des Datenbankbetriebs geschrieben werden, ohne Unterbrechung gesichert werden.
Zusätzliche Backups
Außer den fest eingeplanten Backups gibt es auch Spezialfälle, die ein Backup erfordern, damit es im Fehlerfall nicht zu einem Datenverlust kommt.
- Vor und/oder nach Strukturänderungen der Datenbank:
Unmittelbar nach dem Erweitern oder Neuanlegen eines Tablespace ebenso wie nach dem Umbenennen von Daten-Dateien sollten die betroffenen Daten-Dateien gemeinsam mit einer Kopie der Control-Datei gesichert werden. Wurde ein Tablespace gelöscht, sollte anschließend die Control-Datei gesichert werden.
Die Control-Datei sollte außerdem nach jedem Hinzufügen, Löschen oder Umbenennen von Redolog-Gruppen oder Redolog-Dateien gesichert werden. Dies hat den Vorteil, dass bei einem Recovery eines früheren Backups über diesen Zeitpunkt hinweg, die aktuelle wie auch die Sicherungskopie der Control-Datei bereits die Informationen über die neuen oder geänderten Dateien beinhaltet. - Vor und nach einem Datenbank-Upgrade oder nach dem Einspielen von Oracle-Patches:
Wird ein Oracle-Releasewechsel durchgeführt oder ein neues Patchset eingespielt, so empfiehlt es sich, unmittelbar vor der Software-Änderung eine Komplettsicherung der Datenbank und der Oracle-Software (Windows: auch die Registry-Einträge) durchzuführen, um im Fall des Scheiterns des Software-Updates die Datenbank zurücksetzen zu können. Nach dem erfolgreichen Software-Update muss wiederum eine Komplettsicherung der Datenbank und der Oracle-Software stattfinden. - Nach allen NOLOGGING-Operationen:
Wird ein direct path load zum Bestücken der Datenbank durchgeführt, so werden keine Logging-Informationen in die Redolog-Dateien geschrieben. Daher ist es nicht möglich, diese Änderungen aus einem früheren Backup wiederherzustellen und anschließend ein Recovery der Daten durchzuführen. Ebenso verhält es sich beim Anlegen von Tabellen oder Indizes mit der NOLOGGING-Option. Deshalb sollten nach allen Datenbank-Aktivitäten, bei denen keine Redo-Daten geschrieben werden, die gesamte Datenbank, zumindest jedoch die betroffenen Tablespaces oder Daten-Dateien gesichert werden.
Sicherungsnetzwerk
Ein wichtiger Aspekt bei der Planung von Backup und Restore in Bezug auf Sicherheit, Performance und Ausfallzeiten liegt in den leistungsstarken und redundant ausgelegten Komponenten, die für das Sichern und Wiederherstellen der Daten genutzt werden. Dazu gehört unter anderem auch das Netzwerk.
Um den Datenbankbetrieb durch Online-Sicherungen möglichst wenig zu beeinträchtigen und um die Backup- und Restore-Zeiten so kurz wie möglich zu halten, sollte für die Sicherung ein eigenes, entsprechend leistungsfähiges Netz zur Verfügung stehen. Dadurch kann auch beim Restore der größtmögliche Durchsatz erreicht werden. Dieses Netz sollte exklusiv für diesen Datentransfer reserviert sein. Es muss natürlich im Fehlerfall auf ein anderes Netz ausgewichen werden können, um die Sicherungen bei längeren Ausfallzeiten SLA-konform durchführen zu können.
Dies ist der erste Teil einer Artikelserie zu Oracle Backup und Recovery. Der nächste Artikel befasst sich mit Grundlagen des physischen Backups
Publikationen
- Oracle Backup und Recovery - Das Praxisbuch - Für alle Versionen bis einschließlich 11g Edition Oracle
