Zentralisierte Backup-Lösungen sparen Zeit, Platz und Geld. Auch Datenbanken lassen sich auf diese Weise sichern, brauchen aber die Unterstützung spezieller Software. Ein Vergleich am Beispiel von Oracle.

Es bedarf keines Blicks in die statistischen Gruselkabinette auf den Webseiten der meisten Produzenten von Backup-Software oder der Datenretter (zum Beispiel[1]), längst ist für die meisten selbstverständlich, was die Schadenszahlen belegen: Wer seine Daten nicht sichert, wird sie früher oder später verlieren. Wer seine Daten verliert, ist unter Umständen ruiniert. Allerdings soll das unvermeidliche Backup zugleich kostengünstig, sicher und im Fall des Falles schnell rekonstruierbar sein, möge sich zeitlich gut in den Produktionsablauf einfügen und leicht administrieren lassen. Das erreicht nur eine maßgeschneiderte Strategie.

Ein besonderes Problem dabei verursachen Datenbanken. Ihre Dateien, die ständig zum Schreiben geöffnet sind, lassen sich im laufenden Betrieb nicht wie gewöhnliche Files sichern. Zudem sind sie oft sehr groß, weshalb das Back-up mehrere Medien und viel Zeit erfordert. Die Applikationen, die sich aus solchen Datenspeichern bedienen, dulden auf der anderen Seite häufig keine Auszeiten. Die Software-Industrie hat auf dieses Dilemma reagiert und Lösungen für die Online-Sicherung großer Datenbanken auf zentrale Tape Libraries entwickelt. Drei davon hat das Linux-Magazin in Augenschein genommen: Module für das Online-Backup einer Oracle-Datenbank mit den Linux-Versionen von Arkeia Network Backup, Legato Networker und Veritas Netbackup.

Schon solo sicher

Oracle[2] bietet bereits ohne zusätzliche Software eine breite Palette an Schutzmaßnahmen. So ist – erstens – jederzeit eine logische Sicherung möglich, die die Tabelleninhalte exportiert. Die Wiederherstellung einer komplett ausgefallenen Datenbank (Recovery) ist auf diesem Weg allerdings nicht möglich, lediglich bestimmte Inhalte lassen sich wiedergewinnen (Restore).

Ein physisches Backup aller beteiligten Files ist – zweitens – immer und dabei einfach durchführbar, wenn die Datenbank zuvor heruntergefahren wird (Offline oder Cold Backup). Jedoch fehlt meist die Zeit für die damit verbundene Zwangspause. Selbst wenn kein Betrieb rund um die Uhr nötig ist, sprengen große Datenmengen leicht das nächtliche Zeitfenster. Schließlich würde auch das Recovery eine ausgiebige Auszeit bedingen, die oft nicht zu tolerieren ist. Für Oracle-Datenbanken, die im so genannten Noarchivelog-Modus arbeiten, die ihre Redo-Logs also nicht sichern, bevor sie überschrieben werden, ist die Offline-Sicherung allerdings die einzige Möglichkeit.

Online-Backup manuell

Läuft Oracle im Archivelog-Modus, ist – drittens – jederzeit eine manuelle oder skriptgesteuerte Online-Sicherung möglich, bei der die Tablespaces in einen speziellen Backup-Modus versetzt werden. Danach kann der Admin die zugehörigen Datenfiles mit Betriebssystemmitteln kopieren:

alter tablespace Tablespacename begin backup;
# Kopie der Datenfiles auf
# Betriebssystemebene, Muster:
# cp /oracle/data/datafile_xy /backup/datafile_xy.bck
alter tablespace Tablespacename end backup;
archive log current;

Mit Hilfe der gesicherten Dateien und der archivierten Logs ist die Datenbank nun wiederherstellbar. Parameterfiles (»init.ora«, »SPFILE«), ein Controlfile und die Logs muss man zuvor zusätzlich auf ein sicheres Medium retten.

Als vierte Möglichkeit bietet Oracle dem Administrator ein mächtiges, seit der Version 8 stetig vervollkommnetes Tool, den Backup und Recovery Manager, kurz RMAN. Er kann interaktiv, per Kommandofile oder über den Oracle Enterprise Manager (OEM) bedient werden und beherrscht viele fortgeschrittene Sicherungstechniken. So bezieht er etwa nur tatsächlich verwendete Blöcke in das Backup ein, kann die Daten komprimieren und inkrementell sichern – was jeweils Zeit und Platz spart.

