NetWorker: Anleitung zum Debuggen von Backupvorgängen

Zusammenfassung: Es werden verschiedene Optionen für das Debugging eines fehlgeschlagenen NetWorker-Backups aufgeführt.

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Weisungen

Es stehen verschiedene Optionen zum Debuggen eines NetWorker-Backupfehlers zur Verfügung. In diesem Wissensdatenbank-Artikel werden die verschiedenen Debuggingoptionen beschrieben, die davon abhängen, welche Funktion des Backupprozesses Sie debuggen möchten. 

1. 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 (Standardeinstellung): C:\Program Files\EMC NetWorker\nsr\logs\policy_name\workflow_name\action_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 dem jobid dieses Kinderarbeitsplatzes. Wenn die übergeordnete Aktion eine untergeordnete Aktion startet, erstellt NetWorker ein Verzeichnis für diese untergeordneten Aktionsprotokolle.

Beispiel:

Die Protokollgrößen variieren je nach dem Debug-Level, das während des Backups verwendet wurde. Bei den Rohdateien handelt es sich um die Workflowprotokolle, während die backup_[jobid]_logs Verzeichnisse enthalten die Aktionsprotokolle und untergeordnete Aktionsprotokolle.

Beispiel für den Inhalt von Policy-Protokollordnern 
 

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

Linux: /nsr/logs/daemon.raw
Windows (Standardeinstellung): C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw


Um dieses Protokoll zu lesen, verwenden Sie den Befehl nsr_render_log Befehl, siehe: NetWorker: So verwenden Sie nsr_render_log zum Rendern .raw Protokolldateien

Beispiel:

Beispiel für das Rendern eines NetWorker-Rohprotokolls

Weitere Ressourcen:

2. save 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 der nsradmin Befehl.

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

Beispiel:

Konfigurieren von Debug-Backups für einen NetWorker-Client

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

Beispiel:

Konfigurieren des Backup-Debuggings von nsradmin

Weitere Ressourcen:

 

3. Workflowvorgang auf dem NetWorker-Server: 

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

nsrworkflow -D9 -p [policy] -w [workflow]

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

/nsr/logs/policy/policy_name/workflow_name/

Beispiel:

Debuggen des NSR-Workflows 
 

Das Ausführen des Befehls nsrworkflow initiiert den Job manuell, verwendet jedoch dieselben Planungs- und Levelkonfigurationsoptionen, die auch für ein geplantes automatisiertes Backup verwendet werden. Eine weitere Möglichkeit besteht darin, die -a Flag zur Definition der nsrworkflow Ausführen als adhoc Backup, mit dem der Backup-Zeitplan oder das Backup-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 die -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:

4. savefs Auf dem NetWorker-Client:

Bei der savefs wird während clientbasierter Backups verwendet. Sie wird an den NetWorker-Client gesendet, nachdem das Backup auf dem NetWorker-Server initiiert wurde. savefs Dieser Prozess ist verantwortlich für die Bestimmung der Dateien und Verzeichnisse, 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 abrufen (/nsr/logs/policy/[policy name]/[workflow name]) enthalten. Führen Sie dies dann clientseitig aus und fügen Sie die -D9 Option:

Beispiel:

Auf dem NetWorker-Server: 

Beispiel für einen SaveFS-Prozess  

Und dann zur Client-Seite:

Ausführen von savefs debug über die Befehlszeile 

5. Zuweisen von Zielmedien auf dem NetWorker-Server:

Die Zuweisung des richtigen Ziel-Volumes für ein Backup wird von der nsrd auf dem NetWorker-Server verwaltet Um dies zu debuggen, müssen Sie vorübergehend das Debug-Level der nsrd auf dem NetWorker-Server mit dem Befehl dbgcommand.

Beispiel:

kA5f10000004JErCAM_2_7

Nachdem das Debuggen abgeschlossen ist, müssen Sie das Debuggen deaktivieren, indem Sie die Debug-Ebene auf Null zurücksetzen:

kA5f10000004JErCAM_2_8

dbgcommand kann gegen einen Prozessnamen oder eine Prozess-ID (PID) verwendet werden, Beispiel:

dbgcommand -n PROCESS_NAME Debug=DEBUG_LEVEL
dbgcommand -p PROCESS_ID Debug=DEBUG_LEVEL

Weitere Ressourcen:

WARNUNG: Das Prozess-Debugging darf nur mit der Absicht aktiviert werden, ein Problem zu beheben. Sobald die Fehlerbehebung abgeschlossen ist, muss das Prozess-Debugging deaktiviert werden. Einige Prozesse erzeugen möglicherweise viele Meldungen, wenn das Debuggen aktiviert ist. Dies kann zu einem Wachstum des Dateisystems und zu Speicherplatzproblemen führen.

6. 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 mithilfe der nsrpolicy monitor .

Beispiel:

Beispiel für nsrpolicy monitor

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

Beispiel:

NMC-Warnmeldungen, dass auf 1 beschreibbares Volume gewartet wird

