Felsöka problem med åtkomst till bandbibliotek i NetWorker

• Det gick inte att komma åt den upptäckta bandbiblioteksinstallationen på NetWorker-lagringsnoden eller -servern
• Det gick inte att säkerhetskopiera data på grund av oanvändbar maskinvara för säkerhetskopiering
• Fel vid åtkomst till roboten:
  • 0x29
  • Device busy
  • The requested resource is busy
  • Str=<There is an input or output error.>
  • No such device
  • No such file or directory
  • Inappropriate ioctl for device

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-kompatibilitetsmanualen för maskinvara(inloggning till Dell-supportkonto krävs). Kom ihåg att det är möjligt för ett bibliotek att vara delvis funktionellt; Enbart identifiering garanterar inte användbarhet eller support.

Om du vill felsöka fel med biblioteksåtkomst kan du läsa de senaste ändringarna. Använd sedan grundläggande och jämförande tester från tredje part för att bekräfta om någon värd eller process kan utlösa ett svar från roboten.

Ibland är det önskvärt att testa specifika funktioner, baserat på tillgängliga bevis. Om värd A kan fråga roboten men inte värd B kan det, svarar roboten. Värd A:s förare kan låsa roboten. Om värd B fortfarande får fel efter att alla värdar har tagits bort från zonindelningen kan värd B ha ett drivrutins-, konfigurations- eller programvaruproblem.

Om värden fick åtkomst till roboten före problemet är det mest troligt att recensionsobjekten har ändrats. Undersök fel eller kända konfigurationsändringar efter händelsen.

När biblioteket har identifierats använder du följande kommandon för att testa grundläggande SCSI-åtgärder via lagringstransporten, inte Ethernet eller webbgränssnittet. Se alltid till att korrigeringsfilerna för operativsystemet är uppdaterade, särskilt när det gäller lagring.

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)

Tillgång till biblioteket: Operativsystem:

• Windows: Det finns inget inbyggt sätt att fråga ett bandbibliotek i Windows. mtx är ett gratisprogram som kan testas om så önskas. Den använder växlarenhetens handtag i stället för SCSI-adressen när kommandon utfärdas (vilket kan ha testkonsekvenser).

• Linux: Precis som Windows har inget inbyggt kommando att fråga, men har också en mtx port, som kräver enhetsdrivrutinens referens (återigen, skiljer sig från hur NetWorker kommer åt den).

• Solaris: Solaris innehåller sgen Drivrutin för inbyggt stöd för bandbibliotek, men nej mtx port eller andra inbyggda bibliotekskommandon finns för den. Se avsnittet om NetWorker-kommandon för att testa biblioteksåtkomst i stället (nedan).
   
• AIX: AIX har inget inbyggt stöd för bandbibliotek (lus används i stället), och ingen mtx finns för den. Se avsnittet om NetWorker-kommandon för att testa biblioteksåtkomst i stället (nedan).

• HP-UX: mc är det inbyggda HP-UX-kommandot för manipulering av mediumväxlare:

• NetWorker: Dessa kommandon fungerar på en relativt atomär nivå, och även om de skrivs, kompileras och testas av NetWorker-supporten kräver de inte en NetWorker-instans som körs för att fungera, och inte heller någon av NetWorkers konfigurationer. I allmänhet anses de vara tillförlitliga, lågnivå, mjukvaruoberoende testverktyg. Om du vill öka felsökningen för de flesta verktyg kan du lägga till följande miljövariabler:

SJI_DEBUG=9
LUS_DEBUG=9 (lusdebug ffff on AIX)
CDI_DEBUG=9
SCSI_DEBUG=9
JBDEBUG=9

I nedanstående, '<changer address>' varierar beroende på operativsystem:

Windows: Initiator.Target.LUN (som avslöjats av inquire kommando) eller \\.\changer# drivrutinshandtag
Linux: Intiator.Target.LUN (som avslöjats av inquire kommando) eller /dev/sg# drivrutinshandtag
Solaris: /dev/scsi/changer/c#t#d# förarhandtag
AIX: Initiator.Target.LUN (som avslöjats av inquire kommando)
HP-UX: Initiator.Target.LUN (som avslöjats av inquire kommando) eller /dev/rac/c#t#d# Handtag för drivrutin

Tillgång till biblioteket: Återställa biblioteket:

Transport – konfiguration

• För SAN: Se till att både roboten och den avsedda NetWorker-robotkontrollvärden är korrekt inloggade i switchen och granska zonindelningen för roboten för att säkerställa att fullständig anslutning är möjlig.
• Robotar är inte avsedda att nås eller styras av mer än en värd; Om det inte finns ett behov (t.ex. en partitionerad robot) ska du se till att endast den avsedda NetWorker-robotstyrenhetsvärden är zonindelad för att se roboten.
• Det är möjligt att testa SAS-expandrar för att säkerställa att robotanslutning upprättas. Ren punkt-till-punkt-teknik som SCSI kräver att man testar anslutningen från den relevanta värden.

Transport – maskinvara

• Om problem upptäcks på antingen värd- eller transportmaskinvarunivå bör du överväga att testa switchen eller expanderaren eller byta ut kablarna mot "kända bra" exempel för att utesluta kabeldragningsproblem.
• Granska firmware för transporthårdvaran och firmware för själva roboten för valuta.
• För SCSI, se till att termineringarna är korrekt placerade och sitter tätt, att kabellängdsgränserna följs och att rätt volymtages används.

Värdtransport – konfiguration

• Kontrollera att den berörda värden har uppdaterade drivrutiner och fast programvara för sina transportdrivrutiner – användning EMCReports (medföljer nsrget -o:e).
• Se till att alla HBA-drivrutinskonfigurationer (Host Bus Adapter) som krävs görs på rätt sätt för operativsystemet.

Värdprogramvara – resurslåsning

• För alla värdar som är zonindelade för att se roboten (helst - endast den utsedda NetWorker-värden), kontrollera om det finns någon programvara som kan försöka komma åt roboten, till exempel annan säkerhetskopieringsprogramvara, övervakningsprogramvara eller fristående verktyg som kan försöka komma åt roboten.
• För Solaris 10 är roboten inte tillgänglig när nsrlcpd NetWorker-processen är ansluten. Det kan därför verka otillgängligt (eller till och med oupptäckbart) tills biblioteket i NetWorker avaktiveras (tvingar nsrlcpd att lossna och dö).
• Om någon icke-NetWorker-process misstänks låsa eller komma åt roboten eller någon annan enhet – se Felsöka överskrivna etiketter och SCSI-återställningar i NetWorker för mer information om felsökning och identifiering.

Om operativsystemet identifierar biblioteket men biblioteket inte svarar på kommandon fungerar det till viss del. Den kan vara låst av en annan process eller värd, påverkas av transportproblem eller ha ett fel på komponentnivå.

Om ingen process eller värd kan fastställas ha åtkomst till roboten förutom NetWorker-lagringsnoden som är avsedd att styra den, se Felsöka hårdvaruproblem med bandbibliotek i NetWorker för att avgöra om det finns ett problem med själva roboten.

Se till att du förstår att robotproblem som visar sig ligga utanför NetWorkers omfattning som en applikation (läs: kan inte nås med standardmetoder för operativsystem) inte ligger inom ramen för NetWorker-supporten.
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.