Er speichert selbstständig alle für eine Wiederherstellung benötigten Files und kann sie ab Version 10g in einem speziellen Directory sammeln (Flashback Recovery Area). Er erkennt und repariert nach Möglichkeit defekte Blöcke und versteht sich auf das Multiplexen mehrerer Datenströme auf ein Device. Außerdem verwaltet RMAN noch eine History und wichtige Metadaten aller Backups und hebt auf Wunsch auch die benötigten Skripte in einem eigenen Recovery Catalog auf.

Umgang mit den Medien

Auf Hilfe ist er allerdings dort angewiesen, wo die Backups zentralisiert werden und eine große Tape Library die Medien verwaltet. Hier kommen – fünftens – die schon erwähnten Module für Enterprise-Backup-Software ins Spiel. Sie implementieren eine spezielle Library (MML, Media Management Library), die RMAN als Schnittstelle dient. Damit ergibt sich stets der folgende schematische Ablauf (Abbildung 1):

• Die Backup-Software beziehungsweise ein Cronjob oder der
  Administrator starten RMAN mit einem passenden Kommandofile.
• RMAN übernimmt das Online-Backup der Datenbank, schreibt
  die Daten aber nicht auf ein Medium, sondern übergibt sie an
  das MML-Modul der Backup-Software.
• Die Backup-Software kümmert sich darum, dass die richtigen
  Medien in den richtigen Laufwerken der Tape Library liegen, und
  speichert die empfangenen Daten dort ab. Sie sorgt für die
  zyklische Wiederverwendung der Bänder nach einer bestimmten
  Verfallszeit (Retention Policy), wechselt und labelt die Medien
  automatisch, koordiniert parallele Backups, überwacht den
  Ablauf und bietet dem Administrator eine grafische
  Bedienoberfläche. Außerdem verwaltet sie einen eigenen
  Index aller gesicherten Files und aller verwendeten Bänder,
  der bei einem Recovery den schnellen Zugriff auf die
  benötigten Daten garantiert.

Abbildung 1: Der prinzipielle Ablauf einer Oracle- Online-Sicherung im Zusammenspiel mit den getesteten Backup-Programmen. RMAN übernimmt Backup und Recovery, sein Partner das Medienmanagement.

