Bitte recht freundlich: Snapshots als Sicherungskonzept

Diese Artikelreihe erläutert, welche Vorteile der Betrieb von Oracle Datenbanken auf NetApp Storage bieten kann. Im ersten Teil beleuchten wir, wie man mit Hilfe von Snapshots - einer wichtigen Funktion von NetApp Filern - Oracle Datenbanken sichern und wiederherstellen kann.

Abb. 1: Vergleich der Dateisystemstände zu verschiedenen Zeitpunkten. Abb. 2: Online Backups über NetApp Snapshots. ontap-1> snap list oracle_data Volume oracle_data working... %/used %/total date name --------- --------- ------------ -------- 28% (28%) 0% ( 0%) Dec 16 14:01 backup_20081216_140000 45% (30%) 0% ( 0%) Dec 16 10:00 backup_20081216_100000 56% (30%) 1% ( 0%) Dec 16 08:02 backup_20081216_080000 63% (30%) 1% ( 0%) Dec 15 18:00 backup_20081215_180000 68% (30%) 1% ( 0%) Dec 15 14:01 backup_20081215_140000 72% (28%) 1% ( 0%) Dec 15 10:00 backup_20081215_100000 ontap-1> Tue Dec 16 15:41:46 GMT 2008 ontap-1> snap restore -s backup_20081215_140000 oracle_data WARNING! This will revert the volume to a previous snapshot. All modifications to the volume after the snapshot will be irrevocably lost. Volume oracle_data will be made restricted briefly before coming back online. Are you sure you want to do this? yes You have selected volume oracle_data, snapshot backup_ 20081215_140000 Proceed with revert? yes Volume oracle_data: revert successful. ontap-1> Tue Dec 16 15:42:15 GMT 2008 Abb. 3: Auflistung der Snapshots eines Oracle Datenbankvolumes. Im Anschluss daran wird das Volume auf den Stand vom 15.12. 14:00 Uhr zurückgesichert. Die Größe des Volumes beträgt dabei ca. 1.5 TB. Dauer der Rücksicherung ca. 30 Sekunden. Abb. 4: Restore über Snapshots. Sicherung Oracle RMAN (typisches Szenario; Sa = Level 0; Mo - Fr = Level 1) NetApp Snapshots Sa RMAN Level 0 1000 MB Snapshot 0 MB Mo RMAN Level 1 100 MB Snapshot 100 MB Di RMAN Level 1 100 MB Snapshot 100 MB Mi RMAN Level 1 100 MB Snapshot 100 MB Do RMAN Level 1 100 MB Snapshot 100 MB Fr RMAN Level 1 100 MB Snapshot 100 MB Sa (keine Änderungen von Fr auf Sa) RMAN Level 0 1000 MB Snapshot 0 MB Volumen   2500 MB   500 MB Abb. 5: Vergleich der Backup-Volumen zwischen Oracle RMAN und NetApp Snapshots.

Sicherung als große Herausforderung

Die Sicherung großer Datenbanken ist auch heutzutage noch problematisch. Zwar stellen die meisten Datenbankhersteller Werkzeuge zur Sicherung ihrer Produkte zur Verfügung (z. B. RMAN bei Oracle), allerdings bieten diese Lösungen nicht immer die gewünschte Performance, um große Datenmengen in einer angemessenen Zeit zu sichern oder wiederherzustellen. Beim Einsatz von NetApp Filern können die hier verfügbaren Snapshots eine brauchbare Alternative sein.

NetApp Storage - eine mögliche Alternative

Der Betrieb von Oracle Datenbanken auf NetApp Storage ist mittlerweile weit verbreitet [1 - 3]. Die Filer können sowohl in NAS- als auch SAN-Umgebungen über diverse Protokolle (NFS, CIFS, iSCSI oder FibreChannel) problemlos integriert werden. Gängige Praxis ist es, mehrere Volumes (oder LUNs) für die unterschiedlichen Datenbank-Dateiarten auf einem Filer einzurichten und z. B. über NFS Mounts an den Datenbankserver zu binden. So macht es beispielsweise Sinn, zu der effizienten Administration die Datenbankfiles (DBF) in ein anderes Volume als die Redologs zu legen. Zusätzlich kann man noch weitere Bereiche für die Oracle Binaries und/oder archivierten Logfiles auf dem Filer einrichten.

Snapshot

