Oracle Restoretests – Best Practice

Datenbanken enthalten oft für ein Unternehmen wichtige Daten, deren Verlust dem Unternehmen einen empfindlichen Schaden zufügen würde. Dieser Schaden kann finanzieller Natur sein, ein Imageverlust bedeuten, rechtliche Konsequenzen haben oder einen hohen Arbeitsaufwand bedeuten. Es ist daher selbstverständlich, dass diese Datenbanken vom IT Betriebsteam gesichert werden.

Sicherung mit dem Oracle Recovery Manager

Oracle Datenbanken werden heutzutage in der Regel mit dem Oracle Recovery Manager (RMAN) gesichert. RMAN ist das Mittel der Wahl, wenn es um eine zuverlässige, robuste Sicherung und eine einfache Wiederherstellung einer Oracle Datenbank geht. Standardmäßig werden die Sicherungen im Filesystem abgelegt (DISK). Über eine Media Management Schnittstelle ist RMAN aber auch in der Lage, mit Hilfe einer im Unternehmen eingesetzte Third-Party Backup-Software, wie beispielsweise Tivolo Storage Manager, Commvault, Veritas Netbackup u.a., direkt in eine Tape Library bzw. Virtuelle Tape Library zu sichern (SBT_TAPE).

Verlässlichkeit

Die Backup-Jobs, die durch einen Scheduler oder die eingesetzte Third-Party Backupsoftware gesteuert werden, werden üblicherweise vom IT-Betrieb kontrolliert, so dass fehlgeschlagene oder fehlerhafte Backups bemerkt und die Ursache behoben werden kann.

Aber kann man sich wirklich darauf verlassen, dass sich die Datenbanken tatsächlich auch wiederherstellen lassen? Nein, kann man nicht! Aus diesem Grund gehört zu jeder Backup-Strategie auch die regelmäßige Überprüfung der Wiederherstellbarkeit der Datenbank. Zu groß ist sonst die Gefahr, dass Konfigurationsfehler, Systemänderungen oder Defizite der Backup-Strategie unentdeckt bleiben und Datenverlust durch eine missglückte Wiederherstellung droht.

Risken einer Wiederherstellung

Folgenden Probleme bei einer Wiederherstellung sind beispielsweise denkbar:

• Die konfigurierte Retention Policy entspricht nicht den Unternehmensanforderungen und die gewünschten Daten lassen sich nicht wiederherstellen
• Die Sicherungsdateien sind nicht mehr vorhanden, da sie zuvor gelöscht wurden
• Die zu einer Wiederherstellung erforderlichen Metadaten sind im Controlfile nicht mehr vorhanden, da der Wert des Parameter controlfile_record_keep zu gering ist
• Die Wiederherstellung dauert zu lange, weil der verantwortliche DBA keine Routine hat und nicht weiß welche Schritte erforderlich sind
• Die Datenbank kann nicht zum gewünschten Zeitpunkt wiederhergestellt werden, dass sie offline gesichert wurde und kein Archivelogging aktiviert war
• Die Datenbank nicht ohne Datenverlust wiederhergestellt werden, da es kein aktuelles Backup des Controlfiles gibt
• Eine kritische Anwendung fällt unnötig lange aus, da die Wiederherstellung der Datenbank zu lange dauert, da RMAN nicht optimal konfiguriert ist

Bei der Nutzung von Third-Party Backup Software, kann es außerdem zu folgenden Problemen kommen:

• Die für eine Wiederherstellung erforderliche Sicherungsdateien in der Tape Library sind nicht mehr vorhanden, da sie von der Third-Party Backupsoftware bereits gelöscht wurden
• Die Berechtigung der Backupsoftware zum Zurückschreiben der Dateien auf den Server fehlt
• Notwendige Third-Party Backup-Client Passwörter sind abgelaufen
• Der Third-Party Backup-Client ist unzureichend konfiguriert

Viele der oben beschriebenen Probleme habe ich selbst schon einmal erlebt. In Verbindung mit einer Third-Party Backup Software und der damit verbundenen Sicherung über eine Media Management Schnittstelle, kommt es oft zu Fehlern, mit denen man nicht rechnet. Selbst wenn einige Probleme behoben werden können und kein Schaden entsteht, so möchte man als DBA diese dennoch gelöst wissen, bevor man unter Zeitdruck eine kritischen Datenbank wiederherstellen muss.

Möglichkeiten von Restoretests

Dass Wiederherstellungstests sinnvoll sind, ist vielen klar. Allerdings stellt sich die Frage, wie man einen solchen Wiederherstellungstest durchführen soll. Ich möchte hier einige üblichen Methoden kurz vorstellen und dann ein von mir favorisiertes Verfahren präsentieren, welches ich „Kombinierte RMAN Restore / RMAN Restore Validate“ -Methode nenne.

1. „RMAN Restore Validate“ – Methode

