NetWorker의 테이프 라이브러리 액세스 문제 해결

요약: 이 문서는 지원 팀 및 NetWorker 관리자가 탐지된 로봇이 명령을 수락할 수 없는 원인을 파악하는 데 도움을 주기 위해 작성되었습니다.

이 문서는 다음에 적용됩니다. 이 문서는 다음에 적용되지 않습니다. 이 문서는 특정 제품과 관련이 없습니다. 모든 제품 버전이 이 문서에 나와 있는 것은 아닙니다.
기타 리소스 확인

증상

 

  • NetWorker Storage Node 또는 Server에서 감지된 테이프 라이브러리 설치에 액세스할 수 없음
  • 사용할 수 없는 백업 하드웨어로 인해 데이터를 백업할 수 없음
  • 로봇에 접근하는 동안 오류가 발생했습니다.
    • 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

원인

라이브러리가 이전에 작동하다가 갑자기 작동하지 않는 경우 마지막으로 알려진 변경 사항을 가능한 원인으로 간주합니다.

  • 디바이스 재부팅, 재검색 및 이름 변경 후 라이브러리 주소에서 처리되지 않은 변경
  • 전원 서지, 정전 또는 기타 환경 이벤트로 인한 손상 가능성
  • 전송 하드웨어의 장애 이벤트 또는 재구성
  • 운송 또는 로봇과 관련된 소프트웨어 또는 드라이버의 설치, 변경 또는 삭제

라이브러리가 작동하지 않는 경우 NetWorker 하드웨어 호환성 가이드에서 하드웨어가 지원되는지 확인합니다(Dell 지원 계정 로그인 필요). 라이브러리가 부분적으로 기능할 수 있음을 기억하십시오. 검색만으로는 유용성이나 지원이 보장되지 않습니다.

해결

라이브러리 액세스 실패 문제를 해결하려면 최근 변경 사항을 검토하십시오. 그런 다음 기본 및 타사 비교 테스트를 사용하여 호스트 또는 프로세스가 로봇의 응답을 트리거할 수 있는지 확인합니다.

때로는 사용 가능한 증거를 기반으로 특정 기능을 테스트하는 것이 바람직합니다. 호스트 A는 로봇을 쿼리할 수 있지만 호스트 B는 쿼리할 수 없는 경우 로봇은 응답합니다. 호스트 A의 드라이버가 로봇을 잠그고 있을 수 있습니다. 모든 호스트의 영역을 해제한 후에도 호스트 B에 오류가 계속 발생하는 경우 호스트 B에 드라이버, 구성 또는 소프트웨어 문제가 있을 수 있습니다.

문제가 발생하기 전에 호스트가 로봇에 액세스한 경우 검토 항목이 변경되었을 가능성이 큽니다. 이벤트 후 오류 또는 알려진 구성 변경 사항을 조사합니다.

라이브러리가 감지되면 다음 명령을 사용하여 이더넷 또는 웹 UI가 아닌 스토리지 전송을 통해 기본 SCSI 작업을 테스트합니다. 특히 스토리지와 관련하여 운영 체제 패치가 항상 최신 상태인지 확인합니다.

참고: 위의 내용을 포함한 포괄적인 초기 데이터 세트를 수집하는 가장 쉬운 방법은 nsrget -o:d 영향을 받는 서버 및 노드에서.
주의: 하지 말아야 할 일 -o:d 테이프를 쓰는 데 사용 중인 테이프가 있는 모든 호스트에서 NMC(NetWorker Management Console)의 모니터링 -> 디바이스에서 이를 확인할 수 있습니다. 

다음 문서에서는 NSRGET을 가져오고 사용하는 방법에 대한 정보를 제공합니다. NetWorker: NSRGet NetWorker 데이터 수집 툴을 사용하는 방법


도서관 이용: 운영 체제:

  • Windows: Windows에서 테이프 라이브러리를 쿼리하는 기본 방법은 없습니다. mtx 원하는 경우 테스트할 수 있는 프리웨어 유틸리티입니다. 명령을 실행할 때 SCSI 주소 대신 체인저 디바이스 핸들을 사용합니다(테스트에 영향을 미칠 수 있음).
