Supprimer des jobs en code 50 : Waiting for retry

Il arrive que sous NetBackup, des jobs bizarres se retrouvent dans l'activity monitor. Bizarres, car ils n'ont que très peu d'infos, pas de police par exemple ou encore pas de schedule. Ils n'ont qu'un code retour égal à 50, et un état en "Waiting for retry".
En général, ces jobs apparaissent quand on arrête NetBackup alors que des jobs étaient en cours de démarrage.

Ce n'est pas un problème en soi, car on se dit qu'on va les supprimer, et on en parlera plus. Mais c'est là que le bât blesse : il est impossible de les arrêter ou de les supprimer, ils font de la résistance (sous NetBackup inférieur à la version 7.5).

Il existe une solution simple, mais pas forcément pratique :

• Arrêter NetBackup sur le master
• Ensuite, 2 méthodes :
• Se rendre dans /usr/openv/netbackup/db/jobs et supprimer le fichier bpjobd.act.db
• lancer la commande /usr/openv/netbackup/bin/bpjobd -r (non testé)
• Redémarrer NetBackup

Voilà, c'est magique, les jobs en question sont de l'histoire ancienne !

Sous NetBackup 7.5 et plus, ces jobs apparaissent encore, mais ils sont (enfin) supprimables classiquement par l'interface d'administration.

Gestion des exclude-lists depuis le serveur maître

C'est toujours une question délicate, comment gérer ses exclude lists (et include par extension) ?

Parce qu'elles sont gérées différemment en fonction de l'OS par NetBackup (base de registre pour Windows, fichiers plats pour Linux/Unix), c'est rarement simple de s'y retrouver.
D'ailleurs, Symantec n'a pas réussi à harmoniser la gestion par l'interface graphique : on peut les modifier pour Windows (dans la partie client properties, puis "windows client"), mais pour les autres OS, on n'a pas cette possibilité.

Il est pourtant possible de tout gérer depuis le master server, mais en ligne de commandes uniquement. Par contre, pas de miracle, les commandes à passer ne sont pas les mêmes...

Pour Windows

Il est possible de lancer une commande permettant de récupérer l'exclude list du client :

bpgetconfig -M <client Windows> EXCLUDE

Pour la modifier, on met la sortie obtenue par cette commande dans un fichier, puis on le modifie. Ensuite, on met à jour le client par la commande

bpsetconfig -h <client Windows> <fichier d'exclude>

Pour Unix/Linux

Pour lister l'exclude list et la stocker dans un fichier, c'est cette commande qu'il faut utiliser :

bpgetconfig -e <fichier> <client>

Pour l'include list, c'est

bpgetconfig -i <fichier> <client>

On peut modifier ces fichiers et les repousser vers le client via la commande :

bpsetconfig -e <fichier> <client> 

ou

bpsetconfig -i <fichier> <client>

Pour chacune de ces commandes, il est possible de préciser la police ou le schedule sur lesquels s'applique... Je vous renvoie vers la documentation NetBackup pour plus de précisions.

Utiliser un partage CIFS comme dépot pour NetBackup

Problème rencontré ce jour, en clientèle et pour lequel j'ai eu pas mal de soucis à identifier son origine.

Petit rappel du contexte : intégration d'une appliance dédupliquante (ici une Quantum DXi), mais pour des raisons d'économies, ni OST ni VTL, mais un simple partage CIFS (car mon serveur NBU est sous Windows).
Comme Windows est bien fait et qu'il ne garde pas les montages réseau à la déconnexion du profil, impossible de passer par ce procédé, qui permet pourtant d'utiliser des credentials particuliers.

Dans mon archi du jour, la DXi présente un partage CIFS dans un réseau privé avec le serveur de sauvegarde, alors question sécurité, j'étais un peu tranquille. Ma solution :

• Utiliser un partage sans restriction d'utilisateur (parce que c'est un réseau privé hein !)
• Utilise le format UNC (vous savez le \\IP\nom_du_parrage\) dans la storage unit.

Tout se configure bien, Netbackup détecte bien l'espace présent sur le partage, tout roule quoi.

Je fais un test de sauvegarde et là... le bec dans l'eau : mon job tombe en code d'erreur 800 :

GENERAL ERROR: NBU status: 800, EMM status: Disk volume is down

Je fais un tour dans les logs, et dans l'interface graphique NBU j'ai le message suivant dans la page Disk Errors : 

Volume <MonDisk>:Internal_16 monitored by server is down S{cl-2060017} 

Pas vraiment de quoi m'aider en quelques sorte.

En cherchant sur le net, j'ai finalement trouvé ce HOWTO Symantec qui m'a bien aidé et qui m'a surtout appris une chose : NetBackup ne supporte pas les partages sans credentials sinon il les affiche comme DOWN.

