NetWorker: Anleitung zum Debuggen von Backupvorgängen

Protokolldateien:

Die wichtigsten Protokolle für das Debuggen von Backupfehlern sind die Policy-Protokolldateien , die sich am folgenden Speicherort befinden.

Linux: /nsr/logs/policy_name/workflow_name/action_name
Windows: ..ProgrammdateienEMC NetWorker srlogspolicy_nameworkflow_nameaction_name

Es gibt Workflowprotokolldateien im Raw-Format unter /nsr/logs/policy/policy_name/workflow_name/jobid.raw und ein Unterverzeichnis für jede Aktion. Jede untergeordnete Aktion einer Aktion verfügt über eine eigene Protokolldatei mit der Job-ID dieses untergeordneten Jobs. Wenn die übergeordnete Aktion eine untergeordnete Aktion startet, erstellt NetWorker ein Verzeichnis für diese untergeordneten Aktionsprotokolle.

Beispiel:

Hier sehen wir, wo sich die Policy-Protokolle befinden und dass die Protokolle je nach Debug-Level, das während des Backups verwendet wird, unterschiedlich groß sind.  Bei den Raw-Dateien handelt es sich um die Workflowprotokolle, während die Verzeichnisse backup_[jobid]_logs die Aktionsprotokolle und untergeordnete Aktionsprotokolle enthalten.

Die NetWorker-Hauptprotokolldatei für alle NetWorker-Vorgänge ist die daemon.raw Protokolldatei. 

Dies befindet sich in [NetWorker_install_dir]Protokollen.
 

Um dieses Protokoll zu lesen, verwenden Sie den Befehl nsr_render_log .

Beispiel:

Weitere Ressourcen:

Sparen Sie auf dem NetWorker-Client

Clientbasierte NetWorker-Backups verwenden den Speicherprozess. Der Speichervorgang kommuniziert mit dem NetWorker-Server, dem Speicher-Node (sofern zutreffend) oder dem Zielbackupgerät. Das Debuggen kann für den Speicherprozess aktiviert werden, indem das Debug-Flag -D mithilfe der NetWorker Management Console (NMC) oder mithilfe des Befehls nsradmin an den Speicherprozess übergeben wird.

In der NMC ändern Sie das Feld "Backupbefehl" in den entsprechenden Clienteigenschaften in "save -D9":

Beispiel:

Sie können denselben Vorgang mit dem Befehl nsradmin durchführen:

Beispiel:

Alternativ können Sie auf einem Linux-System den Befehl printf verwenden, um diese nsradmin-Änderung in einer Zeile vorzunehmen:

Beispiel:

printf "show 
 . type : NSR Client; name : vm-lego-231; save set : /alice
 update backup command : save -D9
" | nsradmin -i -

Weitere Ressourcen:

NetWorker – Befehlsreferenzhandbuch
Verwendung der nsradmin-Validierungsprüfung von
NetWorkerSpezielle Verwendungszwecke für das NetWorker-Programm nsradmin – Technischer Hinweis

Workflowvorgang auf dem NetWorker-Server 

Debuggen, der Start eines Workflowvorgangs und eine detaillierte Debuggingausgabe sind erforderlich.

nsrworkflow -D9 -p [Richtlinie] -w [Workflow]

Dadurch wird die Debug-Ausgabe des Workflowjobs in der Raw-Datei protokolliert in:

/nsr/logs/policy/policy_name/workflow_name/

Beispiel:

Durch Ausführen des Befehls nsrworkflow wird der Job manuell initiiert. Verwenden Sie jedoch dieselben Planungs- und Levelkonfigurationsoptionen, die für ein geplantes automatisiertes Backup verwendet werden.  Eine weitere Möglichkeit besteht darin, das Flag -a zu verwenden, um die nsrworkflow-Ausführung als Ad-hoc-Backup zu definieren, wodurch der Backup-Zeitplan oder -Level überschrieben werden kann.  Um das gewünschte Backuplevel anzugeben (nicht das, was für die heutige Ausführung des Workflows festgelegt ist), verwenden Sie -l (oder -L für Backups virtueller Maschinen).

Beispiel:

nsrworkflow -p [policy] -w [workflow] -A "'[action]' -l [level]" -a
nsrworkflow -p Mona -w Bokonon_wf -A "'backup' -l full" -a

Weitere Ressourcen:

516616 : Verwendung des NetWorker-Befehls
nsrworkflow513030 :                                                                     Verwendung des NetWorker-Befehls
nsrpolicyNetWorker 9.1.x – Versionshinweise: 
NetWorker – Befehlsreferenzhandbuch

Savefs auf dem NetWorker-Client

Der savefs-Befehl wird während clientbasierter Backups verwendet. Sie wird an den NetWorker-Client gesendet, nachdem das Backup auf dem NetWorker-Server initiiert wurde.  SaveFS ist dieser Prozess, der dafür verantwortlich ist, die Dateien und Verzeichnisse zu bestimmen, die für diese bestimmte Backupausführung auf diesem Client gesichert werden sollen.

