NetWorker: La recuperación falla con el mensaje "NDMP Service Error: No se puede identificar el formato"

Los síntomas están relacionados con dos problemas principales:

1. El administrador de respaldo no presta buena atención a los errores de I/O de encabezado de NMDP que se repiten constantemente. Esta advertencia de NetWorker conlleva un error de VNX y se debe tratar con seriedad
2. Los dos productos (NetWorker y VNX) consideran que el daño en el encabezado NMDP es un error trivial. En el caso especial de reinicios de respaldo, los daños llegan a un punto que no se puede resolver automáticamente cuando se intenta leer los datos

Los archivos necesarios para la recuperación abarcan varios respaldos (completos + diferenciales + incrementales) y abarcan varios volúmenes.

La recuperación de savesets de tipo NDMP y la recuperación archivo por archivo (navegable) fallan con errores

estrechamente relacionados Registro de fallas de recuperación navegable:

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)

La falla de recuperación del saveset ocurre solo con el respaldo completo; los respaldos de otros niveles se pueden recuperar mediante la recuperación del saveset.

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 #

El síntoma más importante es que el escáner no puede pasar por los volúmenes de respaldo requeridos, se detiene prematuramente antes de leer los datos.

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 !!

El uso del archivo de marca de depuración NW: /nsr/debu/ndmp_auto_pos no ayudó con el saveset de respaldo completo ni con la recuperación navegable.

Formato incorrecto del volumen NDMP causado por daños en el encabezado de NDMP que generan números de archivo erróneos a veces (como el reinicio automatizado de respaldos):  

La inspección de los registros de NW muestra que cada respaldo se combina con un error de I/O cuando se escribe el encabezado NDMP. Este es un problema constante que ocurre con cada respaldo; esto es un indicador de un daño consistente.

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'

La inspección de los registros NAS muestra que el tamaño del buffer de los dispositivos NDMP está configurado en un valor menor que el tamaño de bloque de dispositivos configurado en NW. La configuración predeterminada de NetWorker establece el tamaño de bloque de dispositivos para los dispositivos LTO-5 en 256 K, pero el tamaño del buffer del dispositivo NDMP (NDMP.bufsz) es de 128 K. Esta parte se relaciona solo con el encabezado NDMP, ya que el tamaño del bloque de datos está configurado en el NAS mediante los parámetros de configuración de PAX (valor predeterminado: 60k).

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

El registro de VNX muestra un mensaje relacionado en el tiempo de ejecución del respaldo:

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

Esto no se considera un problema de respaldo porque el flujo de datos no se inició, pero causa daños en el encabezado NMDP (consulte: NDMP: 3: Sesión 384 (subproceso ndmp384) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072)Set NDMP.bufsz >= 262144 y reboot), que resuelve este problema mediante la configuración del tamaño del buffer de los dispositivos NDMP en 256 k. Sin embargo, esta corrección no resuelve el problema de los respaldos que ya se han escrito.

Es posible que existan daños en el encabezado NMDP sin causar el problema de recuperación, pero en casos de un reinicio del respaldo, el número de archivo registrado es incorrecto en la base de datos de medios de NW. Esto anula el posicionamiento automático de la cinta y, por lo tanto, el NAS responde que los datos existentes en esa posición no se pueden reconocer como un flujo de datos NDMP válido (error de servicio de NDMP: No se puede identificar el formato)

Así que aquí hay dos tipos de daños:

1. Errores de I/O de encabezado NDMP causados por la configuración de tamaño de bloque incoherente entre NetWorker y VNX. La característica de posicionamiento automático omite este tipo de daño y puede existir durante años sin que nadie lo note. Siempre y cuando se registren los números de archivo correctos con cada saveset.
2. Cuando se reinicia un respaldo, se escriben varios encabezados y pies de página de NDMP de forma secuencial, y el servidor NW perderá el número de archivo correcto donde se inicia el siguiente respaldo, lo que anula el posicionamiento automático del uso de la depuración de posicionamiento automático deshabilitada de NDMP (/nsr/debug/ndmp_auto_pos) es inútil en este caso porque la interfaz de administración de cintas (MTIO) dejará de leer una vez que encuentre una marca de archivo doble (causada por C1, el daño del encabezado NDMP)