loaderinfo -f \\.\changer#
mtx -f \\.\changer# inquiry
 
  • Linux: Windows와 마찬가지로 쿼리할 기본 명령이 없지만 mtx 포트 - 디바이스 드라이버 핸들이 필요합니다(NetWorker에서 액세스하는 방법과 다름).
loaderinfo -f /dev/sg#
mtx -f /dev/sg# inquiry
 
  • Solaris: Solaris에는 sgen 기본 테이프 라이브러리를 위한 드라이버는 지원되지만 지원되지 않음 mtx 포트 또는 다른 기본 라이브러리 명령이 없습니다. 대신 라이브러리 액세스를 테스트하기 위한 NetWorker 명령 섹션을 참조하십시오(아래).
     
  • AIX: AIX에는 기본 테이프 라이브러리 지원(lus 대신 사용됨), 아니요 mtx 포트가 있습니다. 대신 라이브러리 액세스를 테스트하기 위한 NetWorker 명령 섹션을 참조하십시오(아래).
  • HP-UX: mc 는 미디어 체인저 조작을 위한 기본 HP-UX 명령입니다.
mc -p $(ioscan  FnkC autoch | grep /dev/rac) -r MIDS -q
 
  • NetWorker: 이러한 명령은 비교적 원자적인 수준에서 작동하며 NetWorker 지원 부서에서 작성, 컴파일 및 테스트되지만 실행 중인 NetWorker 인스턴스나 NetWorker 구성이 없어도 작동합니다. 일반적으로 신뢰할 수 있고 낮은 수준의 소프트웨어 독립적인 테스트 유틸리티로 간주됩니다. 대부분의 유틸리티에 대한 디버그를 늘리려면 다음 환경 변수를 추가할 수 있습니다.

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

아래에서, '<changer address>'운영 체제에 따라 다릅니다.

Windows: Initiator.Target.LUN ( inquire 명령) 또는 \\.\changer# 드라이버 핸들
Linux: Intiator.Target.LUN ( inquire 명령) 또는 /dev/sg# 드라이버 핸들
Solaris: /dev/scsi/changer/c#t#d# 드라이버 핸들
AIX: Initiator.Target.LUN ( inquire 명령)
HP-UX: Initiator.Target.LUN ( inquire 명령) 또는 /dev/rac/c#t#d# 드라이버 핸들

sjirjc <changer address>
드라이브 수, 지원되는 기능 등과 같은 데이터를 로봇에 요청합니다.

sjisn <changer address>
로봇에 드라이브 요소 및 일련 번호 정보를 요청합니다.

sjirdtag <changer address>
테이프 카트리지에서 요소 위치 데이터를 요청합니다.

cdi_inq -f <changer driver handle> -v
중요한 제품 데이터 요청(드라이버 핸들을 사용해야 함)
 
ielem -a <changer address>
요소를 다시 초기화하려고 하면 작업이 중단될 수 있습니다.
 

도서관 이용: 라이브러리 재설정:

라이브러리는 부팅 주기 문제를 발생시키는 일시적인 문제에 직면할 수 있습니다. 내부 문제를 완화하기 위해 몇 가지 조치를 취할 수 있습니다.

nsrjb -HEvvvvv
문제가 있는 라이브러리에 reset 명령을 실행하고 요소를 강제로 다시 초기화합니다.

nsrjb -IIvvvvv
라이브러리에서 보고한 바코드와 미디어 데이터베이스의 해당 값을 기반으로 NetWorker nsr 주크박스 객체를 강제로 업데이트하고 새로 고칩니다.

nsrjb -HH
주크박스가 모든 볼륨을 언로드하고 소프트 리셋을 시도하도록 강제합니다.
 
참고: 위의 명령은 워크플로의 이후 단계, 특히 라이브러리 단위가 명령을 수락할 '준비'가 된 후에만 작동합니다. 따라서 이 섹션에서는 라이브러리가 '준비' 상태인 경우 '액세스' 문제를 잠재적으로 해결하는 방법에 대한 단계만 제공합니다. ielem -a 는 대략적으로 다음과 같습니다. nsrjb -E NetWorker에서 작동하는 nsr 주크박스 가 필요하지 않습니다.
 

