NetWorker: Felsöka problem med identifiering av bandbibliotek i NetWorker
Sammanfattning: Den här artikeln är avsedd att hjälpa support- och NetWorker-administratörer att fastställa orsakerna till en värds oförmåga att identifiera ett bibliotek.
Instruktioner
Om biblioteket fungerade tidigare och plötsligt inte gör det, bör du betrakta den senast kända ändringen som den troliga orsaken:
- Ohanterad ändring av biblioteksadress efter omstart, återupptäckt och byte av namn på enheten
- Möjlig skada på grund av strömavbrott, strömavbrott eller annan miljöhändelse
- Felhändelser eller omkonfiguration av transporthårdvara
- Installation, ändring eller borttagning av programvara eller drivrutiner som hänför sig till transport eller robotteknik
Om biblioteket aldrig har fungerat kontrollerar du att maskinvaran stöds i NetWorker-kompatibilitetsguiden för maskinvara (inloggning till Dell-supportkonto krävs).
- Det gick inte att detektera installation av bandbibliotek på NetWorker-lagringsnod eller NetWorker-server
- Det gick inte att säkerhetskopiera data på grund av oanvändbar maskinvara för säkerhetskopiering.
Om du vill diagnostisera biblioteksidentifieringsfel bör du först överväga eventuella senaste ändringar. Bryt sedan ner identifieringsprocessen från dess lägsta nivåer och testa varje steg.
Ibland är det önskvärt att gå vidare till ett mer utvecklat upptäcktsstadium, baserat på tillgängliga bevis. Om värd A misslyckas med att upptäcka roboten medan värd B lyckas, är det sannolikt inte roboten som har fel. Värdarna kan använda olika switchar, vilket gör det till det första området att undersöka. Andra skillnader i det här exemplet är själva värden, eventuellt operativsystem, HBA, zonindelning, kablar osv.
Om värden upptäckte roboten före problemet fokuserar du på de objekt som mest sannolikt har ändrats. Undersök fel eller kända konfigurationsändringar efter händelsen.
Använd följande kommandon för att först ta reda på om operativsystemet kan identifiera biblioteket. Se alltid till att korrigeringsfilerna för operativsystemet är uppdaterade, särskilt när det gäller lagring.
nsrget -o:d på berörda servrar och noder.
-o:d på vilken värd som helst med band där banden är upptagna med att skriva. Du kan kontrollera detta från NetWorker Management Console (NMC) under Monitoring -> Devices.
Följande artikel innehåller information om hur du hämtar och använder NSRGET: NetWorker: Så här använder du datainsamlingsverktyget NSRGet i NetWorker (På engelska)
Biblioteksidentifiering: Operativsystem:
- Windows: Enheter som inte upptäcks av Plug-and-Play-undersystemet (PnP) kanske inte är tillgängliga för NetWorker. Det finns aldrig en instans av ett bibliotek utan en drivrutin, eftersom det finns en allmän drivrutin även om en leverantörsdrivrutin inte är installerad. StorPort är den komponent för Windows-lagringsdrivrutin på låg nivå som bör kontrolleras för valuta.
devmgmt.msc (Enhetshanteraren)
devcon drivernodes *CHANGER*
- Linux: Visa vilka SCSI-klassade enheter som undersystemet har identifierat och räknat upp. Linux använder
sgdrivrutin för bibliotek om inte IBM:s Atape-drivrutin är installerad (rekommenderas inte).
cat /proc/scsi/scsi (Visa upptäckta bibliotek)
echo "- - -" > /sys/class/scsi_host/host#/scan (framtvinga återupptäckt)
- Solaris:
cfgadmellerluxadmPort/dump_mapkommandon kan både räkna upp en biblioteksenhet. Om detta inte är möjligt,update_drvkan användas för att säkerställa både detektering och förmågan att fästa ensgendrivrutinsinstansen.
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: Använd
cfgmgrunder de flesta omständigheter; OmAtapedrivrutinen används, användlsdev. I det här fallet - se till attAtape smcDrivrutinen anges som "definierad" och inte "tillgänglig" (vilket orsakar konflikter).
cfgmgr -v | grep -i changer
lsdev -Cc tape
rmdev -l smc0 (om lsdev visar att den är tillgänglig)
- HP-UX:
ioscanär det enda kommando som krävs för att räkna upp enheter med växlarklass.
ioscan -FnkC autoch
För NetWorker
inquire Kommandot (nedan) För att lyckas kan du behöva ta bort den tillfälliga cachefilen för enhetsupptäckt:
rm -f /tmp/lgto_scsi_devlist
- Openvms: Använd följande kommandon för att verifiera anslutningen:
mcr sysman IO AUTOCONFIGURE
show device gk/full
- NetWorker: Dessa kommandon tillhandahålls som referens och fungerar i allmänhet på en högre nivå än operativsystemkommandona ovan. De kan vara användbara för att försöka diagnostisera ett problem på lägre nivå genom att ge ytterligare information eller fel som ledtrådar till det aktuella problemet, men de förväntas inte lyckas om åtgärder på lägre nivå misslyckas.
inquire -lc
lusbinfo -v
changers
dvdetect -dlV -D9
lusbinfo och changers kanske inte finns på alla plattformar. Om du vill kan du öka felsökningsnivåerna genom att ange miljövariabeln LUS_DEBUG:
UNIX:
export LUS_DEBUG=9
Windows:
set LUS_DEBUG=9
AIX:
lusdebug ffff
Prova också:
SJI_DEBUG=9, SCSI_DEBUG=9, JBDEBUG=9
Ytterligare information
Se till att du förstår att robottekniska problem som visar sig ligga utanför NetWorkers omfattning som en applikation (läs: kan inte upptäckas med standardmetoder för operativsystem) inte ligger inom ramen för NetWorker-supporten.
Mer information finns i: NetWorker: Felsöka problem med bandbibliotek i NetWorker
Support kan ge vägledning med hjälp av kriterierna ovan, men vi har inga OS-, HBA- eller robotteknikleverantörsresurser. Den här begränsningen kan leda till långvarig, misslyckad felsökning.