Mit der Validate-Option des RMAN-Restore Befehls, lässt sich prüfen, ob die für eine Wiederherstellung erforderlichen Sicherungsdateien auf dem Sicherungsmedium verfügbar sind. Es wird jedoch keine tatsächliche Wiederherstellung durchgeführt. Da keine Dateien auf den Datenbankserver zurückgeschrieben werden, bleiben unter Umständen Fehler, beispielsweise verursacht durch fehlende Berechtigungen, weiterhin unentdeckt. Aus dem genannten Grund empfehle ich, sich nicht  allein auf ein „Restore Valiate“ zu verlassen.

Beispiel:

rman target /
RMAN> restore database validate;

2. „RMAN Restore“ – Methode

Die dem Ernstfall am nahesten kommende Methode, ist die tatsächliche Wiederherstellung der Datenbank auf dem Server auf dem die Datenbank läuft. Allerdings erfordert es eine Downtime, da die zu wiederherzustellende Datenbank, für die Dauer der Wiederherstellung, nicht verfügbar ist. Es gibt aber noch einen zweiten Nachteil. Falls die Wiederherstellung nicht erfolgreich ist, mit dem man rechnen muss, ist die Datenbank unter Umständen verloren. Da man dies auf keinen Fall riskieren sollte, müsste man beispielsweise dafür sorgen, dass die Datenbank über eine zweite Methode zuvor gesichert wird. Man kann die Datenbank z.B. vor dem Test offline manuell in ein verfügbares Filesystem kopieren, um diese von dort aus bei Bedarf wiederherstellen zu können. Dies setzt aber voraus, dass ein Filesystem zur Verfügung steht auf welches man Zugriff hat und welches über genügend Freiplatz verfügt. Außerdem ist das manuelle Kopieren selbst ein fehleranfälliges Verfahren und daher nicht verlässlich genug. Deshalb empfehle ich, diese Art eines Wiederherstellungstest nur durchzuführen, wenn es tatsächlich gefordert ist und der DBA sehr sicher ist, was er da tut.

Beispiel:

RMAN> restore database;

3. „RMAN Duplicate“-Methode

Mit diesem Verfahren lässt sich eine Datenbank aus einer Sicherung auf einen zweiten Server oder auf dem selber Server in ein anderes Filesystem wiederherstellen. Dieses Methode hat den Vorteil, dass man eine tatsächliche Wiederherstellung durchführt ohne die Original-Datenbank zu überschreiben und keine Downtime benötigt. Wenn man die Datenbank auf einen zweiten Server wiederherstellt, stellt dieses Verfahren jedoch nicht sicher, dass dies auch auf dem Ursprungsserver tatsächlich funktioniert. Außerdem muss die Third-Party Software so konfiguriert sein, dass sich Backups auch auf einen andern Server als den Originalserver wiederherstellen lassen. Des Weiteren erfordert es, dass man genügend Freiplatz auf dem wiederherzustellenden Server hat, was bei sehr großen Datenbanken oft ein Problem ist.

Beispiel:

rman TARGET sys/<sys_password>@<source_database> nocatalog AUXILIARY
RMAN> duplicate target database to OCLR;

4. Kombinierte ”RMAN Restore / RMAN Restore Validate” Methode

Wie der Name schon vermuten lässt, verbindet dieses Verfahren die Methoden „RMAN Restore“ und „RMAN Restore Validate“ miteinander. Durch die Kombination werden möglichst viele potenzielle Fehler erkannt, das Risiko eines Schadens durch den Wiederherstellungstest minimiert und die Anforderungen an den Freiplatz gering gehalten. Für diesen Test ist auf dem Datenbankserver ein Verzeichnis notwendig, in welches Oracle Controlfiles und Spfile zurückgesichert werden kann.

In dem unten aufgeführten Beispiel, wird eine Wiederherstellungstest einer Datenbank mit einer Backup Retention Policy von 31 Tagen durchgeführt. Die Backups wurden über eine Media Management Schnittstelle einer Third-Party Backupsoftware in eine Tape Library gesichert. Für die Wiederherstellung von Dateien wurde auf dem Datenbankserver ein Verzeichnis /u02/app/restore_tests erstellt.

Folgende Schritte beinhaltet die Methode

A.) Tatsächliche Wiederherstellung einiger Archivelogs vom dem Tag, der maximal gemäß der Retention Policy wiederherzustellen ist:

Dadurch wird sichergestellt, dass

• sich Archivelogdateien auf dem Ursprungserver wiederherstellen lassen
• die Sicherungsdateien, die zur Erfüllung der Retention Policy tatsächlich noch vorhanden sind und nicht beispielsweise von der Third-Party Backupsoftware gelöscht wurden
• grundsätzlich eine Wiederherstellung von der Tape Library möglich ist
• RMAN so konfiguriert ist, dass eine Wiederherstellung über die Media Management Schnittstelle durch den DBA Möglich ist
• Der auf dem Datenbankserver installierte Client der Backupsoftware richtig konfiguriert ist