Sie können den genauen savefs-Befehl, der auf der Clientseite ausgeführt wird, aus der Raw-Datei in den Policy-Protokollen (/nsr/logs/policy/[policy-Name]/[Workflow-Name]) abrufen.  Führen Sie dies dann clientseitig aus und fügen Sie die Option -D9 hinzu:

Beispiel:

Auf dem NetWorker-Server: 

Und dann zur Client-Seite:

Weitere Ressourcen:

Zuweisen von Zielmedien auf dem NetWorker-Server

Die Zuweisung des richtigen Ziel-Volumes für ein Backup wird vom nsrd-Prozess auf dem NetWorker-Server gemanagt.  Um dies zu beheben, müssen Sie das Debug-Level des nsrd-Prozesses auf dem NetWorker-Server mithilfe des Befehls dbg vorübergehend erhöhen.

Beispiel:

Nachdem das Debuggen abgeschlossen ist, müssen Sie das Debugging wie folgt deaktivieren:

Weitere Ressourcen:

336123 : NetWorker-Debugging

Backups, die auf beschreibbares Volume warten

Wenn der NetWorker-Server kein geeignetes NetWorker-Volume zum Schreiben finden kann, reagiert er nicht mehr und erzeugt eine Warnmeldung.  In diesem Fall befindet sich der Job im Status "aktiv".  Sie können den Status des Jobs mit dem Befehl nsrpolicy monitor überprüfen.

Beispiel:

Die Warnmeldung in der NetWorker Management Console enthält weitere Details dazu, welcher Typ von Volume auf welchem Storage Node gesucht wird.

Beispiel:

Weitere Ressourcen:

Backups reagieren aufgrund von Parallelität unerwartet nicht mehr

Wenn der NetWorker-Server feststellt, dass er mit dem Backup nicht fortfahren kann, weil kein freier Parallelitätssteckplatz vorhanden ist.  In diesem Fall befindet sich der Job im Status "in der Warteschlange".

Um die Parallelität zu debuggen, müssen Sie das Debug-Level des nsrjobd-Prozesses auf dem NetWorker-Server erhöhen, wie unten gezeigt.  Die Daemon-Protokolldatei gibt eine Menge Debugging-Daten relativ zur Parallelität aus.

Beispiel:

Weitere Ressourcen:

NetWorker – Handbuch zur Performanceoptimierungsplanung
Parallelitäts- und Zielsitzungen

Client Direct-Backup funktioniert nicht wie erwartet

Ein "Client Direct"-Backup sendet Daten direkt vom NetWorker-Client an die Zielmedien, ohne zuerst auf den NetWorker Storage Node zu schreiben.

Sie können in den Client-Eigenschaften festlegen, ob für diese Client-Instanz ein Client-Direct-Backup verwendet werden soll oder nicht.

Um ein Troubleshooting durchzuführen, ob Client Direct funktioniert oder nicht, müssen Sie die Protokolle wie im folgenden Beispiel gezeigt überprüfen:

Beispiel:

Protokollausgabe: Client Direct ist in Betrieb.

Daemon-Protokolldatei auf dem NetWorker-Server:

91787 01.08.2014 13:37:35 nsrmmd NSR-Hinweis Die Saveset-ID "4091251191" (vm-lego-231:/NetWorker) verwendet das direkte Speichern von Dateien mit dem Data Domain-Gerät "dd4500-dd.local_onetwoone".

lsof auf dem NetWorker-Client

[root@vm-lego-231 ~]# lsof -i TCP | grep speichern
speichern speichern 9831 root 3u IPv4 111668 0t0 TCP vm-lego-231:23178-vm-lego-121>:8985 (ETABLIERT)
speichern 9831 root 5u IPv4 111695 0t0 TCP vm-lego-231:19752-vm-lego-121>:9417 (ETABLIERT)
speichern 9831 root 7u IPv4 111720 0t0 TCP vm-lego-231:31095-vm-lego-121>:9035 (ETABLIERT)
speichern 9831 root 8u IPv4 111728 0t0 TCP vm-lego-231:12421-vm-lego-121>:9653 (ETABLIERT)
save 9831 root 9u IPv4 111731 0t0 TCP vm-lego-231:33739-dd4500-dd.local>:nfs (ESTABLISHED)
save 9831 root 10u IPv4 111736 0t0 TCP vm-lego-231:60278-dd4500-dd.local>:midnight-tech (ETABLIERT)

Hinweis: Wir sehen, dass offene TCP-Verbindungen vom Client zum NetWorker-Server und zur DD vorhanden sind.  Wenn Sie wissen müssen, mit welchen Prozessen auf dem NetWorker-Server genau verbunden ist, können Sie dies mit lsof auf dem Server überprüfen.  Die vierte Spalte ist der verwendete Dateideskriptor. 

