NetWorker: Troubleshooting von Ladeproblemen der Bandbibliothek in NetWorker

• Sporadische oder konsistente Fehler beim Laden von Bandkassetten in die Bibliothek
• Backups oder Recoveries von Bibliotheksmedien können nicht durchgeführt werden  
• Bibliothek ist erkennbar, funktionsfähig und bereit
• Lade- oder Etikettierungsvorgänge können nicht ausgeführt werden
• Bänder sind als "unbeschriftet" gekennzeichnet
• Mögliche ASC/ASCQ/SCSI SENSE-Fehler oder -Meldungen in System- oder Anwendungsprotokollen
• Sporadische oder konsistente Fehler beim Ausführen bestimmter oder zufälliger Bibliotheksvorgänge

Wenn die Bibliothekskonfiguration zuvor funktioniert hat und plötzlich ein Problem auftritt, sollten Sie mögliche Änderungen in Betracht ziehen, die die Erkennung und Konfiguration erschweren könnten:

• Änderung von Roboter-, Switch- oder Adapter-Firmware, -Treiber oder -Konfiguration
• Hinzufügen, Ersetzen oder Entfernen von Laufwerken, Bandkassetten oder anderen Bibliothekskomponenten
• Änderung der NetWorker-Softwareversion, Betriebssystem-Patches
• Hardwareereignisse wie Stromausfall oder Neustart einer Komponente im Datenpfad
• Diskrepanzen zwischen NetWorker-Konfiguration und -Bibliothek (z. B. Bandkassetten, die außerhalb der Kontrolle von NetWorker verschoben wurden)

Wenn die Bibliothek noch nie funktioniert hat, vergewissern Sie sich, dass die Hardware im Hardwarekompatibilitätsleitfaden zu NetWorker unterstützt wird (Anmeldung beim Dell Supportkonto erforderlich). Denken Sie daran, dass es möglich ist, dass eine Bibliothek teilweise funktionsfähig ist. Die Erkennung allein ist keine Garantie für die Benutzerfreundlichkeit oder Unterstützbarkeit.

Um Probleme beim Laden von Bibliotheken zu beheben, nachdem Sie die letzten bekannten Änderungen berücksichtigt haben, beheben Sie ihn, indem Sie den Prozess auf seine primitiven Komponenten übertragen und diese einzeln testen.

Die erforderlichen Daten werden erhoben NSRGet bei Ausführung mit dem -o:d übergeben werden. NetWorker: So verwenden Sie das nsrget-NetWorker-Datenerfassungs-Tool

Die Elemente, die dies nicht sind, sind auf die Vorgänge beschränkt, die als gefährlich angesehen werden könnten, wenn sie manuell versucht würden.
 

Laden der Bibliothek: Kommunikation

• Stellen Sie erneut sicher, dass die Bibliothek reagiert und bereit ist, bevor Sie fortfahren. Wenn nicht:
  • NetWorker: Troubleshooting von Problemen mit der Bandbibliotheksbereitschaft in NetWorker
  • Troubleshooting von Problemen mit dem Zugriff auf die Bandbibliothek in NetWorker
  • Troubleshooting von Problemen bei der Bandbibliothekserkennung in NetWorker
  • Troubleshooting von Hardwareproblemen mit der Bandbibliothek in NetWorker

Laden der Bibliothek: Physischer Betrieb

• Überprüfen Sie, ob der Bibliotheksbetrieb auf einer grundlegenden Ebene physisch möglich ist. Stellen Sie sicher, dass Tests durchgeführt werden, wenn die Bibliothek anderweitig nicht aktiv ist, und dass die Bandkassetten an ihren ursprünglichen Positionen ausgetauscht werden.

sjirdtag <changer address>

sjimm <changer address> <drive|slot|inlt|mt> <element_number> <drive|slot|inlt|mt> <element_number>

• Es gibt einige Situationen, in denen Fehler zu erwarten sind. Beispielsweise erhalten Bibliotheken, für die Auto-Eject auf Bibliotheksebene nicht aktiviert ist, einen Fehler beim Versuch, von einem Laufwerk zu einem anderen Element zu wechseln (die Bandkassette muss separat über ein mt -f <device_handle> offline vor dem Verlassen des Elements).
• Wenn sporadisch oder konsistent Fehler zurückgegeben werden, wenn Robotervorgänge oder SCSI-ASC/ASCQ-Codefehler auftreten, sollten Sie eine Eskalation an den Bibliotheksanbieter zur Überprüfung in Betracht ziehen.

