NetWorker: "NDMP 서비스 오류: 형식을 식별할 수 없습니다."

증상은 두 가지 주요 문제와 관련이 있습니다.

1. 백업 관리자가 지속적으로 반복되는 NMDP 헤더 I/O 오류에 주의를 기울이지 않고 있는 경우 이 NetWorker 경고는 VNX 오류를 수반하므로 심각하게 처리해야 합니다.
2. 두 제품(NetWorker 및 VNX)은 NMDP 헤더 손상을 사소한 오류로 간주합니다. 백업이 재시작되는 특수한 경우 손상을 데이터 읽기를 시도할 때 자동으로 해결할 수 없는 지점에 도달합니다

복구에 필요한 파일이 여러 백업(전체 + 차등 + 증분)에 걸쳐 있고 여러 볼륨에 걸쳐 있습니다.

NDMP 세이브 세트 복구 및 File by File(탐색 가능) 복구가 실패하고 다음과 밀접하게 관련된 오류

탐색 가능 복구 실패 로그:

42744:nsrndmp_recover: Tape server paused: reached the end of file
42897:nsrndmp_recover: Opened the tape device : c208t0l0
42870:nsrndmp_recover: Continuing recover from the next volume
42619:nsrndmp_recover: NDMP Service Error: Cannot identify format.  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
42617:nsrndmp_recover: NDMP Service Log: server_archive: emctar vol 1, 0 files, 61440 bytes read, 0 bytes written
42738:nsrndmp_recover: Data server halted: Error during the restore.
42856:nsrndmp_recover: NDMP data server has an internal error.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
16279:winworkr: NDMP retrieval: child failed with status of 1
42897:nsrndmp_recover: Opened the tape device : c208t0l5
Mover listen address is NULL(NDMP_ADDR_LOCAL)

세이브 세트 복구 실패는 전체 백업에서만 발생하며 다른 수준의 백업은 세이브 세트 복구를 사용하여 복구할 수 있습니다.

root@NW-server# nsrndmp_recover -s NW-server -c NAS-host -S 1011119015 -v off -m "NAS-host::/root_vdm_1/users/recover_emc" "/root_vdm_1/users/VDI_Users/v009/project/Plan04.2012"
42879:nsrndmp_recover: Peforming recover with no file mark dependency..
05/31/16 17:25:50.504040 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
42787:nsrndmp_recover: Performing recover from NDMP type of device
05/31/16 17:26:01.269862 NDMP Service Debug: The process id for NDMP service is 0xc4bd90b0
May 31 17:26:02 NW-server root: [ID 702911 local0.alert] NetWorker media: (waiting) waiting for LTO Ultrium-5 tape VN0116L5 on NAS-host
95555:nsrmmd: ndmp tape mtio failed, I/O error
42850:nsrndmp_recover: Failed to load volume 1111782299 fnum 3 <<<<<< cannot load File Number 3
42855:nsrndmp_recover: Failed to load the tape.
42871:nsrndmp_recover: Error during File NDMP Extraction.
42840:nsrndmp_recover: NDMP recover failed.
42880:nsrndmp_recover: Error during NDMP recover
root@NW-server #

가장 중요한 증상은 스캐너가 필요한 백업 볼륨을 통과 할 수 없으며 데이터를 읽기 전에 조기에 중지된다는 것입니다!

root@NW-server # scanner -vvv -p "rd=NAS-host:c208t0l5 (NDMP)"
8909:scanner: using 'rd=NAS-host:c208t0l5 (NDMP)' as the device name
05/31/16 17:29:08.919423 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8968:scanner: Reading the label...
8969:scanner: Reading the label done
8936:scanner: scanning LTO Ultrium-5 tape VN0116L5 on rd=NAS-host:c208t0l5 (NDMP)
96367:scanner: volume id 1111782299 record size 262144 bytes
created 5/24/16 21:00:35 expires 5/24/18 21:00:35
8973:scanner: setting position from fn 0, rn 0 to fn 2, rn 0
05/31/16 17:29:09.073276 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
05/31/16 17:29:09.201476 NDMP Service Debug: The process id for NDMP service is 0xda018d60
9040:scanner: Opened c208t0l5 for read
8761:scanner: done with LTO Ultrium-5 tape VN0116L5 <<<<<<<< No Errors , no mention of any file after File number 2 !!

