Sicherung

Schnell, schneller, rman (Backup und Restore)

Für ein schnelles Backup der Oracle Datenbank kann hat man wenn man Glück hat eine schnelle Backup Infrastruktur. Aber auch die schnellste Infrastruktur ist einfach immer zu langsam wenn es – warum auch immer – einfach mal schneller gehen muss 🙂 Wenn dann auch noch Oracle Flashback nicht genutzt werden kann weil es den Anforderungen nicht genügt oder schlichtweg nicht konfiguriert ist kann man i.d.R. schnell und einfach auf rman als Backuplösung zurück greifen.

Ich werde hier kurz erläutern wie man rman (Recovery Manager) für ein Backup in ein Filesystem, also ein rman backup to disk  (rman backup2disk) konfiguriert und im Notfall einen Restore aus dem Backup anfertigt.

Für die Nutzung von RMAN müssen zunächst die Parameter überprüft werden. Hierzu ist ein rman connect notwendig.

Zunächst verbindet man sich per rman gegen die Datenbank: [Read more…]

brbackup freundlich bitten die Arbeit niederzulegen

Eine aktuell laufende Sicherung kann man auf mehrere Arten beenden. Rabiat und unschön mit einem schnell wirkenden kill -9 inkl. nachfolgenden Aufräumarbeiten in der Datenbank (End-Backup-Modus setzen) oder eben über die -gun -abort Kombination.

Hierzu einfach auf einer shell brbackup mit folgender Option aufrufen:

brbackup -abort <option>

-abort leitet den Abbruch ein

[Read more…]

rman und das Löschen der Archivelogs

Wenn man für die Sicherung von Oracle Datenbanken rman in Verbindung mit den brtools von SAP nutzt ist das eine feine Sache. Die Architektur ist ausgereift, ermöglicht inkrementelle Datenbankbackups und bietet noch einige Vorteile mehr.

Ein großer Nachteil beim Einsatz von rman ist jedoch die Sicherung der Archivelogs mit dem brtool brachive. Hier wird nämlich eine Bestandsaufnahme der zum Start der Archivelogsicherung zu sichernden Archivelogs vorgenommen und die Dateien erst dann gelöscht, wenn die letzte Archivelogdatei erfolgreich gesichert wurde. Dies stellt gerade dann ein Problem dar, wenn das System kurz vor einem Archiverstuck steht und die zu sichernde Datenmenge das Backuptool vor eine große Herausforderung stellt. Es kann auch passieren, dass die Archivesicherung abbricht, nachdem bereits einige 100 Gigabyte in das Sicherungstool übertragen worden sind – die bereits gesicherten Dateien werden nämlich dann nicht gelöscht, da der komplette rman Aufruf  als solches ja nicht erfolgreich war. Bei der nächsten Archivesicherung werden die Dateien dann erneut übertragen und währenddessen füllt sich die Archivedestination munter weiter.

Das rman Verhalten lässt sich jedoch über einen undokumentierten Parameter in der init<SID>.sap beeinflussen. Hierzu muss man lediglich den Parameter „_rman_grp_cnt =“ setzen. [Read more…]

Domainumzug

… erfolgreich beendet 😉

Aus wesselonline.dyndns.org inkl. Subdomains wurde dann jetzt   http://patrick-wessel.de, inklusive Emaildomains… Damit hat natürlich der erst vor 2 Monaten in Betrieb genommene Linuxserver seine Daseinsberechtigung verloren… und wurde (mal wieder) durch eine NSLU von Linksys und 2x 16GB Usb Sticks ersetzt. Die NSLU übernimmt hier nur noch die internen Mailservertätigkeiten mit dem altbekannten Dreigestirn Postfix (SMTP), Bogofilter (Spamfilter) und natürlich Dovecot (IMAP/POP).

Zusätzlich läuft auf der NSLU noch ein pure-ftp FTP Server, lighttpd + php5 + eaccelerator als Webumgebung sowie die Sicherung per backup2l. Gesichert werden hier nich nur die Mails, sondern auch die neuen Domains. Das ganze wird hier später noch genauer inkl. der kleinen Scripte vorgestellt:

Per sshfs wird das Filesystem der Domänen lokal gemountet. Auf dem Webserver des Hosters läuft ein CRON-Job, der jede Minute ein Script auf dem Server startet. Das Script schaut zunächst in einem Verzeichniss nach einem Startflag (Datei). Wenn die Datei gefunden wurde dumpt es die gefüllten MySQL Datenbanken ins Filesystem und schreibt die Aktionen in ein Logfile.

Auf der NSLU wird per CRON-Job das Backuptool backup2l gestartet. In der Config des Backuptools wird vor dem Backup ein Script gestartet, dass per sshfs das Dateisystem des Webservers mountet und das Startflag für den CRON-Job auf dem Webserver erzeugt. Nach einem Timeout von 5 Minuten wird geprüft ob das Datenbankbackup gelaufen ist und eine entsprechende Meldung ausgegeben. Anschließend läuft backup2l los und sichert ber afio und gzip den Inhalt des Filesystems. Bzip ist einfach zu viel für die kleine 266 MHz Arm CPU der NSLU (zumal hier nur 32 MB RAM zur Verfügung stehen!). Hier wird alle 2 Wochen eine Vollsicherung angelegt und im restlichen Zeitraum inkrementell gesichert. Die Files landen auf dem zweiten USB Stick – von da gehts in regelmäßigen Abständen ab aufs NAS. Die Lösung ist sehr effektiv und spart vor allem Transfervolumen. So werden täglich eigentlich nur die Datenbank + einige wenige Änderungen an den Files  gesichert.

Die Scripte folgen…