Weitere Ressourcen:

7. Backups reagierten 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, befindet sich der Job im Status "in Warteschlange".

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

Beispiel:

Beispiel für die Aktivierung von nsrjobd debug 

Daemon-Protokoll zeigt Parallelitätsfehler an

Weitere Ressourcen:

8. 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.

Einstellungen für NetWorker-Client Direct-Backup

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: Clients direkt in Betrieb.

Bei der daemon.raw Datei auf dem NetWorker-Server:

91787 MM/DD/YYYY HH:mm:SS  nsrmmd NSR notice Save-set ID '4091251191' (vm-lego-231:/NetWorker) is using direct file save with Data Domain device 'dd4500-dd.local_onetwoone'.

lsof auf dem NetWorker-Client

[root@vm-lego-231 ~]# lsof -i TCP | grep save
save       9831    root    3u  IPv4 111668      0t0  TCP vm-lego-231:23178->vm-lego-121:8985 (ESTABLISHED)
save       9831    root    5u  IPv4 111695      0t0  TCP vm-lego-231:19752->vm-lego-121:9417 (ESTABLISHED)
save       9831    root    7u  IPv4 111720      0t0  TCP vm-lego-231:31095->vm-lego-121:9035 (ESTABLISHED)
save       9831    root    8u  IPv4 111728      0t0  TCP vm-lego-231:12421->vm-lego-121:9653 (ESTABLISHED)
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 (ESTABLISHED)

 

HINWEIS: lsof listet offene TCP-Verbindungen vom Client sowohl zum NetWorker-Server als auch zur DD auf. Um festzustellen, mit welchen Prozessen der NetWorker-Server verbunden ist, können Sie mit lsof auf dem Server. Die vierte Spalte ist der verwendete Dateideskriptor.

Auf Windows-Hosts können Sie ähnliche Diagnosen mithilfe von SysInternals Procmon durchführen.Dieser Hyperlink führt Sie zu einer Website außerhalb von Dell Technologies.


9: Client Direct Backup verwendet Client Direct nicht:

Bei der daemon.raw Datei auf dem NetWorker-Server:

91797 MM/DD/YYYY HH:mm:SS nsrmmd NSR severe Unable to perform direct file save with Data Domain device 'ONETWOONE'; setting up traditional save for save-set ID '4024143566' (vm-lego-231:/NetWorker)

 

HINWEIS: Auf der Suche nach dem Wort traditional Im Protokoll erhalten Sie diese Ausgabe schnell. In der Liste der Bedingungen, die erfüllt sein müssen, damit Client Direct funktioniert, finden Sie im NetWorker Administration Guide. Die häufigsten Ursachen sind, dass der Client keinen direkten Netzwerkzugriff auf die Data Domain hat oder die Namensauflösung nicht ordnungsgemäß funktioniert.

lsof Auf dem NetWorker-Client:
[root@vm-lego-231 ~]# lsof -i TCP | grep save
save      10114    root    3u  IPv4 123335      0t0  TCP vm-lego-231:46461->vm-lego-121:8985 (ESTABLISHED)
save      10114    root    5u  IPv4 123369      0t0  TCP vm-lego-231:12593->vm-lego-121:9417 (ESTABLISHED)
save      10114    root    7u  IPv4 123392      0t0  TCP vm-lego-231:63952->vm-lego-121:9035 (ESTABLISHED)
save      10114    root    8u  IPv4 123400      0t0  TCP vm-lego-231:29597->vm-lego-121:9653 (ESTABLISHED)
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:


10. PSS-Backups (Parallel Save Stream):

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 die save , um es gemäß Abschnitt 2 in debuggen zu versetzen. Erstellen Sie außerdem eine leere Datei in ../nsr/debug genannt 'mbsdopen'. Dies bietet eine zusätzliche Debug-Protokollierung sowohl auf dem Client in /nsr/tmp und in den Policy-Protokollen auf dem NetWorker-Server (siehe Abschnitt 1).

Beispiel:

PSS-Option in der NetWorker-Clientressource aktiviert

mbsdfopen-Datei

MBS-Dateien im TMP-Verzeichnis speichern 

Weitere Ressourcen:

11. NetWorker-Storage-Node nsrmmd Der Prozess funktioniert beim Schreiben auf das Zielmedium nicht wie erwartet:

Sie können das Debug-Level der nsrmmd Prozesse, die die dbgcommand (Siehe Abschnitt 5). Sie können entweder das Debug-Level aller nsrmmd oder verwenden Sie Tools des Betriebssystems, um zu ermitteln, welche nsrmmd Prozess ist aktiv:

nsrmmd-Prozesse 

Weitere Ressourcen:

Weitere Informationen

Betroffene Produkte

NetWorker

Produkte

NetWorker, NetWorker Series
Artikeleigenschaften
Artikelnummer: 000010035
Artikeltyp: How To
Zuletzt geändert: 30 Jan. 2026
Version:  8
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.