Wie bereits in einem früheren Blog beschrieben, wird eine fehlerfreie Authorisierung zwischen den einzelnen NetWorker-Komponenten (Server, NMC, StorageNode und Client) immer wichtiger.

Leider ist eine einfache Bearbeitung der Client-Zertifikate mit Hilfe der NMC aber nicht ohne administrativen Eingriff möglich.

In meinen NetWorker-Advanced Workshops entwickle ich mit den Teilnehmern ein nsradmin-Shell-Skript, das ein erweitern des Client-Administrator-Attributes auf allen NetWorker-Clients eines NetWorker-Servers ermöglicht. Das Ziel des Skriptes: Ein NMC-Administrator erhält die Erlaubnis, alle Client-Attribute der NMC-Rubrik 'local hosts' zu bearbeiten. Hierdurch kann ein NMC-Administrator dann auch falsche Zertifikate (peer informations) leicht an einer beliebigen NetWorker-Instanz Löschen.

Diese Shellskripte sind für das Hinzufügen einer Administrator-Kennung erst mal genügend, aber bei der mehrfachen Verwendung des Skripts werden doppelte Einträge erzeugt. Ausserdem gibt es einige hilfreiche Funktionen nicht, wie zum Beispiel:

• Löschen nicht mehr aktiver Admin-Kennungen auf allen Clients
• Löschen von doppelten Einträgen
• Anzeige des Ist-Zustands für definierte Clients
• ...

All diese Funktionen bringt unser neues NetWorker-Tool 'set_nsrexecd_admins' mit!

Hier eine kurze Übersicht der Funktionalität und die Usage des Tools:

1. Add

   Hinzufügen eines NMC-Benutzers als Client-Administrator zu allen oder zu definierten NetWorker-Clients.

2. Delete

   Löschen eines angegebenen Client-Administrators von allen oder definierten NetWorker-Clients.

3. Cleanup

   Entferne doppelte Einträge und den fehlerhaften 'root' Eintrag von den definierten Clients.

4. View

   Gib die aktuelle Client-Administrator-Liste aus.

5. Test

   Führe keine Veränderung an der Administrator-Liste durch, sondern zeige nur auf, welche Veränderungen durchgeführt würden.

Usage:

set_nsrexecd_admins: [-v]* [--add] [--nmc <NMC Server name>] [-m <client name>]* <username>
set_nsrexecd_admins: [-v]* --delete [--test | -n][--nmc <NMC Server name>] [-m <client name>]* <username>
set_nsrexecd_admins: [-v]* --cleanup [--test | -n] [-m <client name>]*
set_nsrexecd_admins: [-v]* --view [-m <client name>]*

    --add                       Add a new nsrexecd Administrator to the clients
    --delete                    Delete a nsrexecd Administrator from clients
    --cleanup                   Remove 'root' and double entrys
    --view                      Print the actual administrator list for clients


    --test                      Print what would be done, but don't do it
    --nmc <NMC Server name>     use this NMC-Machine-name for the administrator
    -m <client>                 work only on the given client[s]
    -v                          verbose

Für Testzwecke können Sie nach der Installation des Tools, die in alphabetischer Reihenfolge 10 ersten Clients Ihrer NetWorker-Umgebungbearbeiten.

Ein einfacher Download bietet Ihnen die Möglichkeit die alphabetisch 10 ersten Clients Ihrer NetWorker-Umgebung zu bearbeiten. Weitere Informationen und Konfigurationsmöglichkeiten befinden sich in der README-Datei des Tools.

Das vorliegende Tool kann auch als Beispiel für die Möglichkeiten zur Automatisierung durch unsere NetWorker-Python-Bibliothek dienen. Sollten SIe vor dem Problem stehen, bestimmte Aufgaben um  NetWorkerumfeld automatisieren zu wollen, so fragen Sie uns.
Wir können Ihnen mit Sicherheit eine Lösung anbieten oder entwickeln.