Du coup, j'ai mis la DXi dans le domaine (via sa patte de management), et j'ai pu définir un utilisateur particulier pour accéder au partage.

Coté NetBackup, j'ai changé le compte lançant les services NetBackup pour utiliser ce fameux utilisateur.

J'ai vérifié que le serveur, quand je me connectais par ce compte, pouvait bien accéder au partage de la DXi, puis j'ai redéfini la STU NetBackup. J'ai relancé la sauvegarde qui est finalement passée.

En espérant que cela puisse servir à d'autres.

Full synthetic backup

On connait tous les problèmes de fenêtres de sauvegarde qui explosent. Souvent, c'est le week-end que ça coince, quand on fait nos sauvegardes Full habituelles, et que le réseau a du mal à faire passer tout le flux nécessaire dans les temps.

Il existe un moyen d'améliorer ça sans le moindre investissement : les sauvegardes full synthétiques.

Quezako ?

Le principe est simple : on prend une full, les incrémentales qui ont suivi, et on génère une sauvegarde full à partir de tout ça.

Ce qui donne à peu près ça :

Avantages :

• Ne transite plus que le réseau, que des sauvegardes incrémentales, bien plus rapides et moins consommatrices de bandes passantes
• La réalisation de la sauvegarde full est beaucoup plus rapide car n'est plus contrainte par la bande réseau limitée

Inconvénients :

• Il faut faire une incrémentale juste avant la full Synthétique si on veut garder un niveau de service identique (sinon on ne fait réellement pas de sauvegarde du client le jour de la full)
• Il faut gérer la 1ère full qui doit être classique, ce qui demande un peu d'administration

Et en plus ça s'optimise !

Si vous utilisez sur votre serveur un mécanisme de déduplication (appliance type DXi ou DataDomain, ou un espace dédupliquant interne au serveur), il est possible de mettre la déduplication à contribution.
En effet, votre espace dédupliquant à déjà tous les blocs de données (puisqu'il héberge la full et les incrémentales), il lui est donc tout à fait facile de générer la nouvelle full, puisque cela ne lui demande que de refaire un nouveau jeu de pointeurs vers des blocs déjà existants.

Contrairement à la version "non optimisée" où la création de la nouvelle full demande de relire les images de sauvegarde déjà faite et de créer la nouvelle (ce qui prend du temps en fonction du volume à traiter, et de la vitesse des équipements), ici la création des pointeurs prends seulement quelques minutes.

C'est fiable docteur ? 

C'est le gros problème de la full synthétique : on a du mal à lui faire confiance. Pourtant, depuis que je l'utilise, aucun souci n'a été remonté, et il n'y a pas de raison pour douter de cette technologie.

On a entendu : "il vaut mieux faire une full tous les mois quand même", mais pourquoi ? Si on doute de la techno dans le temps, pourquoi lui faire confiance pour les sauvegardes hebdomadaires ?

De plus, des vérifications sont mises en oeuvre dans les outils de sauvegarde (voir plus loin)

Sous NetBackup...

Comme c'est mon logiciel de prédilection, je fais un petit focus sur quelques petits points :

Mise en oeuvre : il suffit de cocher la case "Synthétic backup" dans le schedule (qui doit être de type full ou cumulative incremental)

Les limitations :

• NetBackup ne supporte la synthétique que sur les sauvegardes fichier (polices "standard" et "MS-Windows")
• Il ne faut pas multiplexer les sauvegardes pour pouvoir faire de la full (l'option à cocher sera grisée sinon)

Sécurisation : NetBackup vérifie que les incrémentales sont bien toutes là lorsqu'il fait la synthétique. Si jamais une des images incrémentales a été expirée avant de faire la synthétique, on aura le droit à un beau code d'erreur 671 signalant une impossibilité de regénérer la full.

NetBackup 7.5.0.4 est de sortie

Le 24 septembre, Symantec a sorti sa dernière mise à jour NetBackup, la 7.5.0.4.

Au programme, pas de nouvelle fonctionnalités, mais une grosse séries de corrections de bugs (315 en plus que la 7.5.0.3, 700 en tout !).

On notera tout de même quelques nouveautés :

• Nbostproxy multiples sur les clients avec déduplication
• Support des plugins OST tiers sur les appliances

Pour rappel, ces patches peuvent être appliqués sur les clients sans l'appliquer sur les media-servers ou les masters. Il faut cependant que le media-server soit au moins en version 7.5.0.1 (pas de restriction sur le master). Pour plus de précisions, voir la release note.

A noter le changement de méthode de Symantec, qui sort en parallèle la mise à jour sur les appliances N52x0 (Release Update 2.5.1).