Beispiel Wiederherstellung der Archivelogs vor 31 Tagen (Retention Policy = 31 Tage):

run {
allocate channel ch1 type 'sbt_tape';
restore archivelog from time 'sysdate-31' until time 'sysdate-30,5';
delete noprompt archivelog from time 'sysdate-31' until time 'sysdate-30,5';
release channel ch1;
}

Die Archivelogs werden im original Archivelog Directory auf dem Datenbankserver wiederhergestellt und anschließend sofort wieder gelöscht.

B.) Tatsächliche Wiederherstellung des Spfile aus dem letzten Backup und Autobackup

Dadurch wird sichergestellt, dass

• sich das Spfile aus der letzten Sicherung auf dem Ursprungserver wiederherstellen lässt
• sich das Spfile aus dem Autobackup wiederherstellen lässt

run {
allocate channel ch1 type 'sbt_tape';
restore spfile validate;
restore spfile to '/u02/app/restore_tests/spfile.ora';
release channel ch1;
}

Das Spfile wird im Vereichnis /u02/app/restore_tests wiederhergestellt.

C.) Tatsächliche Wiederherstellung des Controlfiles aus dem letzten Backup und Autobackup

Dadurch wird sichergestellt, dass

• sich das Controlfile aus der letzten Sicherung auf dem Ursprungserver wiederherstellen lässt
• sich das Controlfile aus dem Autobackup wiederherstellen lässt

run {
allocate channel ch1 type 'sbt_tape';
restore controlfile validate;
restore controlfile to '/u02/app/restore_tests/controlfile.ctl';
restore controlfile to '/u02/app/restore_tests/controlfile_from_autobackup.ctl' from autobackup;
delete noprompt controlfilecopy "/u02/app/restore_tests/controlfile_from_autobackup.ctl";
delete noprompt controlfilecopy "/u02/app/restore_tests/controlfile.ctl";
release channel ch1;
}

Das Controlfile wird im Vereichnis  /u02/app/restore_tests wiederhergstellt und anschließend gleich wieder gelöscht.

D.) Wiederherstellung der gesamten Datenbank  (Nicht tatsächlich – nur Validate)

Dadurch wird sichergestellt, dass

• alle zur Wiederherstellung notwendigen Sicherungsdateien tatsächlich auf dem Sicherungsmedium verfügbar sind.

run {
allocate channel ch1 type 'sbt_tape';
restore database validate;
release channel ch1;
}

Beispiel-Scripte ”RMAN Restore / RMAN Restore Validate” Methode

restore_test.sh

export NLS_LANG=american
export NLS_DATE_FORMAT='DD.MM.YYYY HH24:MI:SS'

cd /u01/app/restore_tests

# Start Restoretest
rman target / @/u01/app/restore_tests/restore_test.rman | tee /u01/app/restore_tests/restore_test_`date +%d.%m.%Y_%H:%M`_$ORACLE_SID.log

# Wiederhergestellte Spfiles anschließend löschen
rm /u01/app/restore_tests/spfile.ora
rm /u01/app/restore_tests/spfile_from_autobackup.ora

restore_test.rman

# 1. Anzeige der RMAN Konfiguration (Controlfile)
show all;

# 2. Tatsächliche Wiederherstellung von Archivelogs aus dem Zeitraum der maximalen Retention (1/2 Tag)
run {
allocate channel ch1 type 'sbt_tape';
restore archivelog from time 'sysdate-31' until time 'sysdate-30,5';
delete noprompt archivelog from time 'sysdate-31' until time 'sysdate-30,5';
release channel ch1;
}

# 3. Tatsächliche Wiederherstellung des Spfile aus dem letzten Backup und Autobackup
run {
allocate channel ch1 type 'sbt_tape';
restore spfile validate;
restore spfile to '/u02/app/restore_tests/spfile.ora';
restore spfile to '/u02/app/restore_tests/spfile_from_autobackup.ora' from autobackup;
release channel ch1;
}

# 4. Tatsächliche Wiederherstellung des Controlfiles dem letzten Backup und Autobackup
run {
allocate channel ch1 type 'sbt_tape';
restore controlfile validate;
restore controlfile to '/u02/app/restore_tests/controlfile.ctl';
restore controlfile to '/u02/app/restore_tests/controlfile_from_autobackup.ctl' from autobackup;
delete noprompt controlfilecopy "/u02/app/restore_tests/controlfile_from_autobackup.ctl";
delete noprompt controlfilecopy "/u02/app/restore_tests/controlfile.ctl";
release channel ch1;
}

# 5. Wiederherstellung der gesamten Datenbank  (Nicht tatsächlich - nur Validate)
run {
allocate channel ch1 type 'sbt_tape';
restore database validate;
release channel ch1;
}