uws

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.

Ein Blick auf die NetWorker Authentifizierung

Die NetWorker Authentifizierung ist seit langem Bestandteil der NetWorker Instanzen. Dennoch gibt es immer wieder Unverständnis über das NetWorker eigene Authentifizierung-Verfahren, die Art und Weise, wie man die Client Schlüssel am geschicktesten verwaltet und wie man die lästigen SSL-Fehlermeldungen aus der NetWorker-Protokoll-Datei (logs/daemon.raw) wieder los wird. Aus gegebenen Anlass hier mal ein Versuch etwas mehr Klarheit in das Thema zu bringen.

Folgende Themen möchte ich hierbei betrachten:

1. Wie funktioniert die Authentifizierung?
2. Wie wird das Client-Zertifikat generiert und verwaltet?
3. Wie kann man mit der NetWorker-Management-Console (NMC) die Client Zertifikate verwalten?
4. Wie kann ich die Verwendung der Client-Zertifikate erzwingen?
5. Was sind die Fallstricke bei der NetWorker Authentifizierung?

Sollte einer der folgenden Meldungen in ihren Protokollen auftauchen, kann ihnen dieser Artikel hoffentlich weiter helfen.

…nsrexecd SSL critical 51 Unable to complete SSL handshake with host…

nsrexecd GSS An authentication request from xxx was denied. 
The 'NSR peer information' provided did not match the one stored by 
yyy To accept this request, delete the 'NSR peer information' resource with
 the following attributes from yyy's NSRLA database: name: xxx; 
NW instance ID: e7b5adc4-00000004-f1483d9e-55757b22-00010c00-5d22e929; 
peer hostname : xxx

89987:save: Cannot determine the job ID: Failed to register with server yyy: 
Authentication error; why = Client credential too weak. Continuing ... 
100128:save: Unable to update job with id '0' with command value 
'save -b dd -s yyy /etc/hosts': 
Invalid or NULL session channel
76677:save: Authentication error; why = Client credential too weak
90017:save: Cannot open a save session with NetWorker server 'yyy'

1. Wie funktioniert die Authentifizierung?

Jeder Kommunikationsaufbau zwischen 2 NetWorker-Komponenten, sei es Server zum Client, Ciient zum Serevr, Client zur StorageNode oder NMC zum Server, benötigt einen sogenannten Session-Key. Dieser Session-Key wird von den Client-Daemonen (nsrexecd) der jeweiligen Komponente mit Hilfe eines SSL Verfahrens erzeugt. Hierzu hat jeder nsrexecd eine eigene lokale Client-Ressource (NSRLA), die einen privaten und einen öffentlichen Schlüsselanteil enthält. Die öffentlichen Schüssel werden bei dem ersten Kommunikationsaufbau zweier Komponenten automatisch ausgetauscht und in den folgenden Kommunikationsversuchen jeweils auf ihre Gültigkeit überprüft. Erst nach der erfolgreichen Überprüfung der Schlüssel erhält, der anfordernde Prozess den nötigen Session-Key und die eigentlichen NetWorker Daten können übertragen werden.

2. Wie wird das Client-Zertifikat generiert und verwaltet?

Wie oben bereits erwähnt, ist der Client-Daemon nsrexecd zuständig für die Generierung und Übertragung des eigenen Zertifikats aber auch für die Kontrolle und Aufbewahrung der öffentlichen Zertifikatsanteile aller anderen NetWorker-Komponenten.

Wenn beim Start des Client-Daemons kein lokales Zertifikat existiert, generiert der nsrexecd-Prozess ein neues Zertifikat und hinterlegt dieses in die Client eigenen NetWorker-Ressource (NSRLA).

Jeder öffentliche Zertifikatsanteil, der bei einem Kommunikationsaufbau von einer NetWorker-Komponente an den jeweiligen anderen nsrexecd geliefert wird, wird von diesem in einer neuen NSR Peer Information Ressource gespeichert. Diese öffentlichen Zertifikatsanteile werden bei jeder folgenden Kommunikation auf ihre Gültigkeit überprüft.

