Im Rahmen eines Kunden Projektes konnte ich in dieser Woche eines der neuen Features der NetWorker Version 8.2.1 am produktiven System zum Einsatz bringen und ich kann nur sagen, darauf haben wir schon LANGE gewartet.

Worum geht es?

Bis zur Version 8.2.0 war eine NetWorker-Server-Migration (Umtausch der Hardware) offiziell nur unter der Beibehaltung des Server-Namens möglich. Diese Einschränkung ist nun durch das neue Kommando nsrclientfix  Geschichte.

Worin bestand das Problem wenn der Server-Name verändert wurde?

Wenn der NetWorker-Server auf einen anderen Maschinen-Namen migriert wurde, verlor der 'neue' NetWorker-Server seine Beziehungen zu den Index- und Bootstrap-Sicherungen. Diese stehen schließlich als Sicherungen des 'alten' Server-Namens in der Mediendatenbank. Das ist für den alltäglichen Betrieb zunächst mal kein Problem. Möchte man aber einen 'alten' Index wiederherstellen, um nicht mehr browse-bare Dateien im Index wieder sichtbar zu machen, sieht die Sache leider ganz anders aus. War also die Browse-Zeit einer Sicherungen abgelaufen, blieb nur das Einscannen der betreffenden Sicherungs-SaveSets. Leider ist dies aber nur für 'normale' Filesystem-Sicherungen möglich. Indexeinträge für NDMP-Sicherungen können nicht mit Hilfe des scanner Kommandos wiederhergestellt werden.  Indexeinträge von NDMP-Sicherungen konnten somit nachträglich weder mit den Kommandos nsrck, noch mit dem scanner Kommando wiederhergestellt werden. Es gibt zwar auch für dieses Problem eine Lösung (scanner | uasm mit anschließendem nsrck -L 6), diese ist allerdings etwas zeitaufwendig und mühsam.

Die Lösung des Problems!

Durch das neue Kommando nsrclientfix kann man jetzt (V8.2.1) nach einer erfolgten Server-Migration die Client-Zugehörigkeit der 'alten' Index-Sicherungen dem 'neuen' NetWorker-Server übergeben. Nach einem erfolgreichen Einsatz des Kommandos findet man die 'alten' Index-Sicherungen in der Mediendatenbank unter dem Clientnamen des neuen NetWorker-Servers wieder. Anschließend steht einem "nsrck -L 7" aller Clients (inklusive NDMP-Clients) nichts mehr im Wege. Somit können ab sofort auch die Browse-Zeiten der NDMP-Sicherungen auf einen erträglichen Zeitraum reduziert werden. Übergroße NDMP-Client-Indices sollten somit der Vergangenheit angehören.

Möchten sie mehr zu dem Thema NetWorker-Server-Migration wissen, dann besuchen sie einfach unseren NetWorker Admin 3 Workshop oder kontaktieren sie mich direkt.

Wie schon lange von Fujitsu und EMC versprochen hat der neue NetWorker Version 8.0 so ziemlich alle Fujitsu NetWorker Erweiterungen erhalten. Ja - auch das Firewall Modul ist jetzt im NetWorker 8 vorhanden - auch wenn dieses nicht explizit von EMC erwähnt wird.

Damit hat der EMC NetWorker 8 alle nötigen Funktionen, so dass einer Migration der NetWorker Version von FTS zu EMC nichts mehr im Wege stehen sollte.

Hier noch einmal eine Auflistung der wichtigsten nun integrierten FTS Features:

• Firewall Modul
• scm_filter
• "server network interface" Attribute für Devices und Jukeboxen
• compression directive (gzip, bzip2)
• automatisches Rollover der daemon.raw
• Beruhigen eines NetWorker Servers:
  • "accept new session" Attribute

Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit, sollte aber die wichtigsten Punkte enthalten.

Sollten SIe Fragen zur Migration von NetWorker-FTS zu NetWorker 8 von EMC haben, so scheuen Sie sich nicht uns per E-Mail zu kontaktieren. Nähere Informationen zur Umstellung, inklusive Aufzeigen eines Migrationsweges, erhalten sie auch in unserem NetWorker 8.0 Update Workshop

Der Kunde wollte seine NetApp NDMP Sicherungen von einem "alten" NetWorker Server auf einen neuen bereits aktiven NetWorker Server migrieren. Folglich sollten alle Bänder (600 an der Anzahl) im neuen NetWorker Server bekannt gemacht werden.

Da es ja keine Fleißaufgabe werden sollte und sich kein vernünftiger Mensch freiwillig vor den Bildschirm setzt um 600 Bänder für das Einlesen der Bänder zu wechseln, sollte das ganze per Skript gelöst werden. An sich ja alles nicht so schwierig, aber der Teufel lag mal wieder im Detail!

Hier die Idee:

1. Export der Medien
2. Import der Medien
3. Sortieren der Barcodes nach dem Sicherungsdatum
   • mminfo -av -ot -p <pool> -r barcode
4. Entfernen der recyclebaren Medien
5. Scanner Script dass Band für Band abarbeitet

•  Laden des Mediums
•         disablen des Laufwerks
•         scanner -m <device>
•  Eine Schleife über alle restlichen Bänder
  •      Warten bis der scanner sagt, er will das nächste Band
  •      Enablen des Laufwerks
  •      umount des Bandes
  •      Mount des nächsten Bandes
  •      disabeln des Bandes
  •      Scanner mitteilen, das nächste Band ist bereit

Soweit die Idee, nur leider spielte das Scanner Kommando nicht mit :-(

• Ein "Scanner -z" hat für NDMP leider einen bereits bekannten BUG.

• Die Abfrage nach dem nächsten Band läßt sich  nicht automatisieren.

Nachdem auch kein Googlen und Trussen weiterhilft, konnte eine Anfrage an die FTS-Entwicklung doch noch Abhilfe schaffen! FTS kannte das Problem bereits und hatte für einen ähnlichen Fall einen Scanner entwickelt, der eine Nachfrage nach dem nächsten Band mittels einer Datei ermöglicht. Mit diesem Spezial-Scanner konnte das oben skizierte Skript doch noch zum Einsatz kommen.

Jetzt fehlte nur noch der Aufbau der alten Index-Einträge sowie die Anpassung der Rention-Zeiten und die Migration war geschafft!