Beim Dell EMC NetWorker kann man diverse Verhaltensmuster durch das Setzen von bestimmten Umgebungsvariablen beeinflussen. Bei Windows gibt es dafür die Möglichkeit, dies über Systemvariablen zu bewerkstelligen. Diese Möglichkeit gibt es bei Linux/Unix nicht so richtig in dieser Form. Aus diesem Grund hat sich Dell EMC dafür eine andere Möglichkeit einfallen lassen.
NetWorker sucht bei jedem Start nach einer Datei (bzw. einem Bourne shell script) Namens nsrrc im /nsr Verzeichnis. Findet er sie, führt er diese aus. Doch man kann damit auch noch viel mehr machen als nur Umgebungsvariablen zu setzen. Zu allererst eine Warnung an dieser Stelle: Umgebungsvariablen sollten nur gesetzt werden, wenn es dafür einen Grund gibt. Z.B. wenn man das TCP_KEEPALIVE Verhalten des NetWorkers modifizieren möchte oder weil ein Problem eine bestimmte Variable erfordert. Dieser Artikel hier soll auch keine Übersicht über die möglichen Variablen geben, sondern eher einen Denkanstoß geben, dass man mit der Datei noch mehr machen kann.
Als erstes muss man die Datei natürlich erst einmal anlegen.
Dies kann man entweder direkt mit einem Editor wie vi machen oder mittels des “touch” Befehls. Im zweiten Schritt muss die Datei ausführbar gemacht werden und dann kann man sie editieren.
Vor dem Editieren sollte man allerdings noch herausfinden, wo genau sich die Bourne shell bei dem jeweiligen System befindet.
[root@ddp-e01-vst-139 nsr]# touch nsrrc [root@ddp-e01-vst-139 nsr]# chmod +x nsrrc [root@ddp-e01-vst-139 nsr]# ls -lart nsrrc -rwxr-xr-x. 1 root root 0 13. Jun 16:01 nsrrc [root@ddp-e01-vst-139 nsr]#
Damit haben wir jetzt die ausführbare Datei erstellt. Den Pfad zur Bourne shell finden wir mittels:
[root@ddp-e01-vst-139 nsr]# which sh /usr/bin/sh [root@ddp-e01-vst-139 nsr]#
Und jetzt können wir die Datei editieren. Als allererste Zeile müssen wir den Pfad zur Bourne shell mit der sogenannten Shebang-Zeile angeben.
In meinem Fall wäre die erste Zeile also:
#!/usr/bin/sh
Tja, und damit kann man jetzt eigentlich auch loslegen.
Einige sinnvolle Einträge sind:
LC_TIME=C export LC_TIME=C echo "Creating a backup of /nsr/mm to /nsr/mm.tar" echo "Creating a backup of /nsr/mm to /nsr/mm.tar" > /dev/console tar cf /nsr/mm.tar /nsr/mm
Mittels “LC_TIME=<format>” kann man beeinflussen, in welchem Format NetWorker Datumsangaben anzeigt. C bewirkt hier, dass alle Datumsangaben (z.B. beim mminfo) in MM/TT/JJJJ Format ausgegeben werden. Insbesondere wenn man mehr als einen NetWorker besitzt, bei denen die Betriebssysteme unterschiedlichen Sprachen haben, kann dies wichtig sein, wenn man z.B. Scriptbasiert monatliche Reports von allen Servern sammelt. Damit kann man sicherstellen, dass das Datumsformat immer gleich ist.
Mittels der anderen drei Einträge wird im Prinzip erst einmal eine Ausgabe erzeugt, was wir gleich machen. Und dann wird ein tar-Archiv des Verzeichnisses /nsr/mm nach /nsr/mm.tar erstellt. Sprich wir erstellen ein Archiv der Mediendatenbank. Im Normalfall kann man damit natürlich wenig anfangen, da dieses Archiv schließlich nur beim Start des NetWorkers erstellt wird. Aber wenn man z.B. gerade ein Update des NetWorkers durchgeführt hat, wird beim Start auch sofort ein Backup der Mediendatenbank angefertigt. Falls das Update aus irgendeinem Grund fehlschlägt und die Mediendatenbank dabei schreddert, ist man froh, das Archiv zu haben. Kommt sicher nicht häufig vor (oder auch nie, wenn man Glück hat), aber sicher ist sicher. 🙂
Wie gesagt gibt es viele Variablen, die man dort setzen kann.
Aber insbesondere das tar-Beispiel soll zeigen, dass man mit der Datei auch noch andere Dinge vor dem Start des NetWorkers erledigen kann. Wenn man ein Monitoring-Tool mit Prozessüberwachung nutzt und den Server für einen Neustart des NetWorkers in den Wartungsmodus versetzt hat, könnte man den Wartungsmodus durch einen Befehl in der nsrrc-Datei automatisch beim Start des NetWorkers beenden. Es kann schnell passieren, dass man dies vergisst, weil z.B. gerade ein Kollege vorbeikommt und etwas wissen möchte. Dann ruft auch noch ein Kunde an und möchte einen dringenden Restore. Und schon hat man den Wartungsmodus vergessen und bemerkt dann leider nicht, dass der NetWorker zwei Tage später mitten in der Nacht abgeraucht ist, weil das Prozessmonitoring NICHT zugeschlagen hat.
Seit 2006 bin ich im Data Protection Bereich tätig und habe über die Jahre Erfahrungen mit diversen Produkten sammeln können. Darunter NetBackup, Avamar und natürlich vor allem NetWorker. Mit NetWorker habe ich seit meiner Ausbildung zum Fachinformatiker – Fachrichtung Anwendungsentwicklung – zu tun und habe mich auch auf diesen spezialisiert – vor allem in Kombination mit der Data Domain als Backup Storage. Darüber hinaus programmiere ich gerne in der Sprache Perl, sei es nun beruflich oder privat.