3. Wie kann man mit der NetWorker-Management-Console (NMC) die Client-Zertifikate verwalten?

Ohne Eingriff des NetWorker Administrators hat nur der lokale 'root'-Benutzer der jeweiligen Client-Maschine und der Benutzer 'root' des NetWorker-Servers, das Recht die lokalen Client-Ressourcen (nsrladb) einer NetWorker-Komponente zu administrieren. Dies bedeutet, dass eine Administration zunächst nur mit dem Kommando nsradmin möglich ist. Hierzu startet man das Kommando nsradmin mit der Option "-p nsrexec -s <client name>".

Beispiel:

# echo "print type: nsrla " | nsradmin -i - -p nsrexec
                        type: NSRLA;
                        name: xxx.schaefer-tobies.lan;
              NW instance ID: \
1156637e-00000004-b830fb8b-50fd6397-00010c00-5d22e929;
                 certificate: \
"-----BEGIN CERTIFICATE-----
MIIB9DCCAV2gAwIBAQIBADANBgkqhkiG9w0BAQUFADBAMT4wPAYDVQQDEzUxMTU2
NjM3ZS0wMDAwMDAwNC1iODMwZmI4Yi01MGZkNjM5Ny0wMDAxMGMwMC01ZDIyZTky
OTAeFw03MTAxMDEwMDAwMDBaFw0zODAxMTgwMzE0MDdaMEAxPjA8BgNVBAMTNTEx
NTY2MzdlLTAwMDAwMDA0LWI4MzBmYjhiLTUwZmQ2Mzk3LTAwMDEwYzAwLTVkMjJl
OTI5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9+t2I9S+igGRFre7Y+Uz5
d+7oAtmD8rpSZiyM3BrzK3fquFfNGE/7CqYD47Zda5vSvgb8VFuhKj9Tc8giK1ZA
iMG6Rrarg+mXSJDrqBo7g2ojzc7LV3W9ORFnkzNsssHlJGfqrTkO75Z+oDTqGmoq
fIPSVyjecI6osvDt/rqwEwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEehNPAey6DY
uc1bivxL0fny7uBzwftHueyregurb8IBaZ4ncAiGdPKATNCV9zRn/qw/1XW+q9ZE
6/OYvCJ1yQpn6XVJFUWAeXAlUy1q9TFYBFjIFT9DlBTaomQcgLdAhW/rtuQxyAUu
ayMnxWXNraFL9DE5c+wPIb0pHm/q5Z+l
-----END CERTIFICATE-----";
                 private key: Not enough privileges to view this attribute;
                auth methods: "0.0.0.0/0,nsrauth/oldauth";
           max auth attempts: 8;
               administrator: "isroot,host=yyy", 
                              "user=root,host=localhost", 
              "user=root,host=xxx.schaefer-tobies.lan";
                        arch: x86_64;
                 kernel arch: x86_64;
                    CPU type: x86_64;
                machine type: desktop;
                          OS: Linux 3.0.76-0.11-default;
           NetWorker version: 8.1.1.6.Build.321;
              client OS type: Linux;

In dieser NetWorker-Client Ressource kann man dem Attribut "administrator" entnehmen, wer diese Ressource und damit auch die gesamte Client-Ressource-DB (nsrladb) administrieren kann. In unserem Beispiel kann man erkennen, dass hierzu im allgemeinen nur der Benutzer "root" der lokalen Maschine ("user=root,host=localhost") und der "root"- bzw. "System"- Benutzer des NetWorker-Servers ("isroot,host=sim-nw-8") berechtigt sind. Möchte man nun einen NMC-Benutzer dazu berechtigen, die lokalen Ressourcen eines NetWorker-Clients zu berabeiten, so muss sowohl der Dienste-Benutzer der NMC selbst, als auch der NMC-Benutzer in obige Administratoren-Liste eingetragen werden. Selbst wenn also die NMC auf dem selben Rechner wie der NetWorker-Server läuft, fehlt hier immer noch der Anmelde-Benutzer der NMC (z.B. Administrator). Erst wenn man diesen mit Hilfe des Kommandos nsradmin hinzugefügt hat, kann man die lokale Client-Ressource und die von diesem Client-gesammelten Schlüssel mit Hilfe der NMC verwalten.