Besonders interessant an den Storage-Systemen der Firma NetApp ist die Snapshot-Technologie. Diese kann genutzt werden, um Datenbereiche schnell und verlässlich zu sichern - und viel wichtiger - wiederherzustellen. Hinter dem Begriff des Snapshots verbirgt sich nichts anderes als der eingefrorene Zustand eines Dateisystems (Momentaufnahme). Dies bedeutet, dass z. B. der Inhalt (Datenbestand) eines Datenbankverzeichnisses innerhalb weniger Sekunden protokolliert werden kann, indem der root-Inode des Dateisystems (ein Block der Größe 4 KB) kopiert und gesichert wird. Auf diesen gesicherten Zustand kann jederzeit lesend (!) zugegriffen werden, während das aktuelle Dateisystem normal weiterarbeitet und z. B. Änderungen erfährt. Darüber hinaus können die "konservierten" Dateisystemstände (Snapshots) jederzeit wieder zum aktiven Dateisystem erhoben werden.

Abbildung 1 zeigt die Dateisystemstände zu den verschiedenen Zeitpunkten: Zum Zeitpunkt t1 besteht das aktive Dateisystem aus drei Blöcken. In t2 wird das Dateisystem mittels eines Snapshots gesichert. Zu diesem Zeitpunkt belegt die Sicherung keinen eigenen physikalischen Platz. In t3 ändert sich das aktive Dateisystem durch eine Modifikation am Block C. Der Snapshot muss nun den alten Block C zusätzlich verwalten. In diesem Moment benötigt die Sicherung unseres Dateisystems 33 % des Plattenplatzes im Vergleich zum aktiven Dateisystem.

Snapshots von Datenbanken

Ähnlich wie bei einem Gruppenfoto ist die spannende Frage, was man am Ende "fotografiert" hat. Während auf einem Gruppenfoto das Lächeln und die Blicke der Beteiligten synchronisiert werden müssen, sollte man bei Datenbanken daran denken, dass sich die Datenbankdateien während des Ablichtens in einem konsistenten Zustand befinden. Üblicherweise sind sie konsistent, wenn der Datenbankserver normal beendet worden ist und danach eine Offline-Sicherung durchgeführt wurde. In der Praxis führt meist jedoch kein Weg an einer Online-Sicherung vorbei. Dies kann man bei Oracle z. B. über den Hotbackup-Modus erreichen.

• Ab 10g: alter database begin backup
• Vor 10g: alter tablespace <TBS> begin backup

Dieser Modus sorgt immerhin dafür, dass die Dateien zwar in sich, aber nicht unbedingt zueinander konsistent sind. Trotz des Hotbackup- Modus wird damit aus Sicht der Datenbank ein nicht konsistenter Zustand gesichert.

Backup

Um nicht nur konsistente Dateien, sondern am Ende eine konsistente Datenbank zu sichern, reicht daher ein Snapshot als Wiederaufsatzpunkt nicht aus. Zunächst wird die Datenbank, wie oben beschrieben, in dem Hotbackup-Modus gesichert. Im Anschluss daran wird die Datenbank gezwungen, die aktuellen Transaktionen im Rahmen eines archivierten Redologs zu schreiben:

Danach wird das Dateisystem mit dem neu angelegten Archiv ebenfalls mittels eines Snapshots gesichert. An dieser Stelle zahlt es sich aus, die Datenbankdateien in einem anderen Datenbereich als die Archive zu verwalten.

Wozu wird dieses Archiv benötigt? Die Aufgabe dieses Archivs ist es, die nicht zueinander konsistenten Datenbankdateien des ersten Snapshots bei einem Restore zu recovern und sie so auf einen "gemeinsamen Nenner" zu bringen. Im Szenario in Abbildung 2 wird unterstellt, dass die Datenbankdateien (DBF) und die Archive (A) in zwei getrennten Filervolumes verwaltet werden. Der erste Snapshot sichert nur die Datenbankdateien im Hotbackup-Modus. Der zweite Snapshot sichert den Datenbereich mit den Archiven inklusive der neu erstellten Archive.

Restore

Der Restore-Prozess ist stringent und einfach. Zunächst werden die Datenbankdateien aus dem ersten Snapshot wiederhergestellt. Hierfür gibt es auf der Filer-Ebene eine entsprechende Syntax zur Wiederherstellung eines Snapshots. Unabhängig (!) von der Größe des Datenbereiches dauert die Aktivierung eines Snapshots als aktives Dateisystem maximal wenige Sekunden (siehe Abbildung 3). Beim Starten der Instanz muss die Datenbank recovered werden. Hierzu wird das im zweiten Snapshot gesicherte Archiv benötigt. Beim Start der Datenbank wird der Administrator darauf hinweisen, dass die Datenbankdateien nicht zueinander konsistent sind und wiederhergestellt werden müssen (Recovery). Jetzt ist es an der Zeit, das durch den zweiten Snapshot gesicherte Archiv wieder einzuspielen. Selbstverständlich könnten auch noch weitere Archive, die nach dem Backup-Zeitpunkt angefallen sind, eingespielt werden (Point-in-time Recovery). Einen exemplarischen Restore-Prozess zeigt Abbildung 4.

