vendredi 18 octobre 2019

REX Veeam

Voici un petit retour d’expérience sur un problème que j’ai rencontré avec Veeam Backup & Replication 9.5 U4. Je voulais partager ce REX avec vous car il m’a donné quelques cheveux gris 😊

Chez mon client, nous sommes actuellement en plein projet de migration depuis un logiciel de sauvegarde lambda vers Veeam Backup. Au fur et à mesure, nous désactivons la sauvegarde d’un cluster VMware sur l’ancien logiciel de sauvegarde, pour l’activer côté Veeam. Jusque-là tout va bien.

Puis un matin, je vérifie les sauvegardes de la veille et je me rends compte que certains ont fonctionné, mais la plupart sont restés à 0% d’avancement à l’étape suivante : « Pending : Polling Scale-Out Backup Repository extents »

Donc pas de message d’erreur car les jobs n’ont pas échoués, mais cela fait plus de 12h qu’ils sont en attente, et clairement ils n’avanceront plus… 1er réflexe, je me dis que les serveurs proxy sont sous-l’eau ou qu’ils ont un problème. Je me connecte dessus pour vérifier, sans rien remarquer d’anormal. Dans le doute je décide de les redémarre un à un ; mais cela ne change pas le problème. Finalement je redémarre le serveur Veeam lui-même, et les 1ers jobs semblent repartir.

Le lendemain matin, je vérifie les sauvegardes, et de nouveau les jobs sont en attente « Pending : Polling Scale-Out Backup Repository extents » !

Donc je sens tout de suite que ce problème est plus profond, qu’il va se reproduire et va me faire perdre pas mal de temps, donc j’ouvre tout de suite un ticket au support Veeam. La personne du support vérifie tous les logs, et me dit que les serveurs proxy doivent être saturés ou que la connexion avec les target repository doit être HS. On vérifie tout ça, mais ce n’est pas ça le problème. On convient alors d’une prise de main en webex. De là, il vérifie toute la configuration de chaque Repository, Scale-Out Repository, ainsi que chaque serveur proxy, Gateway server, et Mount server… Tout semble correct et on commence à s’arracher les cheveux !

Finalement, après avoir épluché pas mal de logs, on a fini par trouver qu’au fur et à mesure de notre projet de migration, et qu’on ajoutait de nouveaux jobs Veeam, la base de données ainsi que les logs avaient bien grossi et qu’ils saturaient l’espace disque sur la partition du cluster SQL. Donc sans pouvoir écrire de nouveaux journaux de transactions, Veeam restait en attente, CQFD !

Au final, rien de très sorcier, mais les messages d’erreur étant inexistants, difficile de pointer du doigt le problème.

Moralité : bien designer la partie SQL, monitorer l’espace disque, et ceci surtout quand elle est mutualisée avec d’autres applis.

0 commentaires :

Publier un commentaire