Die lange ersehnte NetWorker Version 9.1 steht seit dem 23. Dezember 2016 auf der EMC-Support Seite zum Download zur Verfügung.

Update: 10.02.2017

Die Version 9.1 wurde lange von vielen Kunden ersehnt. Ich habe immer wieder gehört, wir warten vor dem Update auf die Version 9 auf die Version 9.1. Auch von Seiten der EMC wurde immer auf diese Version hingewiesen für die best-mögliche Umstiegsversion. Nun ist sie da, und es stellen sich zwei Fragen: was ist neu an dieser Version, warum kann man den Umstieg von der Version 8 auf die Version 9 jetzt leichter bewältigen?

Hier ein paar Antworten zu diesen Fragen:

1. Was ist neu?

   1. VMware Backup die 3'te.

      Mit der NetWorker Version 8.x wurde die VMware Backup Appliance als neues revolutionäres Backup für die VMware basierten virtuellen Maschinen eingeführt. Diese Art der Sicherung über ein Block-orientiertes Verfahren (CBT) mit einer „inkrementell vor Ever“ Technik, war wirklich ein Riesenschritt nach vorne. Hier die wesentlichen Vorteile:

      1. Die Backup-Zeiten wurden auf einen Bruchteil der vorher nötigen VADP-Backup-Zeiten zusammengeschrumpft.

      2. Das zu transferierenden Sicherungsvolumen wurde durch ein auf dem CBT Verfahren aufsetzendes Sichern der veränderten Blöcke marginalisiert. Vor allem wenn man zusätzlich die Verwendung der DataDomain Boost Technik mit einer Deduplizierung innerhalb der VBA mit betrachtet.

      3. Die Zeiten für die Wiederherstellung einer virtuellen Maschine wurde erheblich verringert. Denn auch hier wurde das Datenvolumen, das für die Wiederherstellung einer virtuellen Maschine übertragen werden muss, durch die Verwendung der CBT Technik minimiert

      4. Durch die Einführung des Instant-Recover, einzelner Maschinen auf dem DataDomain-Backup-Storage, ist auch das Testen eines Sicherungsstandes einer virtuellen Maschine in kürzester Zeit realisierbar.

      5. Die Wiederherstellung einzelner Dateien (FLR-Recover) wurde ebenfalls stark verbessert.

      Allerdings gab es in der VBA Technik einen großen Nachteil! Dieser Bestand in der Verwendung der VBA selbst. Innerhalb dieser virtuellen Maschine ist ein Avamar- Server integriert, der auf der einen Seite mit dem VMware-Vsphere Server und auf der anderen Seite mit dem NetWorker-Server kommuniziert. Diese Sicherungsinstanz hatte jetzt außerhalb des NetWorker-Servers Sicherungsinformationen in einer eigenen Datenbank. Die guten alten NetWorker Regeln „Single Point of Administration“ und „Single Point of Information“ war hierdurch verletzt. Die Praxis zeigte in den letzten Jahren, dass genau diese Verletzung immer wieder zu großen Problemen führte. So gingen immer mal wieder in der Dreierbeziehung zwischen NetWorker, Avamar und Vsphere einige Informationen verloren, die dann zwangsläufig zu Fehlern führten.

      Mit der Version 9.1 ist dieser Malus verschwunden!

      NetWorker hält jetzt wieder alle Informationen und Aktionen allein und selbst in der Hand. Die VBA wird nicht mehr benötigt! Stattdessen werden jetzt für die Sicherung der virtuellen Maschinen lediglich sogenannte vProxy Appliances eingeführt. Diese virtuellen Maschinen kann man sich als reine Data-Mover, ähnlich einer NetWorker-StorageNode vorstellen. Sie bewegen die Daten von dem VMware-Storage mit Hilfe des DataDomain-Boost Protokolls auf einen DataDomain Backup-Storage. Alle Informationen über die Sicherungen und die Initiierung der Sicherungen und Wiederherstellungen können vom NetWorker-Server, der NMC oder direkt von der Vsphere WWW-Oberfläche ausgeführt werden.

       

      Fazit zum Thema VMware Backup:

      Mit der Version 9.1 ist die Sicherung der virtuellen VMware-Maschinen auf der Basis der oben beschriebenen Vorteile auf eine solide und wesentlich robustere Technik gehoben worden. Alle bekannten Probleme der NetWorker VBA Backup Lösung sollten somit erledigt sein.

      Alle Kunden, die sich heute noch mit der „alten“ VADP Sicherungstechnik herum schlagen, sollten sich nun ernsthaft überlegen, auf diese Art der Sicherung umzustellen.

   2. Cloud Boost Unterstützung

      Mit der NetWorker Version 9.1 und deren Clients ist jetzt auf aktuellen Linux Betriebssystemen ein direktes Backup in die Cloud möglich.

      Virtuelle Umgebungen die in einer Amazon EC2 Cloud gehostet werden, können jetzt mit NetWorker und einer Cloud-Boost Appliance auf einen Amazon S3 Storage gesichert werden.

   3. DataDomain Cloud-Tier Unterstützung

      • Integration der DataDomain Cloud Tier Unterstützung in die NetWorker Umgebung.

      • Die Version 9.1 unterstützt direktes Recover incl. GLR Recover von einem Cloud-Tier Storage.

   4. NetApp ONTAP 9 Unterstützung

      Mit der NetWorker Version 9.1 ist erstmalig der Support für NDMP mit ONTAP 9 enthalten.