Laden der Bibliothek: Logischer Vorgang

Sobald wir festgestellt haben, dass physische Vorgänge (zumindest oberflächlich) fehlerfrei sind, können wir versuchen, das Problem in NetWorker nachzuvollziehen.

• Bestimmen Sie das Layout der Bibliothek und stellen Sie ihre Bereitschaft sicher, indem Sie die Informationen zum NSR-Jukebox-Status mit den Bandkassetteninformationen des Roboters vergleichen:

nsrjb [<-j library_name>] -C
sjirdtag <changer address>

• Versuchen Sie, ein betroffenes Band mit hoher Ausführlichkeit in ein betroffenes Laufwerk zu laden:

nsrjb [<-j library_name>] -lvvvvv -f <device_handle> -S <slot_number>

Wenn die Bibliothek wiederholt ohne Probleme geladen wird, kann das Ladeproblem eher auf spezifische situative Faktoren als auf einen dauerhaften Fehler zurückzuführen sein. Es sollten alle Anstrengungen unternommen werden, um die Bedingung zu isolieren, die zum Lastausfall führt, und es sollte ein Debugging der Bedingung folgen (siehe unten).

• Wenn reguläre Ladevorgänge fehlschlagen, insbesondere wenn die Volumes als "nicht etikettiert" gekennzeichnet sind, ist der Lesevorgang des Etiketts während des Ladeversuchs fehlgeschlagen (was dazu führt, dass das Mounten fehlschlägt). Versuchen Sie, dasselbe Band mit hoher Ausführlichkeit erneut in dasselbe Laufwerk zu laden, ohne Folgendes zu mounten:

nsrjb [<-j library_name>] -lnvvvvv -f <device_handle> -S <slot_number>

• Führen Sie eine eigenständige Etikettierungsüberprüfung durch, um zu testen, ob der Lesefehler des Etiketts vorübergehend war oder konsistent ist:

nsrmm -pvvvvv -f <device_handle>

• Wenn das Etikett erfolgreich gelesen wird, löst sich das Problem möglicherweise durch die Leseversuche für das Etikett, die stattfinden, bevor das Bandgerät nach dem physischen Laden bereit ist. In diesem Fall können Sie versuchen, die Variable in der Systemumgebung oder im Startskript festzulegen:

MAX_LOAD_RETRIES=10

Wenn der Ladevorgang während eines zusammengesetzten Lade-/Mountvorgangs (Labellesevorgang) nach dem Festlegen der Variablen immer noch fehlzuschlagen scheint, wechseln Sie zum Abschnitt Debugging.

Laden der Bibliothek: Debugging

Wenn alle Stricke reißen, sammeln Sie die entsprechenden Daten, um das Debuggen des Problems zu unterstützen, bevor Sie Fachexperten (Subject Matter Experts, SMEs) konsultieren:

• Bevor Sie das Problem in NetWorker reproduzieren, ändern Sie das Debug-Trace-Level in der NSR-Jukebox-Ressource auf 5
• Verwenden Sie auch dbgcommand Um das Debug-Level der laufenden nsrd und nsrmmgd Prozesse auf 5
  • dbgcommand -n PROCESS_NAME Debug=5
  • So deaktivieren Sie: dbgcommand -n PROCESS_NAME Debug=0
  • NetWorker: Debug-Informationsebenen
• Betrachten truss/tusc/strace, pstack, gcore/gencore auf der entsprechenden nsrlcpd Vor und während des Problemereignisses
• Legen Sie die Debug-Variablen in der Systemumgebung (Windows) oder im Startskript (UNIX) fest, um umfangreichere Debugging-Daten zu erhalten:

SJI_DEBUG=9
LUS_DEBUG=9
CDI_DEBUG=9
SCSI_DEBUG=9
JBDEBUG=9

Wenn keiner der oben genannten Vorschläge hilft, wenden Sie sich an den Support Ihres Bibliotheksanbieters, wenn die beim Debuggen gesammelten Beweise auf interne Anomalien hindeuten, gemäß Troubleshooting von Problemen bei der Bandbibliothekserkennung in NetWorkerund Troubleshooting von Problemen mit dem Zugriff auf Bandbibliotheken in NetWorker; Andernfalls, stellen Sie sicher, dass die Debug-Ausgabe innerhalb des NetWorker-Supports eskaliert wird, um der Möglichkeit eines Codefehlers nachzugehen.