FAQs - Antworten
Frage:
Warum wirkt die Direktive "<< /tmp >> skip: .?* *" nicht ?
Antwort:
Auf einigen Betriebssystemen ist /tmp ein symbolischer Link auf /var/tmp. Da NetWorker bei der Sicherung keine symbolischen Links verfolgt, wirkt diese Regel nicht! Wenn also /tmp auf /var/tmp gelinkt ist, muss die Regel korrekt << /var/tmp >> skip: .?* * lauten.
Frage:
Warum werden bei eine 'skip'-Direktive einige Dateien von der Regel erfasst, andere jedoch nicht?
Antwort:
NetWorker ist case sensitive, d.h. er unterscheidet zwischen Groß- und Kleinschreibung. Dies tut NT leider nicht, schlimmer noch, der Explorer gaukelt Ihnen vor, die Dateien würden alle mit einem großen Buchstaben beginnen und die restlichen wären klein geschrieben. Dies ist jedoch in den allermeisten Fällen nicht der Fall. Betrachten Sie Ihre Dateien einmal mit dem DOS Eingabefenster, indem Sie hier dir eingeben. Sie werden sehen, die meisten Dateien werden anders geschrieben als sie der Explorer anzeigt. Wenn Sie sichergehen wollen, dass zum Beispiel alle Dateien mit der Endung .bmp geskipt werden sollen, müssen Sie auch die Großbuchstaben als Pattern angeben.
Z.B. skip: *.bmp *.BMP
Frage:
Warum wird mein Verzeichnis core nicht gesichert?
Antwort:
Wenn bei Ihrem Client eine UNIX Standard-Direktive angewählt wurde, so enthält diese folgende Regel:
<< / >> +skip: core
Diese Regel bewirkt, dass auf der ganzen Maschine keine Dateien namens core gesichert werden. Da in Unix Verzeichnisse auch Dateien sind, wird folglich auch kein Verzeichnis mit Namen core gesichert und damit der gesamte Inhalt dieses Verzeichnisses ebenfalls nicht.
Frage:
Die in der Literatur beschriebenen Direktiven zielen darauf ab, bestimmte Verzeichnisse eines Servers nicht zu sichern. Wie kann ich aber von einem Server nur drei Verzeichnisse sichern und den Rest nicht ?
Antwort:
Nichts einfacher als das! Nur dürfen Sie in diesem Fall nicht mit Direktiven arbeiten.
Um drei Verzeichnisse zu sichern, können Sie entweder das NetWorker Binarie "save" mit diesen
3 Verzeichnissen als Argument versehen (Skriptlösung), "save C:\tmp D:\xxx E:\yyy"
oder und das ist wahrscheinlich die Lösung die Sie suchen:
Sie tragen die drei gewünschten Verzeichnisse als SaveSet Namen in der NetWorker Client Resource ein.
In diesem Fall startet NetWorker bei der Sicherung des Clients drei Sicherungen. Für jedes Verzeichnis eine.
Frage:
Als compression-directive sollen u.a. gzip und bzip möglich sind. Wie lautet die genaue Driective ?
Antwort:
Zunächst möchten wir darauf hinweisen, dass die von Ihnen angesprochene Direktive nur
für die FSC-NetWorker Version auf den PlattformenSolaris und LINUX zur Verfügung steht!
Die Direktiven Syntax lautet:
compressasm -gzip [-<1-9>] : <files>
oder
compressasm -bzip2 [-<0-250>] : <files>
genauere Informationen können Sie der Manual-Seite uasm entnehmen.
Frage:
Wir hatten während eines Clonevorgangs einen kurzen Stromausfall. Da die Server an USVen hängen lief der Clonevorgang als solcher weiter. Nur der Rechner auf dem das Clone-Skript lief ist runtergefallen. Im Ergebnis ist der Clonevorgang wohl OK, aber die Retentionzeit und der Status wurden nicht gesetzt. Wie kann ich über die Kommandozeile die Retentionzeit und den Status für die Clones entsprechend setzen?
Antwort:
Die einzige Chance die Sie hier haben ist NetWorker den aktuellen Status per scanner beizubiegen. Er braucht ja nicht nur die IDs und die Zeiten, sondern auch die Positionen auf dem Band!
Daher empfehlen wir "scanner -m " des betroffenen Bandes.
Wenn Sie wissen, dass auf dem Band bereits erledigte und bekannte andere Clones existieren, so können Sie den Scanner auch ab einer definierten Bandmarke starten lassen (-f )
Frage:
Sind auf einer Maschine unterschiedliche Policies für verschiedene zurück oben Verzeichnisse möglich?
Antwort:
Sie wollen Daten eines Rechners beispielsweise generell 3 Monate recovern können. Einige besonders wichtige Daten sollen fünf Jahre aufgehoben werden.
Im Prinzip kein Problem.
Die jeweiligen Policies beziehen sich nicht nur auf die Maschine, sonder auch auf die SaveSet Namen.
Angenommen Sie haben zwei SaveSets /export/long und /export/long1 in denen die wichtigen Daten gesichert werden. Für diese SaveSets kann die Browse- und Retention-Policy entsprechend Ihrenr Wünschen eingestellt werden.
Sie generieren für die Maschine zwei Clients.
Der erste Client sichert den SaveSet "all", in dem jedoch die Sicherung der Verzeichnisse /export/long[1] durch eine Direktive ( null: long long1 ) ausgeschlossen werden sollte.
Der zweite Client erhält die beiden SaveSets /export/long und /export/long1 mit den entsprechenden Policies.
Achten Sie aber darauf, dass Sie für beide Sicherungsteile unterschiedliche Pools vorsehen, sodass die Bänder nicht unnötig lange blockiert werden.
Frage:
Ich möchte den NW-Server(Name A) auf einen anderen neuen NW-Server(Name B) umziehen. Der alte NW-Server soll als Client weiter betrieben werden. Nach der Disaster Recovery Beschreibung sollen der alte und neue Server den gleichen Namen haben, was hier aber aufgrund laufender Verfahren nicht geht. Welches ist die richtige Vorgehensweise zum Umzug der Medien- und Index-DB? Gibt es Erfahrungswerte bzw. Beschreibungen dazu ?
Antwort:
Das ist im Prinzip kein Problem, wenn es sich um die selbe Plattform handelt!
Sollte der Umzug aber auf eine andere Plattform (z.B. von Solaris nach Intel) geplant sein geht es so nicht!!!
Als Vorbereitung empfiehlt sich auf alle Fälle ein
1. ' nsrck -F ' damit die Index Datenbanken der Clients OK sind.
2. Danach ein ' savegrp -O -l full <group> ',
wenn möglich eine Gruppe in der alle Clients anthalten sind. Wenn es eine solche Gruppe nicht gibt sollten sie das savegrp Kommando so oft aufrufen bis alle Client Datenbanken gsichert wurden.
(Kann bei gleicher Architektur und Verwendung von rcp/scp entfallen).
3. Jetzt können Sie die Datenbanken an den neuen Rechner übertragen, dies kann per rcp/scp geschehen. Hier geht eben kein mmrecov, da die neue Maschine einen anderen Namen hat!
Das ist auch der Grund dafür, warum im Handbuch steht, die neue NetWorker Server Maschine sollte den alten Namen behalten.
Kopieren Sie am besten den kompletten /nsr Bereich auf die neue Server Maschine.
4. Kontrollieren sie die Namen Ihrer Tape devices sind diese auf der neuen Maschine identisch zu den alten?
Wenn nicht, sollten sie jetzt mit nsradmin die Laufwerksnamen anpassen.
' nsradmin -d /nsr/res/nsrdb ' und das selbe noch mal für die Jukebox.
5. Hiernach sollte der NetWorker Server sich auf dieser Maschine ohne Probleme starten lassen (alten Server zuerst stoppen).
Wenn Sie nicht gleichzeitig auf eine neu Version upgedatet haben, sind sogar die Lizenzen weiterhin gültig.
6. Wenn der Server läuft, sollten Sie wieder den 'savegrp -O -l full' durchführen, da der neue Server keinen Bezug mehr zur alten Bootstrap Sicherung und den Client Index-Datenbank Sicherungen besitzt.
Dieser Aufruf ist unbedingt wichtig!
7. Jetzt müssen sie nur noch an den Clients den neuen Server als berechtigten NetWorker Server (etc/defaults/nsr, ...) bekannt machen und der Umzug ist komplett.
Frage:
Im Betrieb mit unserem Roboter gibt es manchmal die Meldung, die etwa so lautet:
media alert event: Waiting for a writable Tape ..... usw.
Nach einer gewissen Zeit wird aus dem "alert" ein "critical". Ist die Zeitspanne dazwischen fest definiert? Oder kann man herausfinden, was genau vom alert bis zum critical geschieht?
Bisher sehe ich nur in der Datei "daemon.log" nach, aber erkennbar ist es dort nicht.
Antwort:
Sobald ein Medium benötigt wird, sendet der NetWorker Server, die Notification "Tape Mount Request 1", (Media Event, Priotity waiting).
Nach 15 Minuten wird dieser Event auf Priority Critical eskaliert. Hierdurch wird der "Tape mount Request 2" ausgelöst.
Der dritte "Tape Mount Request" (Priority Alert) folgt nach 37 Minuten ohne Medium. Diese Zeiten sind FIX. Daran läßt sich nichts ändern.
Frage:
Warum wird mein Pre-Kommando nicht mehr ausgeführt?
Antwort:
Dies liegt im allgemeinen daran, dass die savepnpc Lockdatei durch einen Abbruch der Sicherung nicht gelöscht wurde.
Löschen Sie auf dem Client die Dateien /nsr/tmp/....lck
Frage:
Warum kann ich die gesicherten Archive-Log Dateien im Recover Fenster vom NetWorker nicht sehen?
Antwort:
Für dieses Problem gibt es eine einfache Erklärung und auch eine einfache Lösung!
Die Archive-Log Dateien werden vom Archivierungsdaemon amon in Blöcken gesichert und anschließend gelöscht. Dies führt dazu, dass bei der nächsten Sicherung die alten Logfiles nicht mehr in dem Verzeichnis vorhanden sind. Durch das NetWorker TrueImage Recovery wird aber im Recover Fenster immer nur der letzte gesicherte Stand der Platte angezeigt. Dies ist ja auch gewollt und für ein Crash-Recovery einer Platte nötig.
Möchte man eine ältere Version einer Datei zurückholen, oder wie in Ihrem Fall eine Datei, die zu einem zurückliegenden Sicherungszeitpunkt gesichert wurde, im Recover Kommando ansehen, so bietet sowohl das GUI als auch das Alpha Kommando die Möglichkeit, mittels "change browse time" sich einen beliebigen Zeitpunkt in der Sicherungshistorie anzusehen.
Dieses Unterfangen ist jedoch bei der Suche nach einem bestimmten Archivelog File mehr als mühsam und auch nicht nötig! Das Alpha Kommando recover bietet Ihnen die Möglichkeit, eine bestimmte Datei direkt zu markieren. Hierzu müssen Sie lediglich das Kommando add <Logfilename> angeben. In diesem Falle sucht das Programm nach dieser Datei im aktuellen Verzeichnis, unabhängig von dem Sicherungszeitpunkt. Ein anschließendes list Kommando listet Ihnen die markierte Datei und liefert Ihnen auch den genauen Sicherungszeitpunkt.
Siehe auch die Man Page zum recover(8).
Frage:
Wie Frage ich mit dem Alpha Kommando nsradmin ein leeres Attribut ab?
Z.B. möchte ich die Clients ermitteln, die keinen Kommentar Eintrag besitzten!
Antwort:
Networker kennt seit der Version 7.4 die Option 'regexp'.
Mit ' option regexp '
gefolgt von 'print type:nsr client; comment: ^$'
kann man einen leeren String abfragen.
Frage:
Ich möchte eine Gruppe mehrmals täglich "incr" sichern (alle 4h). Dies habe ich in der Gruppen-Resource unter Interval eingestellt. Abends soll diese aber nach dem eingestellten Schedule gesichert werden (werktags mit einem bestimmten Level, am Wochenende "full")! Hierzu habe ich die Einstellung "Force Incremental" auf "Yes" gesetzt. Das Problem hierbei ist, das Networker nun keine Full- bzw. Level-Sicherungen mehr durchführt (nur noch incr.)!
Antwort:
Genau so, wie beschrieben, soll NetWorker funktionieren.
Abhilfe kann wie folgt geschaffen werden:
Es wird eine weitere Gruppe angelegt. Diese neue Gruppe erhält als Intervall 24h und zusätzlich einen Schedule definiert.
Dieser Schedule sorgt dann dafür, dass an Wochentagen eine Level- und am Wochenende eine Full-Sicherung durchgeführt wird. Und zwar unabhängig von den Einstellungen in der Client Resource.
Frage:
Wir haben verschiedene Clients mehrfach in unsere Konfiguration aufgenommen und wollten diesen verschiedene Storagenodes zuweisen. Tun wir dieses für ein Client, so werden auch bei den anderen Clients mit dem gleichen Namen die Storagenodes automatisch geändert. Ist dies ein BUG oder gewollt?
Antwort:
Das ist gewollt!
Die NetWorker Client Resource enthält einige Attribute die über alle Resourcen der gleichen Maschine propagiert werden.
Dies sind z.B. die Attribute "alias", "server network interface", "storage nodes" etc.
Wenn Sie die Sicherung eines Sub-Clients auf einer anderen StorageNode wünschen können Sie das nur mit Hilfe der Pool-Konfiguration erzwingen.
Frage:
Ich habe ein Problem mit meinem Networker, bzw. Clients und nwrecover.
Bei einigen Linuxinstallationen bekomme ich die Fehlermeldung"invalid time, browsetime unchanged", wenn ich die browsetime für die Rücksicherung ändern will.
Konkreter Fall :
Ein Networkerserver läuft unter SuSE Linux 7.3 . Die Eingabe von 'date' gibt folgendes : Tue Jul 2 12:35:10 CEST 2002
Client : SuSE Linux 7.1. Eingabe von 'date' gibt folgendes : Tue Jul 2 12:36:29 MEST 2002.
Ich hatte beim Client die Zone auf CEST geändert, Fehlermeldung war die gleiche.
Antwort:
Das Problem liegt an der Zeitangabe. nwrecover versteht nicht alle Zeitformate.
In Ihrem Fall ist das Problem wohl die Zeitzone. CEST gibt es normalerweise nicht. Das war/ist eine neue Kreation von Linux, die nicht im UnixStandard enthalten ist.
Einfach mal die Zeitzone im Feld "Browse Time" löschen und dann noch mal probieren!
Frage:
Das Recovern zwischen Linux-Server und NT-Cient funktioniert nicht.
Antwort:
Sie wollen die Daten, die ein NT-Rechner gesichert hat an einer Unix-Maschine recovern.
Dies ist leider nicht möglich, da Unix die Dateisysteme von NT nicht versteht und umgekehrt.
Frage:
Ich möchte auf die schnelle ein gesichertes Gesamt-Datenvolumen eines bestimmten Zeitraumes (z.B.Monats oder Woche) ermitteln (summiert).
Können Sie mir ein Tipp geben ?
Antwort:
Hier eine kurze Scriptidee zu Ihrem Problem.
mminfo -q 'savetime>="<datum>",savetime<="<datum>"' -r totalsize | awk 'BEGIN {sum = 0} { sum = sum + $1} END {print sum}'
Vorsicht wenn Sie Softwarekomprimierung verwenden, sind das die komprimierten Werte. Die Netto Werte lassen sich leider nicht ermitteln.
Frage:
können Sie mir sagen was der Fehlercode "Invalid codeset name(s) specified <UTF-8> or <8859-1>" bedeutet.
Antwort:
Bei den codesets ahndelt es sich um Zeichensätze bzw. Zeichencodierung die zur Verwendung der benutzten Zeichen verwendet werden. Der ISO8859-1 Zeichensatz representiert die europäischen Sprachen hier wird für jedes Zeichen ein Byte verwendet. Der UTF-8 Zeichensatz verwendet pro Zeichen 2 Byte und kann damit auch fernöstliche Zeichensätze darstellen. Seit einiger Zeit (NetWOrker 6.x) verwendet NetWorker intern den Zeichensatz UTF-8 zur Codierung der Dateinamen.
Frage:
Ich versuche gerade Bänder zu labeln, die alte Daten aus einer Unix-Sicherung enthalten.
Der Networker will dabei das Band bis zum Ende lesen
> im Monitor: ...es sind mehr Daten vorhanden.
Dies dauert sehr lange. Gibt es eine Möglichkeit die Bänder ohne Lesen bzw. Rücksprache zu labeln ?? Eventuell Konsolenbefehl? Wie komme ich in den Konsolenmodus ?
Antwort:
Gehen wir richtig in der Annahme, dass die Bänder mit tar oder dergleichen beschrieben wurden und keine alten NetWorker-Bänder sind?
Leider werden die Bänder in diesem Fall vor einem Labeln immer komplett gelesen.Sie können das Problem umgehen, in dem sie zwei Blöcke mit jeweils 32kb mit einem 'no rewind'-Laufwerk am Anfang auf das Band schreiben.Dann ist für NetWorker nach der zweiten 'filemarke' Schluß und das Band kann gelabelt werden.
Die NetWorker Kommandos lassen sich in jedem CMD-Fenster aufrufen, hier können die Medien mit dem Kommando nsrmm bzw. nsrjb gelabelt werden.
Für das Schreiben einzelner Blöcke läßt sich unter Windows das Programm
generate_test_tape.exe nutzen:
" generate_test_tape.exe -b 2 -f \\.\tape0 "
Frage:
Gibt es die Möglichkeit, für die Networker-Administratoren eine eigene Userkennung einzurichten?
Es wurde das Ziel formuliert, möglichst keine Root-Kennungen zu vergeben. Es soll eine Benutzerkennung sein, die alle Networker-Kommandos und Networker-Operationen ausführen darf, ohne allerdings andere root-spezifischen Kommandos (shutdown, hvswitch usw.) ausführen zu dürfen.
Bringt das Paket Networker so eine Funktion mit?
Antwort:
NetWorker bietet zwar mit der neuen Resource "user groups" seit der Version 7.0 die Möglichkeit Rollen in der NetWorker Administration einzubauen, aber diese Möglichkeit entspricht nicht dem von Ihnen beschriebenen Wunsch alle Kommandos als nicht root ausführen zu können. Ihren Wunsch nach alle NetWorker Kommandos soll ja nicht den NetWorker Admin einschränken, sondern diesem "nur" die "root" Rechte nehmen. Das geht nicht direkt vom NetWorker aus. Die einzige Chance die ich hier sehe ist das UNIX "sudo" Kommando, hier kann den Nutzern definiert zugewiesen werden welche Kommandos er als "root" ausführen darf, andere Kommandos kann dieser dann nicht als "root" starten!
Frage:
Ich möchte einen NetWorker Client anlegen und bekomme folgende Fehlermeldung als Popup: "Unable to connect to host: Please check NetWorker security settings and daemon.log on the NetWorker client an Console server fo more details." Was hat das zu bedeuten?
Antwort:
Wahrscheinlich sind folgende Ursachen:
1. Der Server ist nicht in der Serversdatei des Clients eingetragen oder wurde falsch geschrieben.
2. Die Namensauflösung funktioniert nicht sauber.
zu 1.: Wenn es Einträge in der Serversdatei auf dem Client gibt, muss auch der aktuelle Server eingetragen sein.
Hierzu die Datei <installationpfad>\res\servers (Windows) oder /nsr/res/servers (Unix/Linux) mit einem Editor öffnen und den aktuellen Server eintragen. Danach den NetWorkerdienst (nsrexecd) neu starten.
zu 2.: DNS oder hosts-Dateien korrigieren.
Frage:
Hallo liebe Networker-Spezialisten, Kann Networker abgebrochene Savesets noch nutzen? (aborted - Flag=ca) Hintergrund: Migration alter LTO1 + LTO2 Bänder auf LTO3. Wir müssen nun alle alten Bänder auf LTO3 klonen. Dazu nutze ich den Befehl "mminfo -q copies<2' -r 'volume,location,written'. Nun werden auch die abgebrochen Savesets angezeigt. Ich würde nun gerne diese Savesets löschen, bin mir aber nicht sicher ob Networker aus diesen Saveset doch Daten wieder herstellen kann? Eine andere Möglichkeit wäre folgender Befehl: "mminfo -q validcopies<2' -r 'volume,location,written'. Dort werden mir dann nur die gültigen Savesets angezeigt die wir klonen könnten. Wenn Bänder geklont werden und die erste Kopie gelöscht wird werden dann auch die Klone gelöscht? Wenn ja, würde das bedeuten das wir die alten Bänder immer behalten müssten? Über eine schnelle Antwort würde ich mich sehr freuen. Vielen Dank.
Antwort:
Teil 1 Ihrer Frage:
Nein aborted SaveSets können im Normalfall nicht genutzt werden (Ausnahme restartable SaveSets Neu in NetWorker 7.6.2). Ihr 2'ter mminfo Aufruf ist daher der korrekte.
Teil 2:
Wenn Sie nur die alten Medien Löschen (nsrmm -d <volume>) werden die Clones nicht gelöscht!
uws
Frage:
Ich habe meine Datensicherung umstrukturiert, um mal ein bißchen Ordnung in meine Bänder zu bekommen. Bislang hatte ich immer auf Default gesichert, das habe ich geändert.
Folgendes habe ich eingerichtet: Zwei neue Groups: Full und Inc, die als Clonepool Fullclone und IncClone haben. Die Clients sind in den Group Full und Inc drin, in alle anderen NICHT.
Pools und Templates habe ich entsprechend generiert, die Bänder damit gelabled. Funktioniert auch alles soweit. Nur wenn ich morgens reinschaue, verlangt NetWorker immer noch Bänder für Default.
Wo muß ich denn da noch gucken?
Antwort:
Wenn Sie eine incrementelle Sicherung machen, wird die Sicherung der Indices sowie des Bootstrap trotzdem mit dem Level 9 durchgeführt.
Das dürfte das Problem sein.
Kontrollieren können Sie das, indem Sie ein Band vom Pool Default mounten und anschliessend nachsehen welche Sicherungen auf dem Medium gelandet sind.
Um das gewollte zu erreichen sollten Sie in Ihrem Pool incr. den Level 9 hinzufügen.
Frage:
Ich will jeden Monat ein Archiv-Band ziehen (damit die DATEN nach einem Jahr nicht verfallen). Bei der Sicherung wird aber immer ein Default-Band verlangt. Wenn ich aber im Manage Pools bei Pool-Type "Backup" statt "Archive" eintrage, dann gelingt die Sicherung.
Antwort:
Der Pool-Typ Archive hat ist nicht für "normale" Sicherungen (Sicherungen mit Hilfe des Kommandos savegrp bzw save) geeignet.
Der Pool Type Archive ist nur für das NetWorker Archive Modul (eigene Lizenz auf UNIX) oder für die NT Archivierung (NT NetWorker User Kommando) gedacht.
Wenn Sie aber wie ich vermute, eine eigene Gruppe am Moantsende starten, die nur aus Ihrer logischen Sicht ein Archiv darstellen soll, ist das für NetWorker noch lange kein Archiv, sondern nur eine normale Sicherung.
Frage:
Hallo und guten Tag, ich habe folgendes Problem. Eine Sicherung wurde versehentlich auf ein älteres LT02 Band geschrieben. Das Band war leider nicht auf "read only" gesetzt. Diese Sicherung sollte aber auf ein LTO3 Band mit dem Pool "SO". Nun würde ich gerne die Sicherung bzw. die Savesets per NSRclone oder dergleichen von dem LT02-Band auf dem LT03-Band, wo die Sicherung immer darauf läuft mit dem Pool "SO" klonen. Dann hätte ich die Daten auf dem richtigen Medium mit der Aufbewahrungszeit von 10 Jahren. Leider ist der Pool "SO" ein Pooltyp "Backup" Das bedeutet wenn ich per NSCClone das Saveset "nsrclone -b "SO" -s 12345..." starte, bekomme ich die Rückmeldung das es sich nicht um eine Pooltyp "Backup Clone" handelt. Somit kann ich leider nicht die benötigten Saveset auf das Band mit dem Pool "SO" Klonen. Ich würde nur ungern eine bestehende Sicherungsgruppe in Networker ändern bzw. ein neuen Pool anlegen und Band Labeln müssen. Gibt es da vielleicht noch eine einfache Möglichkeit? Ich hoffe ich habe mit verständlich ausgedrückt. Vielen Dank und herzliche Grüße aus dem Norden.
Antwort:
Hallo,
das Problem lässt sich mit dem Kommando 'nsrstage' lösen. Hier für den Zielpool auch ein Pool Type 'Backup' möglich:
# nsrstage -m -S 12345 -b SO
Es wird zwar eine Fehlermeldung generiert, die besagt, dass der fragliche SaveSet nicht gelöscht werden kann
- dies ist auf Bandmedien tatsächlich nicht möglich -
aber der SaveSet wird trotzdem wie gewünscht auf ein Medium des angegebenen Pools geclont und anschließend wird der ursprüngliche SaveSet aus der MedienDB gelöscht.
Damit ist der SaveSet dann tatsächlich auf ein neues Band verschoben worden.
Frage:
warum wird nach einem Lizenzschlüssel gefragt? ich dachte ich könnte 30 tage kostenlos testen.
Antwort:
ST-Report verfügt auch in der DEMO-Version über alle Features und ist nicht eingeschränkt. Daher ist es notwendig einen Lizenzschlüssel zur Verfügung zu stellen.
Diese DEMO-Lizenz ist problemlos auf der Seite Produkte/ST-Report/Lizenzierung zu erstellen.
Es ist lediglich der NetWorker-Servername einzugeben und der Key kann heruntergeladen werden.
Dieser Key ist natürlich kostenlos und gilt 30 Tage.
Frage:
Ich möchte mit ST-Report eine Anfrage starten oder den Resourcen Cache neu laden, erhalte jedoch keinerlei Ausgaben bzw. das Programm scheint nicht zu reagieren.
Antwort:
Überprüfen Sie die Kommunikation ihres nsrexecd Prozesses mit dem NetWorker Server. Dieser Prozess muss im Hintergrund laufen, damit das Kommando mminfo ausgeführt werden kann.
Ab Version 7.5 muss außerdem der Client im NetWorker Server eingetragen werden.
Des weiteren muss der Name des NetWorker Servers auflösbar sein, er muss also entweder im DNS bekannt sein oder in die hosts Datei Ihres Betriebssystems eingetragen werden. Beachten Sie, dass der Name des Servers identisch mit dem Namen der generierten Lizenz sein muss, auch bei FQDNs.
Sie können Die Kommunikation mit dem NetWorker Server durch Aufruf des Kommandos mminfo testen. Geben Sie hierzu in einem Terminal das Kommando
mminfo -s <server_name>
ein. Dieses Kommando gibt Ihnen die Informationen über SaveSets in den letzten 24 Stunden aus und sollte daher eine Ausgabe produzieren.
