NetWorker: Troubleshooting von Problemen bei der Bandbibliothekserkennung in NetWorker
Zusammenfassung: Dieser Artikel soll Support- und NetWorker-Administratoren dabei unterstützen, die Ursachen für die Nichterkennung einer Bibliothek durch einen Host zu ermitteln.
Weisungen
Wenn die Bibliothek zuvor funktioniert hat und plötzlich nicht mehr funktioniert, betrachten Sie die letzte bekannte Änderung als wahrscheinliche Ursache:
- Unbehandelte Änderung der Bibliotheksadresse nach Neustart, Neuerkennung und Umbenennung des Geräts
- Mögliche Schäden aufgrund von Überspannung, Stromausfall oder anderen Umgebungsereignissen
- Ausfallereignisse oder Neukonfiguration von Transporthardware
- Installation, Änderung oder Löschung von Software oder Treibern im Zusammenhang mit Transport oder Robotik
Wenn die Bibliothek noch nie funktioniert hat, vergewissern Sie sich, dass die Hardware im NetWorker-Hardwarekompatibilitätsleitfaden unterstützt wird (Anmeldung beim Dell Supportkonto erforderlich).
- Bandbibliotheksinstallation auf NetWorker-Speicher-Node oder -Server kann nicht erkannt werden
- Daten können aufgrund nicht verwendbarer Backuphardware nicht gesichert werden.
Um Fehler bei der Bibliothekserkennung zu diagnostizieren, berücksichtigen Sie zunächst alle kürzlich vorgenommenen Änderungen. Als Nächstes sollten Sie den Erkennungsprozess von seinen untersten Ebenen herunterbrechen und jede Phase testen.
Manchmal ist es wünschenswert, auf der Grundlage der verfügbaren Beweise zu einem weiter entwickelten Stadium der Entdeckung überzugehen. Wenn Host A den Roboter nicht erkennt, während Host B erfolgreich ist, ist der Roboter wahrscheinlich nicht schuld. Die Hosts können verschiedene Switches verwenden, sodass dies der erste Bereich ist, der untersucht werden muss. Weitere Unterschiede in diesem Beispiel betreffen den Host selbst, möglicherweise Betriebssystem, HBA, Zoning, Verkabelung usw.
Wenn der Gastgeber den Roboter vor dem Problem erkannt hat, konzentrieren Sie sich auf Elemente, die sich höchstwahrscheinlich geändert haben. Untersuchen Sie Fehler oder bekannte Konfigurationsänderungen nach dem Ereignis.
Verwenden Sie zunächst die folgenden Befehle, um festzustellen, ob das Betriebssystem die Bibliothek erkennen kann. Stellen Sie immer sicher, dass die Betriebssystem-Patches auf dem neuesten Stand sind, insbesondere was den Storage betrifft.
nsrget -o:d auf dem betroffenen Server und den betroffenen Nodes.
-o:d Auf jedem Host mit Bändern, auf denen die Bänder mit dem Schreiben beschäftigt sind. Sie können dies über die NetWorker Management Console (NMC) unter Monitoring -> Devices überprüfen.
Der folgende Artikel enthält Informationen zum Abrufen und Verwenden von NSRGET: NetWorker: So verwenden Sie das nsrget-NetWorker-Datenerfassungs-Tool
Bibliothekserkennung: Betriebssystem:
- Windows: Geräte, die vom PnP-Subsystem (Plug & Play) nicht erkannt werden, sind möglicherweise nicht für NetWorker zugänglich. Es gibt nie eine Instanz einer Bibliothek ohne Treiber, da ein generischer Treiber vorhanden ist, auch wenn kein Anbietertreiber installiert ist. StorPort ist die Low-Level-Komponente des Windows-Storage-Treibers, deren Aktualität überprüft werden sollte.
devmgmt.msc (Geräte-Manager)
devcon drivernodes *CHANGER*
- Linux: Zeigen Sie an, welche SCSI-Klasse-Geräte das Subsystem erkannt und aufgezählt hat. Linux verwendet die
sgTreiber für Bibliotheken, es sei denn, IBMs Atape-Treiber ist installiert (nicht empfohlen).
cat /proc/scsi/scsi (Erkannte Bibliotheken anzeigen)
echo "- - -" > /sys/class/scsi_host/host#/scan (Erneute Erkennung erzwingen)
- Solaris:
cfgadmoderluxadmHafen/dump_mapBefehle können beide ein Bibliotheksgerät auflisten. Gelingt dies nicht,update_drvkann verwendet werden, um sowohl die Erkennung als auch die Fähigkeit zum Anbringen einessgenTreiberinstanz.
cfgadm -lavo show_FCP_dev
for FCI in `luxadm -e port | cut -f1`; do luxadm -e dump_map $FCI; done
rm -f /dev/scsi/changer/*; update_drv -f sgen -v
- AIX: Verwenden Sie
cfgmgrunter den meisten Umständen; WennAtapeTreiber in Verwendung ist, verwenden Sielsdev. Stellen Sie in diesem Fall sicher, dass dieAtape smcDer Treiber wird als "definiert" und nicht als "verfügbar" aufgeführt (was zu Konflikten führt).
cfgmgr -v | grep -i changer
lsdev -Cc tape
rmdev -l smc0 (Wenn lsdev zeigt es als verfügbar an)
- HP-UX:
ioscanist der einzige Befehl, der zum Auflisten von Geräten der Wechslerklasse erforderlich ist.
ioscan -FnkC autoch
Für den NetWorker
inquire -Befehl (unten) Um erfolgreich zu sein, müssen Sie möglicherweise die temporäre Cache-Datei für die Geräteerkennung entfernen:
rm -f /tmp/lgto_scsi_devlist
- Openvms: Verwenden Sie die folgenden Befehle, um die Konnektivität zu überprüfen:
mcr sysman IO AUTOCONFIGURE
show device gk/full
- NetWorker: Diese Befehle werden als Referenz bereitgestellt und werden in der Regel auf einer höheren Ebene ausgeführt als die oben angegebenen Betriebssystembefehle. Sie können beim Versuch, ein Problem auf niedrigerer Ebene zu diagnostizieren, indem sie zusätzliche Informationen oder Fehler als Hinweise auf das vorliegende Problem bereitstellen, aber es wird nicht erwartet, dass sie erfolgreich sind, wenn Vorgänge auf niedrigerer Ebene fehlschlagen.
inquire -lc
lusbinfo -v
changers
dvdetect -dlV -D9
lusbinfo und changers Möglicherweise nicht auf allen Plattformen vorhanden. Falls gewünscht, können Sie die Debug-Level erhöhen, indem Sie die Umgebungsvariable LUS_DEBUG:
UNIX:
export LUS_DEBUG=9
Windows:
set LUS_DEBUG=9
AIX:
lusdebug ffff
Versuchen Sie auch:
SJI_DEBUG=9, SCSI_DEBUG=9, JBDEBUG=9
Weitere Informationen
Stellen Sie sicher, dass Sie verstehen, dass Robotikprobleme, die als außerhalb des Anwendungsbereichs von NetWorker liegen (d. h. mit den Standardbetriebssystemmethoden nicht erkannt werden können), nicht in den Umfang des NetWorker-Supports fallen.
Weitere Informationen finden Sie unter: NetWorker: Troubleshooting von Bandbibliotheksproblemen in NetWorker
Der Support kann anhand der oben genannten Kriterien Hilfestellung leisten, aber wir verfügen nicht über BS-, HBA- oder Robotik-Anbieterressourcen. Diese Einschränkung kann zu einer langwierigen, erfolglosen Fehlerbehebung führen.