01 oracle@toshi:~> $ORACLE_HOME/bin/rman target sys/******@TESTDB cmdfile './full_backup.txt'
02 
03 Recovery Manager: Release 10.1.0.3.0 - Production
04 
05 Copyright (c) 1995, 2004, Oracle.  All rights reserved.
06 
07 connected to target database: TESTDB (DBID=2326866451)
08 
09 RMAN> run {
10 2>      allocate channel t1 type 'SBT_TAPE';
11 3>      allocate channel t2 type 'SBT_TAPE';
12 4>
13 5>      send 'NSR_ENV=(NSR_SERVER=toshi.linuxnewmedia.de,
14 6>                     NSR_DATA_VOLUME_POOL=Default)';
15 7>
16 8>      backup full filesperset 4
17 9>         format '/FULL_%d_%u/'
18 10>     (database);
19 11>
20 12>     release channel t1;
21 13>     release channel t2;
22 14> }
23 15>
24 using target database controlfile instead of recovery catalog
25 allocated channel: t1
26 channel t1: sid=139 devtype=SBT_TAPE
27 channel t1: NMO v4.1.0.0
28 
29 allocated channel: t2
30 channel t2: sid=124 devtype=SBT_TAPE
31 channel t2: NMO v4.1.0.0
32 
33 sent command to channel: t1
34 sent command to channel: t2
35 
36 Starting backup at 13-JAN-05
37 channel t1: starting full datafile backupset
38 channel t1: specifying datafile(s) in backupset
39 input datafile fno=00001 name=/data1/oradata/TESTDB/system01.dbf
40 input datafile fno=00002 name=/data1/oradata/TESTDB/undotbs01.dbf
41 input datafile fno=00006 name=/data1/oradata/TESTDB/convert_tbs.dbf
42 channel t1: starting piece 1 at 13-JAN-05
43 channel t2: starting full datafile backupset
44 channel t2: specifying datafile(s) in backupset
45 input datafile fno=00003 name=/data1/oradata/TESTDB/sysaux01.dbf
46 input datafile fno=00005 name=/data1/oradata/TESTDB/example01.dbf
47 input datafile fno=00004 name=/data1/oradata/TESTDB/users01.dbf
48 channel t2: starting piece 1 at 13-JAN-05
49 channel t2: finished piece 1 at 13-JAN-05
50 piece handle=/FULL_TESTDB_0hga3mse/ comment=API Version 2.0,MMS Version 4.1.0.0
51 channel t2: backup set complete, elapsed time: 00:02:15
52 channel t2: starting full datafile backupset
53 channel t2: specifying datafile(s) in backupset
54 including current controlfile in backupset
55 channel t2: starting piece 1 at 13-JAN-05
56 channel t2: finished piece 1 at 13-JAN-05
57 piece handle=/FULL_TESTDB_0iga3n0l/ comment=API Version 2.0,MMS Version 4.1.0.0
58 channel t2: backup set complete, elapsed time: 00:00:07
59 channel t2: starting full datafile backupset
60 channel t2: specifying datafile(s) in backupset
61 including current SPFILE in backupset
62 channel t2: starting piece 1 at 13-JAN-05
63 channel t2: finished piece 1 at 13-JAN-05
64 piece handle=/FULL_TESTDB_0jga3n0t/ comment=API Version 2.0,MMS Version 4.1.0.0
65 channel t2: backup set complete, elapsed time: 00:00:07
66 channel t1: finished piece 1 at 13-JAN-05
67 piece handle=/FULL_TESTDB_0gga3msd/ comment=API Version 2.0,MMS Version 4.1.0.0
68 channel t1: backup set complete, elapsed time: 00:02:56
69 Finished backup at 13-JAN-05
70 
71 released channel: t1
72 released channel: t2
73 
74 Recovery Manager complete.

01 toshi:/home/oracle # nsrinfo -n oracle toshi
02 scanning client `toshi' for all savetimes from the oracle namespace
03 /FULL_TESTDB_0jga3n0t/, date=1105618957 Thu Jan 13 13:22:37 2005
04 /FULL_TESTDB_0iga3n0l/, date=1105618950 Thu Jan 13 13:22:30 2005
05 /FULL_TESTDB_0hga3mse/, date=1105618815 Thu Jan 13 13:20:15 2005
06 /FULL_TESTDB_0gga3msd/, date=1105618814 Thu Jan 13 13:20:14 2005
07 4 objects found
08 
09 toshi:/home/oracle # mminfo -v -c toshi
10  volume     client          date     time        size ssid      fl   lvl name
11 VOLUME01    toshi.linuxnewmedia.de 13.01.2005 13:20:14 376 MB 4041631616 cb full /FULL_TESTDB_0gga3msd/
12 VOLUME01    toshi.linuxnewmedia.de 13.01.2005 13:20:15 274 MB 4024854400 cb full /FULL_TESTDB_0hga3mse/
13 VOLUME01    toshi.linuxnewmedia.de 13.01.2005 13:22:30 3073 KB 4008077318 cb full /FULL_TESTDB_0iga3n0l/
14 VOLUME01    toshi.linuxnewmedia.de 13.01.2005 13:22:37 257 KB 3991300111 cb full /FULL_TESTDB_0jga3n0t/

Legato Networker

Das Produkt von Legato[3], einer Firma, die seit 2003 zum Imperium von EMC gehört, lässt sich aus einer Reihe RPM-Packages schnell und problemlos installieren. Als Schnittstelle zu RMAN muss der Admin im nächsten Schritt die programmspezifische MML-Library »libobk« in Oracles Bibliotheksverzeichnis verlinken. Danach richtet er die verwendete Hardware ein. Weiter muss die Backup-Software wissen, was sie wann wohin sichern soll, welche Medien und Laufwerke sie verwenden und wie lange sie die Metadaten der Sicherung aufbewahren soll. Die leicht bedienbare grafische Oberfläche unterstützt den Administrator bei jeder diesen Konfigurationsarbeiten gut.

Diese Oberfläche muss er allerdings verlassen, sobald es um die Kommandofiles für RMAN geht. Legato liefert zwar einige Beispielskripte mit der Programmdokumentation, überlässt es ansonsten aber dem Anwender, sich passende Befehlsdateien für Oracles Backup-Tool zurechtzubasteln.

Die Datenbanksicherung lässt sich manuell oder automatisch starten. Im zweiten Fall ruft der Networker-Server über eine Kette aus Daemons und Skripten auf der Client-Seite schließlich RMAN auf. Ein einfaches Backup-Skript und den Ablauf einer Sicherungssession zeigt Listing 1. Am Ende der Sicherung ergänzt Networker die Metadaten in File-Index und Medien-Datenbank. Die Einträge lassen sich von der Kommandozeile aus abfragen (Listing 2).

Das Recovery gestaltet sich analog. Ein beispielhaftes RMAN-Skript zum Wiederherstellen eines Tablespace zeigt Listing 3. Der Ablauf einer Session des Oracle Agent lässt sich wie jede andere Sicherung im Hauptfenster des Programms mitverfolgen (Abbildung 2).

Auch Arkeia[4] stellt für die Linux-Version seiner Backup-Software RPM-Pakete bereit. Die Installation ähnelt damit der beschriebenen Prozedur, die Einrichtung des Programms geht leicht von der Hand und ist gut dokumentiert.

Abbildung 2: Eine laufende Backup-Session des Oracle Agent für Legato Networker lässt sich in der grafischen Oberfläche mitverfolgen.

Abbildung 3: Arkeia Network Backup beim Sichern der Testdatenbank. Ein Tacho informiert über die aktuelle Transferrate.

Abbildung 4: Netbackup präsentiert Dateien und Datenbankobjekte in einer konsistenten Ansicht, was die Bedienung wesentlich vereinfacht.

Arkeia Network Backup

Daneben gilt es, ein Konfigurationsfile anzupassen, dass einige Parameter für Backup-Software und RMAN enthält. Die kleine Mühe wird durch noch einfachere Kommandofiles für den Recovery Manager belohnt. Im einfachsten Fall reicht jetzt für ein Vollbackup:

run {
allocate channel t1 type 'sbt_tape';
backup database;
release channel t1;
}

Sicherungsläufe muss der Arkeia-Admin immer manuell oder durch Skripte starten. Für periodische Sicherungen kann er den Unix-Dienst Cron einspannen. Der programminterne Scheduler, der gewöhnliche Filesystem-Backups zu bliebigen Zeiten zur Arbeit ruft, ist allerdings nicht auf die Kommunikation mit RMAN vorbereitet.

Veritas Netbackup

Die beste Integration des Oracle Agent und die einfachste Bedienung in diesem Vergleich bot Netbackup von Veritas. Das beginnt schon bei der skriptgesteuerten Installation, die Handarbeit überflüssig macht. Der Installer ermittelt beispielsweise selbst die verwendete Oracle-Version und verlinkt die passende MML-Library automatisch.

Ein Stolperstein auf dem Weg zum ersten Backup war im Test aber doch aus dem Weg zu räumen. Beim Aufspielen der Software ergänzt das Einrichtungsprogramm auch Einträge in der Konfigurationsdatei des Internet Service Daemon Xinetd. Allerdings war dieser Dienst auf dem verwendeten Suse Enterprise Server (SLES 9) per Default deaktiviert. In der Folge startete unter anderem ein für die Benutzerauthentifikation erforderlicher Service nicht, was zum Abbruch der Installation führte. Die dabei produzierte Fehlermeldung wies auf mangelnde Berechtigungen und damit nicht unbedingt auf die Ursache des Problems hin.

Nachdem diese Klippe umschifft war, halfen Assistenten bei der Konfiguration aller nötigen Parameter bis zum ersten Backup. Damit gelingt dieser Schritt sicher auch weniger erfahrenen Admins ohne langes Handbuchstudium. Anschließend präsentiert Netbackup im Hauptfenster seines grafischen Administrationswerkzeugs alle für ein Backup in Frage kommenden Datenbankobjekte auf die gleiche Weise wie die Dateien des Filesystems (Abbildung 4).

In der aufklappbaren Baumstruktur lassen sich nun die gewünschten Schemata, Tablespaces oder Tabellen für das Backup oder Recovery selektieren. Danach generiert die Software automatisch ein passendes RMAN-Skript, das sich einmalig verwenden oder als Template für gleichartige Aufgaben abspeichern lässt. Zwar könnte ein gewitzter Admin manuell mehr Feinheiten und Kniffe in die Kommandofiles einbauen, die automatisch erzeugten reichen aber für die überwiegende Anzahl der Anwendungsfälle völlig aus und sind dafür um Klassen einfacher und sicherer zu handhaben. Bei Bedarf kann er sie später immer noch manuell editieren.

Fazit

Ein zentralisiertes Online-Backup einer Oracle-Datenbank gelingt unter Linux ohne größere Schwierigkeiten. Die Arbeitsteilung zwischen Datenbank und Sicherungssoftware und der prinzipielle Ablauf sind immer gleich. Die verglichenen Produkte unterscheiden sich dennoch merklich. Die beste Integration der Oracle-Komponente, die leichteste Erstkonfiguration und den einfachsten Umgang mit Oracles Recovery Manager bietet Netbackup von Veritas.

01 Skript
02 run {
03 
04         allocate channel t1 type 'SBT_TAPE';
05         allocate channel t2 type 'SBT_TAPE';
06 
07         send 'NSR_ENV=(NSR_SERVER=toshi.linuxnewmedia.de,
08                        NSR_DATA_VOLUME_POOL=Default)';
09 
10         sql 'alter tablespace users offline immediate';
11 
12         restore (tablespace users);
13 
14         sql 'alter tablespace users online';
15 
16         release channel t1;
17         release channel t2;
18 }