전송 - 구성

  • SAN의 경우: 로봇과 원하는 NetWorker 로봇 제어 호스트가 스위치에 올바르게 로그인되어 있는지 확인하고 로봇의 영역 지정을 검토하여 포괄적인 연결이 가능한지 확인합니다.
  • 로봇은 둘 이상의 호스트가 액세스하거나 제어하도록 설계되지 않았습니다. 필요하지 않은 경우(예: 파티셔닝된 로봇) 원하는 NetWorker 로봇 컨트롤러 호스트만 로봇을 볼 수 있도록 조닝해야 합니다.
  • SAS 익스팬더를 테스트하여 로봇 연결이 설정되었는지 확인할 수 있습니다. SCSI와 같은 순수 지점 간 기술을 사용하려면 관련 호스트에서 연결을 테스트해야 합니다.

운송 - 하드웨어

  • 호스트 또는 전송 하드웨어 레벨에서 문제가 감지되면 스위치 또는 확장기를 테스트하거나 케이블을 '정상 작동이 확인된' 예로 교체하여 케이블 연결 문제를 배제하는 것이 좋습니다.
  • 운송 하드웨어의 펌웨어와 통화에 대한 로봇 자체의 펌웨어를 검토하십시오.
  • SCSI의 경우 터미네이터가 올바르게 배치되고 꼭 맞게 장착되었는지, 케이블 길이 제한이 준수되었는지, 적절한 전압이 사용되고 있는지 확인합니다.

호스트 전송 - 구성

  • 관련 호스트에 전송 드라이버에 대한 최신 드라이버 및 펌웨어가 있는지 확인합니다. EMCReports (함께 번들로 제공됩니다. nsrget -o:e)를 제공해야 합니다.
  • 필요한 HBA(Host Bus Adapter) 드라이버 구성이 운영 체제에 맞게 구성되었는지 확인합니다.

호스트 소프트웨어 - 리소스 잠금

  • 로봇을 볼 수 있는 영역이 지정된 호스트(지정된 NetWorker 호스트만)의 경우 로봇에 액세스를 시도할 수 있는 다른 백업 소프트웨어, 모니터링 소프트웨어 또는 독립 실행형 유틸리티와 같이 로봇에 액세스하려고 시도할 수 있는 모든 소프트웨어가 있는지 확인합니다.
  • Solaris 10의 경우 nsrlcpd NetWorker 프로세스가 연결되어 있으면 로봇에 액세스할 수 없습니다. 따라서 NetWorker의 라이브러리가 비활성화될 때까지(또는 감지할 수 없는 경우) 액세스할 수 없는(또는 감지할 수 없는 것처럼 보일 수 있음) nsrlcpd 분리되어 죽다).
  • NetWorker가 아닌 프로세스가 로봇 또는 드라이브를 잠그거나 액세스하는 것으로 의심되는 경우 문제 해결 및 식별에 대한 자세한 내용은 NetWorker에서 덮어쓴 레이블 및 SCSI 재설정 문제 해결을 참조하십시오.

운영 체제에서 라이브러리를 감지했지만 라이브러리가 명령에 응답하지 않는 경우 운영 체제는 어느 정도 작동합니다. 다른 프로세스 또는 호스트에 의해 잠겨 있거나, 전송 문제의 영향을 받거나, 구성 요소 수준의 오작동이 발생할 수 있습니다.

로봇을 제어하려는 NetWorker Storage Node 외에 로봇에 액세스하는 프로세스 또는 호스트를 확인할 수 없는 경우에는 NetWorker의 테이프 라이브러리 하드웨어 문제 해결 을 참조하여 로봇 자체에 문제가 있는지 확인합니다.

추가 정보

NetWorker의 애플리케이션 범위를 벗어난 것으로 표시된 로보틱스 문제(읽기: 표준 운영 체제 방법을 사용하여 액세스할 수 없음)는 NetWorker 지원 범위에 포함되지 않는다는 점을 이해해야 합니다.
Networker: NetWorker

의 테이프 라이브러리 문제 해결지원 부서는 위의 기준을 사용하여 지침을 제공할 수 있지만 OS, HBA 또는 로봇 공급업체 리소스가 없습니다. 이러한 제한으로 인해 문제 해결이 장시간 실패할 수 있습니다.

해당 제품

NetWorker
문서 속성
문서 번호: 000116098
문서 유형: Solution
마지막 수정 시간: 23 1월 2026
버전:  4
다른 Dell 사용자에게 질문에 대한 답변 찾기
지원 서비스
디바이스에 지원 서비스가 적용되는지 확인하십시오.