Auf einem Windows-System können Sie eine ähnliche Ausgabe sehen, indem Sie resmon verwenden:  Start - Ausführen - resmon - Registerkarte "Netzwerk" - TCP-Verbindungen

Protokollausgabe:  Das Backup verwendet nicht Client Direct.

Daemon-Protokolldatei auf dem NetWorker-Server:

91797 01.08.2014 13:57:51 nsrmmd NSR schwerwiegend Direkte Dateisicherung mit Data Domain-Gerät "ONETWOONE" nicht möglich; Einrichten des herkömmlichen Speichers für die Saveset-ID "4024143566" (vm-lego-231:/NetWorker)

Hinweis:  Wenn Sie im Protokoll nach dem Wort "traditionell" suchen, erhalten Sie diese Ausgabe schnell.  Wenn Sie herausfinden möchten, warum Client Direct nicht verwendet wird, beginnen Sie mit der Liste der Bedingungen im NetWorker Administration Guide, die erfüllt sein müssen, damit Client Direct funktioniert.  Die häufigsten Gründe sind, dass der Client über keinen direkten Netzwerkzugriff auf die DD von der verwendeten NIC verfügt oder dass die Namensauflösung vom Client aus nicht ordnungsgemäß funktioniert.

lsof auf dem NetWorker-Client:

[root@vm-lego-231 ~]# lsof -i TCP | grep speichern
speichern speichern 10114 root 3u IPv4 123335 0t0 TCP vm-lego-231:46461-vm-lego-121>:8985 (ESTABLISHED)
speichern 10114 root 5u IPv4 123369 0t0 TCP vm-lego-231:12593-vm-lego-121>:9417 (ETABLIERT)
speichern 10114 root 7u IPv4 123392 0t0 TCP vm-lego-231:63952-vm-lego-121>:9035 (ETABLIERT)
speichern 10114 root 8u IPv4 123400 0t0 TCP vm-lego-231:29597-vm-lego-121>:9653 (ETABLIERT)

Hinweis:  Hier sind nur TCP-Verbindungen zum NetWorker-Server (der in diesem Beispiel auch der Storage Node ist) geöffnet.  Es ist keine TCP-Verbindung für die DD geöffnet.  Alle Daten werden an den Speicher-Node übertragen.

Weitere Ressourcen:

Handbuch zur Planung der Leistungsoptimierung bei NetWorker

Parallele Savestream-Backups

So debuggen Sie PSS-Backups. Stellen Sie sicher, dass die Eigenschaft "paralleler Speicherstream" in der Clientressource in der NetWorker Management Console aktiviert ist.  Ändern Sie den Speicherbefehl so, dass er gemäß Nummer 1 oben in den Debug-Modus versetzt wird.  Erstellen Sie außerdem eine leere Datei in .. /nsr/debug mit dem Namen 'mbsdopen'.  Dies bietet eine zusätzliche Debug-Protokollierung sowohl auf dem Client in /nsr/tmp als auch in den Policy-Protokollen auf dem NetWorker-Server (siehe Nummer 1 oben).

Beispiel:

Weitere Ressourcen:

Troubleshooting von parallelen NetWorker-Savestream-Backups
NetWorker – Handbuch zur Performanceoptimierungsplanung

Der nsrmmd-Prozess des NetWorker-Storage-Node funktioniert beim Schreiben auf die Zielmedien nicht wie erwartet.

Sie können das Debug-Level der nsrmmd-Prozesse mithilfe des Befehls dbg erhöhen (siehe Nummer 7 oben).  Sie können entweder das Debug-Level aller nsrmmd-Prozesse erhöhen oder mithilfe von Betriebssystemtools ermitteln, welcher nsrmmd-Prozess aktiv ist:

Weitere Ressourcen:

479665 : Triage-Artikel: Troubleshooting von Bandbibliotheksproblemen in NetWorker
NetWorker Data Domain Boost – Integrationshandbuch

Weitere Debugging-Tipps für bestimmte NetWorker-Technologien:

• Tuning von NetWorker-Server für optimale Leistung

• NVP-vProxy: So aktivieren Sie die Debug-Protokollierung  

• So testen Sie die NetWorker-Client-Server-Kommunikation durch eine Firewall 

• Troubleshooting von Fehlern beim geplanten Klonen mit NetWorker

• NetWorker – Troubleshooting-Handbuch: Prozessabstürze und Core-Speicherabbilder

• NetWorker NMC 9.x: So aktivieren Sie die Debug-Protokolle

• So aktivieren Sie das Debuggen für NMDA

• Detailliertes Troubleshooting-Handbuch zu NMM

• Anleitung zum Debuggen von Wiederherstellungsjobfehlern von NMC          

• NDMP-Triage-Handbuch           

• 479591 : Selektierungshandbuch zur Rückgewinnung von Speicherplatz von Data Domain-Geräten