Da der Benutzer "root"vom NetWorker-Server das Recht hat alle Client-Ressourcen zu administrieren, kann man mit Hilfe eines nsradmin-Skriptes allen NetWorker-Clients das benötigte Recht auf einmal eintragen lassen. Entsprechende Beispiel-Skripte werden unter anderem in unserem NetWorker Advanced Workshop erstellt. Wir haben aber auch eine fertige Skriptlösung, die es auf Basis der Programmiersprache Python ermöglicht, auf allen Clients eines NetWorker-Servers die Administratoren-Liste gleich zu halten, bzw neue Administratoren hinzuzufügen.

4. Wie kann ich die Verwendung der Client-Zertifikate erzwingen?

Nach der Installation einer NetWorker Client Paketes ist die Kommunikation zwischen diesem Client und dem NetWorker Server keinesfalls bereits abgesichert. Denn zusätzlich zu dem hier beschriebenen Kommunikationsverfahren (das auch nsrauth genannt wird) besitzt NetWorker noch sein altes  Authentifizierung-verfahren, das lediglich die Übereinstimmung von Namen überprüft (auch oldauth genannt). Im Default Falle führt jede NetWorker-Instanz (seit Version 7.3) das nsrauth  Authentifizierung-Verfahren durch, jedoch wenn dieses nicht erfolgreich war, fällt die Kommunikation auf das alte (oldauth) Verfahren zurück.Dies wird durch das Attribut "auth methods" (siehe obiges Beispiel) definiert. Möchte man die NetWorker-Kommunikation folglich auf das sichere Verfahren einschränken, so muss dieses Attribut auf allen NetWorker-Komponenten angepasst werden. Dies kann man zwar auch mit der NMC erreichen, bei mehr als 10 Clients empfiehlt sich hierfür aber ein "nsradmin-Skript".

