Le problème était le suivant : sur une infra NetBackup classique, NetBackup en 7.5.0.6, sauvegarde sur bande, j'avais des sauvegardes VMware configurées quelques mois plus tôt et qui se déroulaient très bien. Mais depuis quelques temps, certaines VMs n'étaient plus sauvegardées, toute tombaient en code 156.
Pour rappel, le code 156 est une erreur de snapshot, indispensable à toute sauvegarde de VM. J'ai commencé, comme toujours dans ce cas, à valider la possibilité le faire des snapshots coté VMware, tout était ok.
D'ailleurs, je me suis aperçu que même les demandes de snapshots par NetBackup échouaient avant même de provoquer la prise d'image coté vCenter.
Dans les logs NetBackup bpfis sur le media serveur, des erreurs basiques et pas trop parlantes, comme dans le job de sauvegarde lui même :
J'ai cherché pas mal sans trouver trop de piste, puis en analysant coté vCenter les VMs impactées, je me suis rendu compte que 80% d'entre elles avaient des caractères accentués dans le display name. Ca se réchauffait.10 févr. 2014 21:00:00 - Info nbjm (pid=2577) starting backup job (jobid=100723) for client <Client>, policy VMware_Prod, schedule Incr10 févr. 2014 21:00:00 - Info nbjm (pid=2577) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=100723, request id:{EC849602-928D-11E3-84A2-0E6ECE4CEAEC})10 févr. 2014 21:00:00 - requesting resource LB_Montpeliier_EML10 févr. 2014 21:00:00 - requesting resource backup.NBU_CLIENT.MAXJOBS.<Client>10 févr. 2014 21:00:00 - requesting resource backup.NBU_POLICY.MAXJOBS.VMware_Prod10 févr. 2014 21:00:14 - awaiting resource <STU Group>. Waiting for resources.Reason: Drives are in use, Media server: <Media Server>,Robot Type(Number): TLD(0), Media ID: N/A, Drive Name: N/A,Volume Pool: VMware_Day, Storage Unit: <Storage Unit>, Drive Scan Host: N/A,Disk Pool: N/A, Disk Volume: N/A10 févr. 2014 21:03:58 - granted resource backup.NBU_CLIENT.MAXJOBS.<Client>10 févr. 2014 21:03:58 - granted resource backup.NBU_POLICY.MAXJOBS.VMware_Prod10 févr. 2014 21:03:58 - granted resource 00810910 févr. 2014 21:03:58 - granted resource HP.ULTRIUM4-SCSI.00210 févr. 2014 21:03:58 - granted resource <Storage Unit>10 févr. 2014 21:03:58 - estimated 0 kbytes needed10 févr. 2014 21:03:58 - begin Parent Job10 févr. 2014 21:03:58 - begin VMware: Start Notify Script10 févr. 2014 21:03:58 - Info RUNCMD (pid=21091) started10 févr. 2014 21:03:58 - Info RUNCMD (pid=21091) exiting with status: 0Operation Status: 010 févr. 2014 21:03:58 - begin VMware: Step By ConditionOperation Status: 010 févr. 2014 21:03:58 - end VMware: Step By Condition; elapsed time 0:00:0010 févr. 2014 21:03:58 - begin VMware: Read File ListOperation Status: 010 févr. 2014 21:03:58 - end VMware: Read File List; elapsed time 0:00:0010 févr. 2014 21:03:58 - begin VMware: Create Snapshot10 févr. 2014 21:03:58 - started process bpbrm (pid=3048)10 févr. 2014 21:04:02 - end writingOperation Status: 15610 févr. 2014 21:04:02 - end VMware: Create Snapshot; elapsed time 0:00:0410 févr. 2014 21:04:02 - begin VMware: Stop On ErrorOperation Status: 010 févr. 2014 21:04:02 - end VMware: Stop On Error; elapsed time 0:00:0010 févr. 2014 21:04:02 - begin VMware: Delete Snapshot10 févr. 2014 21:04:02 - started process bpbrm (pid=3136)10 févr. 2014 21:04:03 - end writingOperation Status: 154210 févr. 2014 21:04:03 - end VMware: Delete Snapshot; elapsed time 0:00:01Operation Status: 15610 févr. 2014 21:04:14 - Info bpbrm (pid=3048) <Client> is the host to backup data from10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) reading file list from client10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) start bpfis on client10 févr. 2014 21:04:14 - Info bpbrm (pid=3048) Starting create snapshot processing10 févr. 2014 21:04:15 - Info bpfis (pid=4068) Backup started10 févr. 2014 21:04:15 - snapshot backup of client <Client> using method VMware_v210 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - VMware snapshot failed: Unrecognized error10 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - snapshot processing failed, status 15610 févr. 2014 21:04:17 - Critical bpbrm (pid=3048) from client <Client>: FTL - snapshot creation failed, status 15610 févr. 2014 21:04:17 - Warning bpbrm (pid=3048) from client <Client>: WRN - ALL_LOCAL_DRIVES is not frozen10 févr. 2014 21:04:17 - Info bpfis (pid=4068) done. status: 15610 févr. 2014 21:04:17 - end VMware: Start Notify Script; elapsed time 0:00:1910 févr. 2014 21:04:17 - Info bpfis (pid=0) done. status: 156: snapshot error encountered10 févr. 2014 21:04:18 - Info bpbrm (pid=3136) Starting delete snapshot processing10 févr. 2014 21:04:18 - Info bpfis (pid=0) Snapshot will not be deleted10 févr. 2014 21:04:19 - Info bpfis (pid=3624) Backup started10 févr. 2014 21:04:19 - Critical bpbrm (pid=3136) from client SLPPRAPP01: cannot open C:\Program Files\Veritas\NetBackup\online_util\fi_cntl\bpfis.fim.<Client>_1392062638.1.010 févr. 2014 21:04:19 - Info bpfis (pid=3624) done. status: 154210 févr. 2014 21:04:19 - end Parent Job; elapsed time 0:00:2110 févr. 2014 21:04:19 - Info bpfis (pid=0) done. status: 1542: An existing snapshot is no longer valid and cannot be mounted for subsequent operationssnapshot error encountered (156)
J'ai cherché davantage pour trouver un point commun à toutes, et ça s'est avéré fructueux : toutes ces VMs avaient été créées avec un display name contenant des accents, ce qui a provoqué la création des vmdk dans des répertoires à nom accentués. Les machines sans accents dans le display name avaient juste été renommées par la suite, mais leur arborescence était restée intacte, provoquant également l'erreur.
Le plus simple pour solutionner cela, est de cloner les VMs à problème vers des VMs 'propres', mais cela nécessite une interruption de service.
Alors à l'avenir : pas de backup-host en français, ni de noms de VMs avec des accents (par contre, les caractères internationaux comme &# et autres fonctionnent bien)
Aucun commentaire:
Enregistrer un commentaire