2. Warum kann man jetzt leichter auf die Version 9 umsteigen?

   Um diese Frage beantworten zu können, sollte man vielleicht auf meinen Absatz in der News zum NetWorker 9.0 schauen. Hier hatte ich folgende Probleme für den Umstieg festgestellt:

   Zitat zum NetWorker 9.0

   ---

   Was fehlt an alten Funktionen:

   1. Es gibt kein savegrp Kommando mehr. Aber Backups lassen sich weiterhin mit dem CLI-Kommando nsrpolicy starten.

   2. Das Kommando nsradmin kann für die neuen Policys nicht verwendet werden. Auch hierfür kann stattdessen das neue CLI-Kommando nsrpolicy verwendet werden.

   3. Die Backup-Levels 2-9 sind Geschichte, es gibt nur noch den Level 1, Voll und inkrementelle Sicherungen.

Wie sieht es jetzt mit den obigen Punkten im NetWorker Version 9.1 aus?

Zu 1. Als Ersatz für das Kommando savegrp kann seit der Version 9.0.1.x das Kommando nsrworkflow verwendet werden. Dieses bietet einen fast vollständigen Ersatz.

Zu 2. Zusätzlich zum Kommando nsrpolicy steht seit der Version 9.0.1 ein recht umfängliches REST-API zur Verfügung. Mit dieser Programmierschnittstelle können alle bisher verwendeten nsradmin Skripte umgestellt werden.

Folgende von NetWorker 8 bekannten Features und Funktionen fehlen aber leider weiterhin:

• Die bereits oben in Punkt 3 genannten Level Sicherungen.

• Die fehlende Browse-Policy und damit größer werdende Index-Datenbanken

• Die geänderte Protokollierung und damit fehlende Savegroup-CompletionMessage, sowie die zugehörigen Tools nsrsggrpcomp und nsrscm_filter.

FAZIT:

Alles in allem kann man sagen, die NetWorker Version 9.1 hat nicht alle Features, die sich der ein oder andere zurück gesehnt hat, aber der Umstieg auf die neue Technik mit Policys und Workflows bringt dafür auch einige interessante neue Möglichkeiten. Ob sie auf die NetWorker Version 9.1 umsteigen wollen, oder ob sie auf die nächste Version warten, muss jeder Kunde für sich selbst entscheiden. Ein Zwang zum Update besteht zurzeit nur für Kunden die ihre Daten in die Cloud sichern wollen, oder die einen NDMP Support für NetApp 9 benötigen.

Sollten sie einen tieferen Einblick in die Version bekommen wollen, so kann ich ihnen nur den Besuch eines unserer nächsten NetWorker 9 Workshops im Hause qSkills empfehlen. Selbstverständlich helfen wir ihnen natürlich auch gerne beim Umstieg auf die neue Version. Sei es nun bei der Unterstützung des kompletten Update-Vorganges oder bei der Umstellung diverser Skripte auf das REST-API.

Wie bereits im letzten Blog beschrieben hat die NetWorker Version 9.0.1 ein REST-API erhalten. Dieses ermöglicht es nun NetWorker aus einer beliebigen Umgebung heraus zu Administrieren und zu Verwalten.

NetWorker konnte man bis zur Version 9 über sein Commad-Line-Interface (CLI) automatisieren und ihn so in jeden beliebigen externen Scheduler oder Batch-Job integrieren. Leider sind diese Möglichkeiten durch die im NetWorker 9 eingeführten Policys weitestgehend entfallen. Kunden, die den NetWorker wie bisher über ein externes Programm automatisieren möchten sind somit gezwungen, ihre Routinen auf die neue REST-API-Schnittstelle umzustellen.
NetWorker liefert hierbei aber eben nur die Schnittstelle, die Implementierung der gewünschten Funktionalitäten ist dem Anwender selber überlassen. Da dieses Unterfangen (Implementierung über REST-API) einen normalen Backup-Administrator meist überfordert, haben wir versucht zwei wesentliche Funktionen, Start einer Sicherung und Ermitteln des Sicherungsstatus, als fertige Kommandos zu implementieren. Diese Kommandos sind freilich nur Beispiele und sollen mehr oder weniger nur die Möglichkeiten der REST-API-Schnittstelle beispielhaft aufzeigen.

Die Kommandos:

nsr_api_start_workflow

Start eines NetWorker Workflows.