5. Was sind die größten Fallstricke bei der NetWorker Authentifizierung?

   Ich kann hier leider nur die wichtigsten Probleme aufführen, es gibt weitere und mit Sicherheit auch mir nicht bekannte Probleme.

   • Mehrere Maschinen verwenden das gleiche Zertifikat!
     

     Dieses Problem tritt vor allem in Virtualisierungsumgebungen auf! Das für den Aufbau von neuen virtuellen Maschinen verwendete VM-Image enthält bereits den NetWorker-Client. Wenn vor der Fertigstellung des Images der NetWorker-Client bereits einmal gestartet wurde, enthalten die in der Folge aus diesem Image erstellten Maschinen alle das selbe Zertifikat.

     Lösung:
     Auf den Client Maschinen muss das bestehende Zertifikat durch ein neues ersetzt werden.Hierbei sollte man darauf achten, dass auch der in der NSRLA Ressource verwendete Host-Name korrigiert wird.

   • Beim ersten Start des NetWorker-Client-Daemons hatte die Maschine noch keinen Hostnamen

     In diesem Falle ist der Host-Name in der NSRLA Ressource localhost. Dies kann bei späteren Kommunikationen zwischen NetWorker-Server und NetWorker-Modulen zu Problemen führen. Sollte eine NetWorker-StorageNode mit einem solchen Zertifikat aufgebaut worden sein, so kann das den ganzen NetWorker-Server lahm legen!

     Lösung:
     Auch hier muss auf den betreffenden Maschinen ein neues Zertifikat generiert werden.

   • Der Client wird von einer alten Fujitsu-NetWorker Version (z.B. 7.4) upgegraded

     In diesem Fall wird das Zertifikat aus mir nicht bekannten Gründen nicht mehr akzptiert und die Clients Sicherung lässt sich nicht mehr starten!

     Lösung:
     Auch hier muss auf den betreffenden Maschinen ein neues Zertifikat generiert werden.

   • In dem Attribut 'auth methods' der NMC wurde der Eintrag nsrauth entfernt

     Auf Grund von "falschen" Problemlösungen, betreffend der SSL Fehlermeldungen in der NetWorker-Protokolldatei daemon.raw, wurde der Wert nsrauth aus dem Attribut auth methods entfernt. Hierdurch gibt es zwar keine Fehlermeldungen mehr wegen falscher Zertifikate, aber es kann auch keine sichere Verbindung zwischen den NetWorker Instanzen mehr erstellt werden. Wenn auf dieser Maschine später ein NetWorker-Modul oder die NetWorker-Management-Console laufen soll, verweigern diese ihren Dienst.

     Lösung:
     Das Attribut auth methods korrigieren und die falschen öffentlichen Schlüssel aus den Peer Information Ressourcen löschen.

   • Beim ersten Start des NetWorker-Client-Daemons existierte keine "servers"-Datei

     Dieser bei Linux Maschinen leider häufig vorkommende Umstand führt gleich zu 2 Problemen:

     • Zum Ersten erhält der Benutzer "root" von allen Maschinen durch die Administrator-Liste der NSRLA Ressource Administrationsberechtigung. Das Attribut administrator sieht in diesem Falle etwa so aus:

       
                     administrator: root, "user=root,host=xxx";
       
       
       
       

     • Zum Zweiten wird die Client-Authentifizierung zum Teil außer Kraft gesetzt!

       Es wird kein Zertifikat auf seine Gültigkeit überprüft. Dies gilt sowohl für den NetWorker-Server, wie für alle anderen Instanzen.

     Lösung:
     Die NSRLA Ressource und damit auch das Zertifikat der betreffenden Maschine muss nach der Erstellung der Datei "/nsr/res/servers" neu generiert werden.

   • Achtung: Änderungenan dem Attribut auth methods wirken zum Teil erst nach dem Neustart des NetWorker-Servers oder des betreffenden Client-Daemons.

Falls sie noch weiter gehenden Bedarf haben in die Thematik einzusteigen, empfehle ich ihnen unseren NetWorker Advanced Workshop zu besuchen. Hier arbeiten wir alle genannten Punkte  theoretisch aber auch praktisch in Übungen durch.

Oracle-NMDA Backups in großen NetWorker Umgebungen

Die Konfiguration einer NetWorker Oracle-Backup Umgebung hat sich durch die Einführung des NetWorker Moduls für Database Applications (NMDA) und dem zugehörigen NMC-Wizzard, auf den ersten Blick stark vereinfacht. Betrachtet man die Konfiguration aber in Umgebungen mit einer hohen zweistelligen, oder gar dreistelligen Zahl von Datenbanken, so macht sowohl die Migration bestehender Konfigurationen, als auch die Pflege der Oracle-RMAN-Skripte mit dieser Art der Datenbanksicherung-Konfiguration wenig Spass. Der Pflegeaufwand und der potentielle Wildwuchs der verwendeten RMAN-Skripte und NetWorker Konfigurationen wuchert doch sehr schnell aus.

Genau vor diesem Problem Stand ein Kunde bei der anstehenden Umstellung der Oracle-Datenbanksicherungen vom ehemaligen NMO Modul auf das aktuelle NMDA Modul. Die Anzahl der zu sichernden Datenbanken lag im dreistelligen Bereich. Es sollte also eine Möglichkeit gefunden werden,

