NetBackup remonte régulièrement,sur tous les clients, des codes 48 : client hostname could not be found

J'ai, il y a peu, migré un serveur de sauvegarde NetBackup Linux via une copie du /usr/openv (c'est pas la méthode la plus jolie ni la plus recommandée, mais j'ai plein de bonnes raisons pour avoir utilisé ce procédé, que je ne donnerai pas ici).

Bref, j'ai installé NetBackup, vidé mon /usr/openv local, puis copié le /usr/openv du serveur d'origine (qui comportait le même nom évidemment). J'ai redémarrée NetBackup, et tout fonctionnait... Presque...

Les tests de sauvegardes local au master étaient concluants, mais quand je me suis rendu dans l'interface NetBackup, dans la partie Host Properties > Clients, chacun des clients me retournait un code 48 (client hostname could not be found).

Pour y remédier, j'ai purgé le host cache NetBackup (qui existe depuis la 7.0) via la commande bpclntcmd -clear_host_cache puis tenté de contacter chacun des clients via la commande bptestbpcd -host <client>. Tous répondaient et étaient opérationnels.

Mais voilà, pendant la nuit, les clients qui étaient pourtant disponibles, sont devenus injoignables avec un code 48 (encore). Un revidage du cache a réglé le souci, mais là encore c'était temporaire.

Des sauvegardes étant en cours, je n'ai pas pu arrêter NetBackup. J'ai donc supprimé à chaud les entrées présentes dans le répertoire /usr/openv/var/host_cache (c'est encore plus radical que le bpclntcmd -clear_host_cache). Ca a permis d'accéder au clients, mais contre toute attente, les codes 48 sont réapparus plus tard dans la nuit.

Mon salut est venu de la même opération, mais NetBackup arrêté, a croire qu'il existe une version du cache en RAM qui est régulièrement flushé sur disque. Le fait est qu'en vidant ce répertoire à froid, tout est rentré dans l'ordre... ouf.

Sauvegarde VMware via SAN en code 6 sous NetBackup

Je rencontre à nouveau le cas aujourd'hui, et je me rappelle avoir passé énormément de temps sur ce problème de fou (ou considéré comme tel) lors de ma première expérience. Donc je me suis dit qu'il était intéressant que je le rapporte ici.

Problème
Le souci est le suivant : vous configurez la sauvegarde VMware de manière classique, via l'agent dédié NetBackup.
Lors de votre test en sauvegarde réseau (nbd), tout se passe très bien, mais dès que vous activez le mode SAN (san), votre job de sauvegarde se plante en code 6 (mais avec le message "ERR - Error opening the snapshot disks using given transport mode: Status 23" dans la log ou alors bascule sur le mode LAN (si jamais vous avez autorisé les 2 modes).

Ce problème est répertorié dans cette Technote Symantec. Il ne se produit que si l'OS windows 2008 de votre Backup Host est en français (je sais c'est rare mais certaines société utilisent ce langage - C'est MAL, je le rappelle). Il est possible que ça arrive pour d'autres versions de Windows, je n'ai pas eu l'occasion de tester.

La raison est simple, L'API va vouloir utiliser un montage sur C:\Windows\TEMP\vmware-Système\, et avec l'accent, ça passe (très) mal. En anglais, cet accent n'existe pas et votre montage de snapshot va se dérouler sans le moindre problème.

Solution
Il existe un contournement :

• Editer (ou créer) le fichier C:\Program Files\Common Files\VERITAS\VxMS\Shared\VDDK\bin\vixDiskLib.ini, puis y ajouter la ligne suivante : tmpDirectory = "<temp path>", ou <temp_path> est le chemin où seront montés les snapshots de VM (sans y mettre des accents évidemment).
• Editer si besoin l'utilisateur renseigné dans les crédentials pour accéder au vCenter, pour que ce dernier n'utilise pas de caractères accentués.

Attention : en migrant de version NetBackup, le  fichier vixDiskLib.ini sera supprimé/écrasé, il faudra donc le recréer.