Login Registrieren

Neue NetWorker Task; nsrclientfix

Verfasst von Uwe W. Schäfer am 17. September 2015

In einem vorhergehenden Block habe ich die Verwendung des neuen NetWorker Kommandos 'nsrclientfix' bereits beschrieben. Allerdings wurde ein weiteres für den Administartor vielleicht überraschendes Feature dort nicht erwähnt, das nach einem Update auf die NetWorker Version 8.2.1 automatisch aktiv ist:

Jeden Sonntag um 07:00 wird nämlich dieses Kommando von einem NetWorker Task automatisch gestartet.

Sichtbar ist dieser Task und die zugehörige Ressource allerdings nicht über die Oberfläche der NMC, sondern nur mit Hilfes des Kommandos nsradmin.

echo "print name: DefaultNsrclientfixTask" | nsradmin -i -

Sollte jemanden die dabei entstehende Mail stören, kann man den Task mit folgendem Kommando deaktivieren.

echo ". name: DefaultNsrclientfixTask
          update autostart: Disabled " | nsradmin -i -

 

Achtung: 

Das obige Update-Kommando funktioniert so nur auf einem LINUX/UNIX NetWorker Server. Bei einem Windows-Server müssen sie die beiden Zeilen zwischen den Anführungszeichen in eine Datei schreiben und das Kommando nsradmin mit der Option -i <dataiename> starten.

Die NetWorker Client-Update-Datenbasis

Verfasst von Uwe W. Schäfer am 13. März 2013

NetWorker besitzt seit der Version 7.3 einen eigenen Client-Update Mechanismus. Nun ist seit dieser Version doch schon einige Zeit vergangen und es scheint nicht verwunderlich, dass Maschinen die vielleicht in dieser Version inventarisiert wurden, mittlerweile nicht mehr existieren. Doch wie bekommt man diese "alten" Clients jetzt auch aus der NetWorker-Versions-Datenbank (Push-DB) entfernt?

Man kann natürlich erstmal fragen, warum sollte man die denn entfernen wollen? Dazu kurz folgende Zusatzinformation:

Mit Hilfe des nsrpush Kommandos kann man leicht alle NetWorker Clients eines NetWorker Servers auf eine neue Version updaten. Hierzu dient die nsrpush Option 'all'.
Hat man aber seit dem letzten Inventory einen oder mehrere NetWorker-Clients gelöscht, so erhält man vom nsrpush die nette Meldung:
"Skipping client 'old_client' because it is no longer configured with this server"

Wie bekommt man aber jetzt diesen gelöschten Client aus der Push-DB?
Der nsrpush selbst bietet einem hierzu leider keine Option.
Wenn man aber weiß, dass die Push-DB eine NetWorker-RAP Database ist, läßt sich das relativ leicht mit dem 'nsradmin' Kommando bewerkstelligen.
Man benötigt folglich "nur" noch den Ressource-Namen und ein eindeutiges Attribut zum Löschen der zugehörigen Ressource.
Hier der passende Kommando Aufruf:

echo ". type: NSR installed Software; name:  old_client
           delete " | nsradmin -i - -d /nsr/res/cpdb

 

Werden alle notwendigen NetApp Volumes gesichert?

Verfasst von Uwe W. Schäfer am 10. September 2010

Wann merkt man, dass ein Datenbereich nicht gesichert wird?
Natürlich erst dann, wenn man Daten aus dem betreffenden Bereich wiederherstellen möchte!

Genau dieses war mal wieder beim Kunden vorgekommen und damit dieses nicht noch mal passiert, sollte eine Lösung entwickelt werden, die einmal täglich überprüft, ob alle zurzeit existierenden Volumes gesichert werden.

Die Umgebung:

Der Kunde sichert mehrere NetApp Filer mit dem Backup Produkte NetWorker und dem NDMP Protokoll auf externe Bandmedien.

Auf den Filern werden sowohl Oracle-Datenbanken, MS-Exchange-Daten, VMware-Datastores als auch Benutzer-Daten gespeichert. Die Oracle-, Exchange,- wie auch die VMware-Daten werden über eigene Module gesichert; so kann folglich nicht einfach der NetWorker-SaveSet "All" verwendt werden, um alle NetApp-Volumes zu sichern.

Die Lösung:

Mit unserer eigenen NetApp-ZAPI-Python-Schnittstelle werden zunächst vom jeweiligen Filer alle Volumes ermittelt.

Dann werden über unsere Python-NetWorker-nsradmin-Schnittstelle alle "Save Sets" für den betreffenden Filer ausgelesen.

Volumes, die nicht im NetWorker definiert sind, werden anschließend noch gegen eine definierbare White-Liste verglichen. Die Oracle- und VMware-Volumes will man ja nicht jeden Morgen vor Augen haben,
da man sonst ja wieder nicht sieht, ob ein neues Volume hinzugekommen ist.

Über die Volumes, die weder in der Sicherung noch in der White-Liste enthalten sind, werden die Administratoren mittels E-Mail informiert.

 

Durch unsere bestehenden NetApp und NetWorker Frameworks konnte somit eine einfache und praktikable Lösung in kurzer Zeit entwickelt werden, die dem Kunden eine Menge Ärger und Erklärungsnöte ersparen kann.

Seite 1 von 1