Usage:

nsr_api_start_workflow -i
nsr_api_start_workflow -a 
nsr_api_start_workflow -s <nsr-srv> [-v]* [-u <user>] [-p <password>] 
      -n <policy-name> -w <workflow> [-c <client>]*
  
  -i   interactive; Ask for all parameters

  -a   active; Parameters are defined in the 'local_defines.py' file

  -n   Policy name

  -w   workflow name

  -c   start only this client from workflow-group

  -v   verbose; Wait till the job finishes!

nsr_api_get_jobinfo

Ermitteln des aktuellen Status eines zuvor gestarteten Workflows.

Usage:

nsr_api_get_jobinfo -i [--wait] <workflow-jobid> 
nsr_api_get_jobinfo [-a] [--wait] <workflow-jobid>
nsr_api_get_jobinfo -s <nsr-srv> [-u <user>] [-p <password>] [--wait] <jobid> 
 
  -i      interactive; Ask for all parameters

  -a      active; Default: Parameters are defined in the 'local_defines.py' file

Common parameters:

  --wait  Job waits until all dependend jobs and the workflow job are finished

~

Da die Ausführung der Kommandos eine relativ aktuelle SSL Umgebung benötigt, die noch nicht mal auf einem SuSE SLES 12.0 standardmäßig gegeben ist, haben wir uns dazu entschlossen, die Kommandos als fertige Pakete mit binär ausführbaren Dateien und nicht als Skripte zur Verfügung zu stellen. Die zurzeit existierenden Pakete sind ausführbar auf einem Windows x64 System (ab Windows7) oder einem Linux System mit einer GLIBC_2.14 oder neuer. Letzteres ist zum Beispiel auf einem SuSE-SLES 12.x oder einem Ubuntu 14.04 gegeben.

Die vollständige Dokumentation mit Installationsanleitung können sie hier herunterladen, die Pakete für Windows und Linux erhalten sie auf Anfrage beim Autor.

Sollten sie ein ähnliches NetWorker Automatisierungsprogramm benötigen, scheuen sie sich bitte nicht den Autor zu kontaktieren. Wir können ihnen bestimmt weiter helfen.

Ein Kunde hatte vor einigen Jahren Sicherungen bzw. Archivierungen mit NetWorker auf damals aktuelle Tandberg 9840B und T10000 Medien gespeichert. Die Sicherungen haben zum Teil Sperrfristen von bis zu 30 Jahren. Im Rahmen des endgültigen Abbaus der „veralteten“ Laufwerke sollten diese Sicherungen auf neue aktuelle Medien migriert werden.

Klingt erst mal ganz einfach. NetWorker kann ja seine Sicherungen ohne Probleme von einem Medium auf ein anderes Clonen. Eigentlich sollte ich nur für eine möglichst weitgehende Automatisierung der Migration sorgen. Aber wie so oft lag auch hier mal wieder die Tücke im Detail. Daher möchte ich hier kurz die aufgetretenen Probleme beschreiben.

Folgende unerwartete Probleme kamen zu Tage:

• Die Tandberg 9840B Laufwerke ließen sich weder an einem aktuellen Linux noch an einem NetApp C-Mode Storage-System verwenden. Die aktuellen Treiber konnten mit den alten Laufwerken nicht mehr arbeiten. Kaum zu glauben aber wahr.

• NetApp NDMP Band-Sicherungen lassen sich nur über ein NetApp System auf neue Hardware clonen. An den aktuellen Storage-Systemen waren aber gar keine Bandlaufwerke mehr vorgesehen. Hier musste folglich ein „altes“ NetApp 7-mode System wieder aktiviert werden, um die Daten von den alten Medien lesen zu können.

• Zwei der für das Wiederherstellen benötigten Solaris-Systeme brachen während der Cloning Aktivitäten, wegen Hardwareproblemen zusammen. Bis zu diesem Einsatz liefen sie ja nur noch im Standby-Modus. Jetzt wo die Hauptspeicher und lokalen Platten mal wieder aktiv benötigt wurden, kamen die schwelenden Hardware-Fehler zum Vorschein!

Fazit:

Lassen sie es erst gar nicht so weit kommen. Sollten auch bei ihren Sicherungen lange Aufbewahrungszeiten verwendet worden sein, so überprüfen sie rechtzeitig und regelmäßig, ob die damals verwendeten Medien in der aktuellen Umgebung noch lesbar sind.

Der Hersteller hat die Lesbarkeit der Medien auf „n“ Jahre garantiert, sie haben die Sicherungen auch in doppelter Ausführung vorhanden, aber haben sie auch eine lauffähige Maschine mit der sie die Daten lesen können?

Wollen sie mehr über dieses Projekt erfahren, oder haben sie ähnliche Aufgaben und möchten diese weitgehend automatisiert haben, so wenden sie sich bitte an den  Autor, oder rufen sie uns unter der

+49 8250 92903

an.

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.