Kosten

Welche Kosten entstehen denn nun durch die Snapshots? Diese Frage ist nicht einfach zu beantworten. Ein Voll-Backup (Level 0) mittels Oracle RMAN ist relativ einfach zu überschlagen. Im schlimmsten Fall wird für ein vollständiges Backup genauso viel Platz benötigt, wie für die Datenbank an sich.

Der Platzbedarf eines Snapshots hängt von der Änderungsrate der Datenbankinhalte und der Aufbewahrungsdauer der Sicherung ab. Im Moment der Erstellung eines Snapshots benötigt er physikalisch keinen Platz, da sowohl das aktive Dateisystem als auch das gesicherte Dateisystem auf die gleichen Plattenbereiche (Blöcke) referenzieren. Erst wenn das aktive Dateisystem Änderungen erfährt, muss der Snapshot physikalisch die Differenzen abbilden. Ändert sich der Inhalt der Datenbank nach einem Snapshot zu 100 %, so belegt der Snapshot genauso viel Platz wie die Datenbank an sich.

Nutzen

So extrem hohe Änderungsraten wie im Beispiel zuvor sind aber eher selten. Bei geringeren Modifikationen können daher relativ viele Sicherungen gefahren und aufgehoben werden, da die Anzahl der Sicherungen nicht mit dem Verbrauch von Speicherplatz korreliert. Zur Verdeutlichung ein kleines Beispiel: Gegeben sei eine Datenbank mit einer fixen Größe von 1.000 MB. Pro Tag ändern sich 100 MB Daten. Die Datenbank wächst jedoch nicht, weil es keine Einfügungen, sondern lediglich Änderungen gibt. Die Sicherungen einer Woche sollen für die Datenbank erhalten bleiben (siehe Abbildung 5).

Selbst bei einer Verdopplung der Snapshots (2 x pro Tag) würde sich am Gesamtvolumen nichts ändern. Die Änderungsrate von 500 MB (Mo - Fr) würde sich schlicht nur auf mehr Snapshots verteilen.

Versteckte Kosten

Ein Snapshot muss die Daten (Blöcke) einer Oracle Datenbank sichern, die sich nach dem Erstellen im aktuellen Dateisystem verändert haben. Solche Änderungen müssen aber nicht zwangsläufig durch Anwender ausgelöst werden. Auch ein administrativer Vorgang, wie z. B. das Reorganisieren von Speicherbereichen wie Tabellen, Tablespaces usw. oder der Neuaufbau von Indizes, sorgt für Modifikationen der Blöcke im Dateisystem. Der zuletzt erstellte Snapshot vor einer solchen Aktion wird durch eine solche Maßnahme unweigerlich größer, auch wenn sich die Inhalte bzw. Nutzdaten der Datenbank dadurch eigentlich nicht ändern.

Räumliche Trennung

Die Vorteile der Snapshots gegenüber den althergebrachten Backup-Strategien wie z. B. RMAN liegen auf der Hand: eine verbesserte Performance und ein geringerer Platzbedarf. Allerdings darf man nicht vergessen, dass die Backup- Informationen eines Snapshots am aktiv genutzten Datenbereich hängen. Sollte der Filer, der diesen Datenbereich bereitstellt, oder der Datenbereich selbst z. B. durch einen administrativen Fehler zerstört werden, so wäre das aktive Dateisystem samt seiner Sicherungen verloren. Aus diesem Grund empfiehlt es sich, für solche Szenarien Vorkehrungen zu treffen. Es ist beispielsweise möglich, virtuelle Tape-Libraries an NetApp Filer anzuschließen, den Filer zu clustern und/oder Datenbereiche inklusive ihrer Snapshots auf andere Filer zu übertragen, z. B. durch das Spiegeln von Volumes.

Fazit

Netapp Filer sind mit ihrer Snapshot-Technologie sehr gut für die Sicherung und Wiederherstellung von großen Datenbanken geeignet. Das Erzeugen und Zurücksichern von großen Datenmengen wird aufgrund der Snapshots größtenteils von der zeitlichen Dimension entkoppelt. Das Steuern und Verwalten der Backups ist dabei einfach und unkompliziert. Selbst komplexe Backup-Anforderungen lassen sich mit wenigen Shell-Skripten leicht realisieren.

Im nächsten Artikel berichten wir über die Möglichkeit des Klonens von Datenbanken mittels NetApp und gehen auf die Möglichkeit der Datenübertragungen zwischen Filer-Systemen ein.

Sie möchten mehr über dieses Thema erfahren, dann nehmen Sie Kontakt zu uns auf. Wir helfen Ihnen gerne weiter.

Matthias Jung (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen