Erreur 156 NetBackup sur Hyper-V : corriger les snapshots

Le statut 156 de NetBackup sur Hyper-V signifie que l'opération de snapshot a échoué, mais il ne désigne pas une cause unique valable partout. Quand l'échec laisse des disques AVHD ou AVHDX non consolidés et que les checkpoints suivants échouent aussi, cessez de traiter l'événement comme une simple sauvegarde à relancer et dépannez directement la chaîne de snapshots Hyper-V.

Un administrateur a signalé plus de 100 serveurs touchés après des tentatives de snapshot NetBackup revenues en 156. L'hypothèse de travail était qu'un mot de passe de compte de service NetBackup avait changé sans être mis à jour sur les hôtes Hyper-V, et que les opérations en échec avaient laissé des disques qui ne se consolidaient pas.

Que signifie réellement l'erreur 156 de NetBackup sur Hyper-V ?

NetBackup documente le statut 156 comme « snapshot error encountered ». Le guide Hyper-V actuel cite plusieurs causes possibles plutôt qu'une correction directe, parmi lesquelles des noms de VM incorrects dans la politique, un espace libre insuffisant pour le snapshot et des composants d'intégration Hyper-V manquants ou incorrects. Autrement dit, le code de statut vous indique où le job a échoué, et chaque environnement peut échouer à cet endroit pour ses propres raisons.

Commencez par rassembler les détails du job NetBackup et les journaux d'événements Hyper-V d'une VM touchée. Identifiez la première erreur de snapshot, l'hôte qui l'a déclenchée, et vérifiez si Hyper-V arrive lui-même à créer un checkpoint en dehors de NetBackup. Si un checkpoint Hyper-V manuel échoue aussi, le problème se situe sous la couche de politique NetBackup : corrigez la VM Hyper-V, VSS, le stockage ou l'état des checkpoints avant de lancer une autre sauvegarde.

Un mot de passe de compte de service expiré peut-il provoquer cette série d'échecs ?

Oui, de mauvais identifiants peuvent casser la découverte ou les opérations d'API, mais le cas d'origine ne prouve pas que le changement de mot de passe soit la seule cause de tous les problèmes AVHDX restants. Un commentateur a rappelé que NetBackup pour Hyper-V dépend, dans certaines configurations, d'une identité de domaine pour les opérations de l'API Windows, et a suggéré de vérifier si la découverte fonctionne toujours.

Cela vous donne une ligne de partage utile. Si NetBackup ne peut pas parcourir ni découvrir les ressources Hyper-V, l'authentification et la configuration du compte demandent une attention immédiate. Si la découverte fonctionne mais que la création de snapshot échoue, poursuivez avec le dépannage des snapshots et de VSS.

Après avoir mis à jour le mot de passe d'un compte de service, vérifiez l'identifiant partout où il est stocké ou délégué, et testez un hôte et une VM avant de relancer la protection sur tout le parc. Corriger l'identifiant ne réparera pas automatiquement une chaîne de checkpoints déjà laissée en mauvais état. L'authentification peut expliquer l'échec initial alors que Hyper-V doit encore fusionner ou nettoyer les disques de différenciation qui en résultent.

Pourquoi des disques AVHDX non consolidés peuvent-ils bloquer les checkpoints suivants ?

Les checkpoints Hyper-V utilisent des disques de différenciation, en général des fichiers AVHDX, qui forment une chaîne parent-enfant avec les disques virtuels de la VM. Quand un checkpoint est supprimé, Hyper-V refusionne normalement les données de différenciation dans la chaîne parente.

Si cette fusion n'aboutit pas, la VM peut rester dans un état de checkpoint ou de chaîne de disques qui empêche de créer proprement de nouveaux snapshots, et les jobs NetBackup suivants peuvent échouer de nouveau même après la correction du déclencheur d'origine. Cela correspond au schéma répété de statut 156 observé par l'administrateur : le premier snapshot raté a créé un état d'infrastructure qui rendait l'échec du suivant plus probable.

Ne supprimez pas à la main des fichiers AVHDX du système de fichiers, car cela peut casser la chaîne et rendre la VM impossible à démarrer. Utilisez le gestionnaire Hyper-V, PowerShell, les journaux d'événements et les procédures de fusion ou de réparation des checkpoints supportées par Microsoft, en fonction de la relation réelle entre les disques.

Faut-il redémarrer plus de 100 VM pour consolider les disques ?

Un redémarrage peut sembler aider certains systèmes, mais redémarrer tout un parc est une mauvaise première stratégie de réparation. L'administrateur du cas a remarqué que le redémarrage des serveurs consolidait les disques et, on le comprend, ne voulait pas relancer plus de 100 machines.

Travaillez plutôt sur un échantillon. Choisissez une VM touchée non critique, documentez l'arborescence des checkpoints et la chaîne AVHDX avant le redémarrage, puis vérifiez précisément ce qui change ensuite. Si le redémarrage déclenche un nettoyage supporté, vous avez une preuve. Sinon, vous vous êtes épargné une opération de maintenance de masse sans bénéfice.

Pour le reste du parc, regroupez les VM par symptôme. Certaines peuvent avoir des checkpoints périmés, d'autres des échecs VSS, d'autres un manque d'espace, et certaines n'avoir besoin que d'une correction d'identifiants.

Le nombre d'opérations simultanées dans les politiques de sauvegarde compte aussi. Une grosse vague d'opérations de snapshot peut mettre sous pression les hôtes, le stockage et les composants de gestion : limitez le travail simultané à ce que le cluster Hyper-V peut absorber au lieu de laisser chaque VM protégée créer ses snapshots en même temps.

Quelles autres causes du statut 156 faut-il vérifier ?

Vérifiez l'espace libre dans les volumes concernés des VM et sur le stockage Hyper-V, puisque la documentation Hyper-V de NetBackup indique qu'un espace libre insuffisant peut faire échouer un snapshot. Vérifiez aussi que les noms ou identifiants de VM dans la politique correspondent toujours à l'inventaire Hyper-V réel. Contrôlez les composants d'intégration Hyper-V dans l'invité quand la configuration supportée les exige, puis la santé des writers VSS dans les invités Windows qui ont besoin de snapshots cohérents au niveau applicatif.

Méfiez-vous des conseils copiés de cas VMware. Le fil Reddit a brièvement évoqué un fournisseur VSS Veritas qui s'applique à certains processus VMware liés à l'état des applications, et un autre participant a fait remarquer à juste titre qu'il ne règle pas un cas Hyper-V. Gardez des frontières nettes entre plateformes : le comportement des snapshots Hyper-V, celui des snapshots VMware et la sauvegarde applicative dans l'invité peuvent tous produire des symptômes de « snapshot » tout en utilisant des composants différents.

Pour une comparaison plus large des sauvegardes de virtualisation, consultez les options de sauvegarde Proxmox. Les plateformes diffèrent, mais la même règle s'applique. La technologie de snapshot fait partie de la pile de l'hyperviseur et du stockage, si bien qu'un produit de sauvegarde peut déclencher l'opération sans être responsable de chaque échec qui se produit en dessous.

Comment éviter un nouvel incident de snapshots en masse ?

Corrigez la condition de départ, puis réduisez le rayon d'impact. Gérez le cycle de vie des comptes de service pour que les changements de mot de passe atteignent les intégrations de sauvegarde avant le prochain job planifié, et supervisez les échecs de découverte et d'authentification séparément des échecs de snapshot.

Fixez des limites raisonnables pour les ressources NetBackup et le nombre de jobs simultanés par unité de stockage. Les opérations de snapshot ont un coût : elles créent du travail de gestion, de stockage et de fusion qui peut devenir visible pendant une grande fenêtre de sauvegarde.

Surveillez les checkpoints et les fichiers AVHDX qui traînent après des échecs de sauvegarde. Un rapport quotidien qui repère les VM avec d'anciens checkpoints ou des chaînes de disques de différenciation inhabituelles peut détecter le problème secondaire avant qu'il ne touche 100 serveurs.

Le guide Proxmox Backup Server apporte un contexte utile venu d'une autre plateforme, car il traite la santé des sauvegardes et celle de l'hyperviseur comme des signaux distincts. Un job en échec peut relever d'un problème de configuration de sauvegarde, d'un problème de VM ou d'un problème de stockage.

Que ferais-je avec le parc touché ?

Je gèlerais les relances de sauvegarde répétées pour le groupe touché, puisqu'une nouvelle tentative de snapshot ne sert à rien tant que la chaîne de disques n'est pas saine. Ensuite, je corrigerais le compte de service suspect et je prouverais que la découverte des ressources et les opérations d'API fonctionnent sur un hôte Hyper-V.

Puis je choisirais une VM touchée pour voir si Hyper-V peut créer et supprimer un checkpoint à la main. J'examinerais VSS, l'espace libre, les journaux d'événements et les relations parent des AVHDX, puis j'utiliserais la méthode Hyper-V supportée pour fusionner ou nettoyer la chaîne de checkpoints.

Une fois une méthode de réparation validée, automatisez l'inventaire et répétez la procédure validée par lots contrôlés. Je ne réactiverais la protection NetBackup qu'une fois les VM en bonne santé.

Le statut 156 donne l'alerte. Le travail de reprise consiste à identifier quelle dépendance de snapshot a réellement échoué et à remettre l'hyperviseur en ordre avant la prochaine fenêtre de sauvegarde.