• die Umstellung des Datenbankmoduls möglichst einfach zu gestalten.
• sowohl den Update-Vorgang des  NetWorker-Clients als auch des Datenbankmoduls zu automatisieren.
• die NetWorker Ressourcen automatisch vom alten Modul auf das neue Modul anzupassen.
• den anschließenden Pflegeaufwand der Datenbanksicherungskonfigurationen und der RMAN-Skripte zu minimieren.

Klingt auf den ersten Blick ziemlich unmöglich. Doch mit der richtigen Systemumgebung und einigen geschickten Randbedingungen war eine Idee ziemlich schnell gefunden und die Implementierung der Lösung war dann sogar relativ einfach.

Hier eine kurze Beschreibung der Randbedingungen und der implementierten Lösung:

Systemumgebung:

1. Alle Datenbanken befinden sich auf LINUX/UNIX Systemen
2. Die zu installierenden Software-Pakete befinden sich auf einem für alle Maschinen zugänglichen NFS-Share.
3. Es existiert eine sichere (gespiegelte) NFS-Umgebung auf der ein Share angelegt wird, der auf allen Datenbankmaschinen gemountet werden kann.

Randbedingungen:

1. Die Oracle RMAN-Skripte lassen sich durch die Verwendung einiger Oracle-Parameter für alle Datenbanken einer Oracle-Version verwenden.
2. Die NetWorker Ressource-Namen der Gruppen-, Schedule und sonstigen Ressourcen müssen standardisiert sein.
3. Der Save-Set des Clients definiert die Sicherungs-Parameter (Oracle-SID, RMAN-Sicherungstyp (Archive, Full, Level, ...))

Implementierte Lösung

Shell und Python-Skripte

Die Lösung des Problems bestand neben dem Aufbau einer geschickten Datenablage, in der Implementierung folgender Skripte:

1. Migrationsskript, das auf einer Oracle-DB-Maschine
   
   • die bestehende NetWorker-Umgebung analysiert
   • die "alten" NetWorker Pakete deinstalliert 
   • die "neuen" definierten NetWorker Pakete installiert
   • die alten NetWorker Ressourcen deaktiviert
   • neue NetWorker Ressourcen erzeugt
   • die Oracle-Backup-Library verlinkt
   • das Backup-Command verlinkt
   • den NFS-Mount des NFS-Ablageverzeichnisses in die /etc/fstab integriert
2. NetWorker Backup Command, das
   • anhand des übergebenen SaveSets, das definierte RMAN-Skript mit den benötigten Parametern aufruft.
   • das Rollieren der "alten" Backup-Protokolle durchführt

NFS-Ablage

Die gemeinsam genutzte NFS-Freigabe enthält folgende Datenstruktur:

1. Ein eigenes Verzeichnis für jede Datenbank mit dem Namen der Oracle-SID,  in dem neben einer Konfigurationsdatei  die Protokolle der Sicherungen und Wiederherstellungen abgelegt werden.
2. Ein Binarie-Verzeichnis, in dem die gemeinsam genutzten RMAN-Skripte und das implementierte NetWorker-Backup-Kommando liegen.

Fazit

Welche Vorteile bringt die implementierte Lösung?

• Leichtere Wartung der RMAN-Skripte. Nur noch wenige zentral abgelegte Skripte werden benötigt.
• Leichtere Fehlersuche, da bei Problemen die Protokolle und Konfigurationen von funktionierenden und fehlerhaften Sicherungen auf jeder Maschine direkt verglichen werden können. Ein mühsames Anmelden des NetWorker Administrators auf der jeweiligen Datenbankmaschine ist nicht mehr notwendig.
• Übersichtlichere NetWorker Konfiguration. In der Client-Ressource definiert alleine der SaveSet die Art der Oracle-Sicherung.
• Einfache und fehlerfreie Migration der alten NetWorker-Client Umgebungen in die neue NMDA-Umgebung.

Sollten sie Fragen zu diesem Blog haben oder vor ähnlichen Herausforderungen stehen, so scheuen sie sich bitte nicht sich per E-Mail an info@schaefer-tobies.de zu wenden.