NetWorker : La restauration échoue avec le message « NDMP Service Error : Impossible d’identifier le format »

Les symptômes sont liés à deux problèmes principaux :

1. L’administrateur de sauvegarde n’est pas suffisamment attentif aux erreurs d’E/S d’en-tête NMDP récurrentes. Cet avertissement NetWorker est porteur d’une erreur VNX et doit être traité sérieusement
2. Les deux produits (NetWorker et VNX) considèrent la corruption de l’en-tête NMDP comme une erreur anodine. Dans le cas particulier du redémarrage de la sauvegarde, la corruption atteint un point qui ne peut pas être résolu automatiquement lors de la tentative de lecture des données

Les fichiers requis pour la restauration couvrent plusieurs sauvegardes (complète + différentielle + incrémentielle) et plusieurs volumes.

La restauration du saveset NDMP et la restauration fichier par fichier (consultable) échouent avec des erreurs

étroitement liées Browsable recovery failure log :

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)

L’échec de la restauration du saveset se produit uniquement avec la sauvegarde complète. Les sauvegardes d’autres niveaux peuvent être restaurées à l’aide de la restauration des savesets.

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 #

Le symptôme le plus important est que le scanner n’est pas en mesure de parcourir les volumes de sauvegarde requis, il s’arrête prématurément avant de lire les données !

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

Utilisation du fichier de balise de débogage NW : /nsr/debu/ndmp_auto_pos n’a pas aidé avec le saveset de sauvegarde complète ou la restauration consultable.

Un format de volume NDMP mal formé en raison d’une corruption de l’en-tête NDMP générant parfois des numéros de fichier erronés (comme le redémarrage automatisé de la sauvegarde) :  

L’inspection des logs NW montre que chaque sauvegarde est associée à une erreur d’E/S lors de l’écriture de l’en-tête NDMP. Il s’agit d’un problème récurrent qui se produit à chaque sauvegarde. C’est un pointeur vers une corruption constante.

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'

L’examen des journaux NAS montre que la taille de la mémoire tampon des périphériques NDMP est définie sur une valeur inférieure à la taille de bloc du périphérique configurée dans NW. La configuration NetWorker par défaut définit la taille de bloc de périphérique pour les périphériques LTO-5 sur 256 K, mais la taille de la mémoire tampon du périphérique NDMP (NDMP.bufsz) est de 128 K. Cette partie est liée uniquement à l’en-tête NDMP, car la taille des blocs de données est configurée sur le NAS par les paramètres de configuration PAX (60k par défaut).

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

Le journal VNX affiche un message connexe au moment de la sauvegarde :

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

Ce problème n’est pas considéré comme un problème de sauvegarde, car le flux de données n’a pas démarré, mais il endommage l’en-tête NMDP (voir : NDMP: 3: Session 384 (thread ndmp384) TAPE_WRITE, size(262144) > ndmpMaxBufSize (131072)Set NDMP.bufsz >= 262144 et reboot), qui résout ce problème en définissant la taille de la mémoire tampon des périphériques NDMP sur 256k. Cependant, cette correction ne résout pas le problème des sauvegardes qui ont déjà été écrites.

La corruption de l’en-tête NMDP ci-dessus peut exister sans causer le problème de restauration, mais en cas de redémarrage de la sauvegarde, le numéro de fichier enregistré est erroné dans la base de données des supports NW. Ce qui annule le positionnement automatique de la bande et, par conséquent, le NAS répond que les données existantes à cette position ne peuvent pas être reconnues comme flux de données NDMP valides (Erreur de service NDMP : Impossible d’identifier le format)

Il existe donc ici deux types de corruption :

1. Erreurs d’E/S de l’en-tête NDMP causées par le paramètre de taille de bloc incohérent entre NetWorker et VNX. Ce type de corruption est contourné par la fonction de positionnement automatique, et il peut exister pendant des années sans que personne ne s’en aperçoive. Tant que les bons numéros de fichier sont enregistrés avec chaque saveset.
2. Lorsqu’une sauvegarde est redémarrée, plusieurs en-têtes et pieds de page NDMP sont écrits de manière séquentielle, et le serveur NW n’a pas le bon numéro de fichier à l’endroit où la sauvegarde suivante démarre, ce qui annule le positionnement automatique de l’utilisation du débogage de positionnement automatique désactivé par NDMP (/nsr/debug/ndmp_auto_pos) est inutile dans ce cas car l’interface de gestion des bandes (MTIO) arrête la lecture une fois qu’elle rencontre une double marque de fichier (causée par C1 la corruption de l’en-tête NDMP)