Wie es der Zufall mal wieder so wollte, fragten in diesem Jahr zwei Kunden unabhängig voneinander, nach einem Prove Of Concept (POC) für den Einsatz des NMDA-OApp Moduls. In einem Fall für einen Einsatz mit PostgreSQL Datenbanken im zweiten Fall für MySQL Datenbanken.

Beide POCs konnten erfolgreich beendet werden, aber bevor wir uns mit den Details befassen ein paar kurze Infos zu dem NMDA-OApp Modul.

Mit der NetWorker Version 18.1 (2018) wurde in dem NetWorker „Modul for Database Applications (NMDA)“ die sogenannte OApp Erweiterung eingeführt. Diese ermöglicht es, mit Hilfe eines DataDomain Storage-Systems und dem zugehörigen BoostFS Modul, Datensicherungen und Wiederherstellungen der Datenbanken PostgreSQL, MySQL, MariaDB und MongoDB schnell, elegant und vor allem sicher auf ein externes Backup-Storage-System zu speichern.

Bei dieser für NetWorker neuen Art der Sicherung werden die vom Datenbankprodukt bekannten Sicherungs- und Wiederherstellungs-programme verwendet, aber die Daten sind nach der Sicherung nicht mehr auf der lokalen Platte des Datenbank-Systems sondern auf der DataDomain und auf einem NetWorker-Medium.

Vorteile:

• Alle Sicherungen (Voll und Log-Sicherungen) werden mit den bekannten NetWorker-Eigenschaften verknüpft. Im einzelnen sind das:
  • Retention Zeiten
  • Cloning auf eine 2‘te Data-Domain
  • Integration der Sicherung in die Medien-Datenbank und damit Such-Möglichkeiten über die Sicherungsattribute

• Auch eine Wiederherstellung auf einen definierten Zeitpunkt (Recover-Until-Time) werden durch die OApp Erweiterung ermöglicht.

Nachteile:

• Die Installation und Konfiguration des benötigten BoostFS Moduls und der benötigten Skripte ist ein wenig knifflig.

• Für eine Wiederherstellung müssen Anpassungen in Wiederherstellungs-Skripten vorgenommen werden.

Hier ein kurzer Abriss der benötigten Installations- und Konfigurations-Schritte beim Einsatz des Moduls mit PostgreSQL Datenbanken:

1. Installation der benötigten NetWorker und DataDomain Pakete
2. BoostFS Konfiguration
   • Lockbox konfigurieren
   • BoostFS für PostgreSQL konfigurieren
3. NetWorker NMDA Config Files anlegen
4. NetWorker Ressourcen anlegen
5. Postgres Config File anpassen

> mminfo -ot -v -c sles12sp5-1
pgres.005 sles12sp5 02/17/22 55 MB cr full   PostgreSQL_nsr_full
pglog.005 sles12sp5 02/17/22 16 MB cr txnlog PostgreSQL_nsr_txnlog_1040
pglog.005 sles12sp5 02/17/22 16 MB cr txnlog PostgreSQL_nsr_txnlog_1041
pglog.005 sles12sp5 02/17/22  2 KB cr txnlog PostgreSQL_nsr_txnlog_1041.0028.backup

Nötige Schritte für einen Point in Time Recover:

• Sicherungszeit (savetime) und SaveSet-Name des gewünschten Backup in der Config-Datei eintragen
• Relocation-Destination vorbereiten
• DB-Stoppen
• PostgreSQL Data Verzeichnis entfernen
• NetWorker NMDA Recover Kommando starten
• Wiederhergestellte Daten in das PostgreSQL-Data Verzeichnis umziehen
• Definitionsparameter in der postgresql.conf editieren
  1. restore_command
  2. recovery_target_time
• Postgres Signal Datei anlegen
• DB Starten
• Postgres Log File kontrollieren
• Postgres Signal Datei entfernen
• PostgreSQL Config File editieren
• PosgreSQL Dienst neu starten

Log-Ausgabe eines erfolgreichen Point in Time Recovers

> less data/log/postgresql-2022-02-17_104617.log

starting
point-in-time recovery to 2022-02-17 10:30:00+01

The recovery completed successfully.

restored log file "1046" from archive

redo starts at 0/46000028

consistent recovery state reached at 0/46000138

database system is ready to accept read only connections

The recovery completed successfully.

restored log file "1047" from archive time 2022-02-17
10:30:24.525416+01 

recovery stopping before commit of transaction 13283,

pausing at the end of recovery

HINT: Execute pg_wal_replay_resume() to promote.

FAZIT:

Die oben gezeigten Konfigurations-Schritte haben nicht den Anspruch vollständig und ausreichend zu sein, sie sollen Ihnen nur die Komplexität des Themas vermitteln, ihnen aber auch zeigen, dass das Ergebnis den Aufwand lohnt.

Sollten Sie weitergehende Fragen zu dem Einsatz des NMDA-OApp Moduls haben oder selbst einen POC in Ihrem Hause wünschen, so scheuen Sie sich nicht, den Autor zu kontaktieren.

Oracle-NMDA Backups in großen NetWorker Umgebungen