NW 디버그 플래그 파일의 사용: /nsr/debu/ndmp_auto_pos 전체 백업 세이브 세트 또는 탐색 가능 복구에 도움이 되지 않았습니다.

경우에 따라 잘못된 파일 번호를 생성하는 NDMP 헤더 손상으로 인해 NDMP 볼륨 형식이 잘못됨(예: 자동 백업 재시작):  

NW 로그를 검사하면 NDMP 헤더를 쓸 때 모든 백업이 I/O 오류와 결합되어 있음을 알 수 있습니다. 이는 모든 백업에서 발생하는 일관된 문제이며 지속적인 손상의 원인입니다.

70896 05/01/16 12:18:05 0 0 2 1 23177 0 NW-server nsrd NSR info NAS-host:/root_vdm_1/userdata saving to pool 'NDMPPool' (VN0050L5)
42597 05/01/16 12:18:05 2 0 0 1 23990 0 NW-server nsrmmd NSR warning ndmp header: I/O error   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
71193 05/01/16 12:18:05 0 0 0 1 23177 0 NW-server nsrd NSR info NDMP Save Notice: NAS-host:/root_vdm_1/users NDMP save running on 'NW-server'

NAS 로그를 검사하면 NDMP 디바이스의 버퍼 크기가 NW에 구성된 디바이스 블록 크기보다 작은 값으로 설정되어 있음을 알 수 있습니다. 기본 NetWorker 구성은 LTO-5 디바이스의 디바이스 블록 크기를 256K로 설정하지만 NDMP 디바이스 버퍼 크기(NDMP.bufsz)는 128K입니다. NAS에서 PAX 구성 매개변수(기본값 60k)에 의해 데이터 블록 크기가 구성되므로 이 부분은 NDMP 헤더와만 관련이 있습니다.

2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:37: NDMP: 3: Thread ndmp533 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:49: NDMP: 3: Thread ndmp535 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 DartTapeInterface: tape read error: tape read block size (262144 bytes) > 131072 bytes (NDMP.bufsz (128 KB) x 1024)
2016-05-25 17:30:50: NDMP: 3: Thread ndmp536 set parameter NDMP.bufsz (in KB) to 256 or larger to resolve this error

VNX 로그에 백업 시 관련 메시지가 표시됩니다.

1466097048: NDMP: 3: Session 236 (thread ndmp236) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072) Set NDMP.bufsz >= 262144 and reboot

데이터 스트림이 시작되지 않았기 때문에 백업 문제로 간주되지 않지만 NMDP 헤더가 손상될 수 있습니다( 참조: NDMP: 3: 세션 384(스레드 ndmp384) TAPE_WRITE, 크기(262144) > ndmpMaxBufSize (131072)NDMP.bufsz >= 262144 및 재부팅으로 설정)을 수행하며, NDMP 디바이스의 버퍼 크기를 256k로 설정하여 이 문제를 해결합니다. 그러나 이렇게 수정해도 이미 작성된 백업 문제는 해결되지 않습니다.

복구 문제를 일으키지 않고도 위의 NMDP 헤더 손상이 존재할 수 있지만, 백업을 재시작할 경우 NW 미디어 데이터베이스에 등록된 파일 번호가 잘못되었습니다. 이 경우 테이프의 자동 포지셔닝이 무효화되고 따라서 NAS는 해당 위치의 기존 데이터를 유효한 NDMP 데이터 스트림으로 인식할 수 없다고 응답합니다(NDMP 서비스 오류: 형식을 식별할 수 없음)

여기에는 두 가지 유형의 손상이 있습니다.

1. NetWorker와 VNX 간의 블록 크기 설정이 일치하지 않아 NDMP 헤더 IO 오류가 발생합니다. 이러한 유형의 손상은 자동 포지셔닝 기능으로 우회되며 아무도 모르게 수년간 존재할 수 있습니다. 각 세이브 세트에 올바른 파일 번호가 등록되어 있으면 가능합니다.
2. 백업이 재시작되면 여러 NDMP 머리글 및 바닥글이 순차적으로 작성되고 NW 서버는 다음 백업이 시작되는 올바른 파일 번호를 누락하여 NDMP 비활성화된 자동 위치 지정 디버그(/nsr/debug/ndmp_auto_pos여기서는 MTIO(Tape Management Interface)가 이중 파일 표시(C1, NDMP 헤더 손상으로 인해)가 발견되면 읽기를 중지하므로 )는 쓸모가 없습니다