Der Kunde musste die Sicherung einer SAP/R3 Datenbank mit 'Dedicated StorageNode' auf NetWorker 7.5 umstellen. Normalerweise kein Problem, denkt man. Aber der Teufel lag mal wieder im Detail.

Zur Umgebung:

• Der Kunde sichert eine MAXDB (früher SAPDB) SAP/R3-Datenbank mit Hilfe des NetWorker Save-Kommandos über eine Pipe. Eine genaue Beschreibung des Verfahrens kann man hier bekommen.
• Bei dieser Sicherungslösung werden die zu sichernden Daten von der MAXDB in eine Pipe geschrieben und auf der anderen Seite vom NetWorker Save-Kommando mit Hilfe des internen rawasm gelesen und weitergereicht.
• Das Save-Kommando wird in diesem Fall vom MAXDB Sicherungsmodul selbst aufgerufen. Der Aufruf erfolgt nicht über den NetWorker Client-Dämonen (nsrexecd). 

Und hier liegt die Ursache des Problems. Seit NetWorker V7.5 wird bei einem vom Benutzer gestarteten Save-Kommando keine Level Angabe mehr akzeptiert! In diesem Fall erhält man folgende Warnung:

# save -l full /etc/host
Client initiated backup.Option '-l' is ignored and backup is performed at level 
adhoc

Diese Meldung veranlasst das MAXDB-Modul die Sicherung als fehlerhaft einzustufen.

Welche Lösungsmöglichkeiten gibt es?

1. Wenn in der Umgebung des Save-Kommandos die Variable NSR_MAST gesetzt ist, akzeptiert das Save-Kommando die Level-Angabe.
2. Aufbau eines "Wrappers" um das eigentliche Save-Kommdando

Da es sich bei der Datenbank um ein 7*24 System handelt, war an einen Restart der Datenbank zum Setzen der Umgebungsvariablen nicht zu denken. Eine Sicherung sollte aber unbedingt täglich erzeugt werden!

Also wurde Variante 2 gewählt: Ein Shellskript ersetzt das Save-Kommando und startet das eigentliche Binary mit der benötigten Umgebung. Wichtig ist hierbei aber auch darauf zu achten, dass die Ausgabe des Save-Kommandos nicht verfälscht wird. Denn auch diese wird von dem MAXDB-Sicherungsmodul ausgewertet. Wurde das Binary auf den Namen "save_bin" umbenannt so wird die Ausgabe des Kommandos in etwa so aussehen:

save_bin: /etc/hosts  8 KB 00:00:00      3 files

Das mag die MAXDB aber auch nicht, das Sicherungsmodul scheint in seiner Auswertung nach dem String "save:" zu suchen und wenn der nicht gefunden wird die Sicherung als fehlerhaft eingestuft.