Die Konfiguration einer NetWorker Oracle-Backup Umgebung hat sich durch die Einführung des NetWorker Moduls für Database Applications (NMDA) und dem zugehörigen NMC-Wizzard, auf den ersten Blick stark vereinfacht. Betrachtet man die Konfiguration aber in Umgebungen mit einer hohen zweistelligen, oder gar dreistelligen Zahl von Datenbanken, so macht sowohl die Migration bestehender Konfigurationen, als auch die Pflege der Oracle-RMAN-Skripte mit dieser Art der Datenbanksicherung-Konfiguration wenig Spass. Der Pflegeaufwand und der potentielle Wildwuchs der verwendeten RMAN-Skripte und NetWorker Konfigurationen wuchert doch sehr schnell aus.

Genau vor diesem Problem Stand ein Kunde bei der anstehenden Umstellung der Oracle-Datenbanksicherungen vom ehemaligen NMO Modul auf das aktuelle NMDA Modul. Die Anzahl der zu sichernden Datenbanken lag im dreistelligen Bereich. Es sollte also eine Möglichkeit gefunden werden,

• die Umstellung des Datenbankmoduls möglichst einfach zu gestalten.
• sowohl den Update-Vorgang des  NetWorker-Clients als auch des Datenbankmoduls zu automatisieren.
• die NetWorker Ressourcen automatisch vom alten Modul auf das neue Modul anzupassen.
• den anschließenden Pflegeaufwand der Datenbanksicherungskonfigurationen und der RMAN-Skripte zu minimieren.

Klingt auf den ersten Blick ziemlich unmöglich. Doch mit der richtigen Systemumgebung und einigen geschickten Randbedingungen war eine Idee ziemlich schnell gefunden und die Implementierung der Lösung war dann sogar relativ einfach.

Hier eine kurze Beschreibung der Randbedingungen und der implementierten Lösung:

Systemumgebung:

1. Alle Datenbanken befinden sich auf LINUX/UNIX Systemen
2. Die zu installierenden Software-Pakete befinden sich auf einem für alle Maschinen zugänglichen NFS-Share.
3. Es existiert eine sichere (gespiegelte) NFS-Umgebung auf der ein Share angelegt wird, der auf allen Datenbankmaschinen gemountet werden kann.

Randbedingungen:

1. Die Oracle RMAN-Skripte lassen sich durch die Verwendung einiger Oracle-Parameter für alle Datenbanken einer Oracle-Version verwenden.
2. Die NetWorker Ressource-Namen der Gruppen-, Schedule und sonstigen Ressourcen müssen standardisiert sein.
3. Der Save-Set des Clients definiert die Sicherungs-Parameter (Oracle-SID, RMAN-Sicherungstyp (Archive, Full, Level, ...))

Implementierte Lösung

Shell und Python-Skripte

Die Lösung des Problems bestand neben dem Aufbau einer geschickten Datenablage, in der Implementierung folgender Skripte:

1. Migrationsskript, das auf einer Oracle-DB-Maschine
   
   • die bestehende NetWorker-Umgebung analysiert
   • die "alten" NetWorker Pakete deinstalliert 
   • die "neuen" definierten NetWorker Pakete installiert
   • die alten NetWorker Ressourcen deaktiviert
   • neue NetWorker Ressourcen erzeugt
   • die Oracle-Backup-Library verlinkt
   • das Backup-Command verlinkt
   • den NFS-Mount des NFS-Ablageverzeichnisses in die /etc/fstab integriert
2. NetWorker Backup Command, das
   • anhand des übergebenen SaveSets, das definierte RMAN-Skript mit den benötigten Parametern aufruft.
   • das Rollieren der "alten" Backup-Protokolle durchführt

NFS-Ablage

Die gemeinsam genutzte NFS-Freigabe enthält folgende Datenstruktur:

1. Ein eigenes Verzeichnis für jede Datenbank mit dem Namen der Oracle-SID,  in dem neben einer Konfigurationsdatei  die Protokolle der Sicherungen und Wiederherstellungen abgelegt werden.
2. Ein Binarie-Verzeichnis, in dem die gemeinsam genutzten RMAN-Skripte und das implementierte NetWorker-Backup-Kommando liegen.

Fazit

Welche Vorteile bringt die implementierte Lösung?

• Leichtere Wartung der RMAN-Skripte. Nur noch wenige zentral abgelegte Skripte werden benötigt.
• Leichtere Fehlersuche, da bei Problemen die Protokolle und Konfigurationen von funktionierenden und fehlerhaften Sicherungen auf jeder Maschine direkt verglichen werden können. Ein mühsames Anmelden des NetWorker Administrators auf der jeweiligen Datenbankmaschine ist nicht mehr notwendig.
• Übersichtlichere NetWorker Konfiguration. In der Client-Ressource definiert alleine der SaveSet die Art der Oracle-Sicherung.
• Einfache und fehlerfreie Migration der alten NetWorker-Client Umgebungen in die neue NMDA-Umgebung.

Sollten sie Fragen zu diesem Blog haben oder vor ähnlichen Herausforderungen stehen, so scheuen sie sich bitte nicht sich per E-Mail an info@schaefer-tobies.de zu wenden.