Quelques notes à propos des plans d’exécution

Nous avons reçu à plusieurs reprises des appels de clients qui se plaignaient de comportements étranges avec les plans d’exécutions. Les sauvegardes exécutées dans leur contexte « débordaient » parfois de la plage horaire qui leur était assignée… Un comportement en contradiction avec le cahier des charges de cette fonctionnalité, censée délimiter strictement un horaire dans lequel les tâches devaient s’exécuter.

Une rapide inspection de leur serveur a permis de déterminer que certaines sauvegardes devant être exécutées dans le cadre de plans d’exécution possédaient également des paramètres individuels de planification, ce qui est la cause de ce qu’ils identifiaient comme un dysfonctionnement du logiciel.

Conceptuellement, il y a deux manières d’exécuter automatiquement une sauvegarde :

  • Soit la sauvegarde est déclenchée de manière autonome par l’agent client, en fonction des paramètres de planification qui lui sont associés,
  • Soit la sauvegarde est déclenchée par le serveur de sauvegarde dans le cadre d’un plan d’exécution. Dans ce cas, l’exécution est totalement pilotée par le serveur, qui décide quand lancer, relancer ou interrompre la tâche.

Mixer les deux modes de fonctionnement est une mauvaise idée. Non seulement cela sort de la logique précédemment exposée, mais cela peut aussi perturber l’exécution des plans d’exécutions. En effet, dès qu’une sauvegarde possédant des paramètres de planification est interrompue d’une manière qu’il considère comme « non prévue », l’agent client relance automatiquement la tâche. Par conséquent, le système serveur gérant les plans d’exécutions peut entrer en concurrence avec l’agent client pour démarrer ou redémarrer l’exécution de certaines tâches, alors que celles-ci devraient être abandonnées – la plage horaire du plan n’étant plus active. D’où le comportement inhabituel remarqué par l’utilisateur, dont il avait raison de se plaindre.

De ce fait, la version 5 d’UltraBackup vérifie systématiquement que les sauvegardes susceptibles d’être exécutées dans le cadre d’un plan d’exécution ne possèdent pas de paramètres de planification, et dans le cas contraire affiche un message d’information permettant de réinitialiser la planification :

Avertissement lors de la création d'un plan d'exécution

NS5 : les collecteurs d’activité journalière

La version 4.5 avait ajouté des fonctionnalités de collecte automatisée d’informations, principalement classables en deux catégories :

  • Les indicateurs systèmes volatiles de type « Nombre d’utilisateurs connectés en ce moment au serveur » ou « Nombre d’opérations en cours sur le serveur »,
  • Les indicateurs du volume de données stocké à un instant donné sur le serveur : « Nombre de fichiers sauvegardés sur le serveur », « Volume sauvegardé sur le serveur », etc.

La version 5 ajoute de nouveaux collecteurs permettant de suivre l’activité journalière serveur : nombre de sauvegardes effectuées chaque jour, nombre de restaurations, nombre de fichiers sauvegardés, nombre de fichiers restaurés, volume de données sauvegardé, et volume de données restauré :

Les collecteurs de données d'activité journalière

Comme pour les autres collecteurs les données brutes peuvent être exportées au format CSV pour un permettre un traitement statistique externe éventuel.

 

Activer le mode débogage de l’agent client

Lorsque l’agent client semble se comporter de manière étrange ou inexpliquée il peut être utile d’activer le mode Débogage afin que soit générée une trace détaillée des opérations effectuées.

Pour activer ce mode, démarrez le gestionnaire de sauvegardes, et cliquez sur le bouton « Système » :

Cliquez sur l’onglet « Avancé » et cochez « Activer le débogage » :

Vous pouvez ensuite lancer manuellement la sauvegarde problématique. A la fin de son exécution, un fichier texte contenant de nombreuses informations sera affiché à l’écran et pourra nous être transmis pour diagnostic.

Plus généralement, toute exécution de tâche sur le poste générera un fichier de trace, conservé dans le répertoire « DebugLog » du dossier de configuration client du logiciel. Sous Windows Vista et ultérieur, celui-ci est :

C:\ProgramData\UltraBackup NetStation\<numéro de version>\Client\DebugLogs

Les fichiers sont nommés avec la date du début de l’opération et contiennent toutes les informations nécessaires à nos services pour identifier un éventuel dysfonctionnement logiciel.

NS5 : L’annulation des sauvegardes

Depuis les premières versions d’UltraBackup, l’annulation d’une sauvegarde depuis la console d’administration ne fut pas véritablement optimal.

Jusqu’à la version 4, le processus était purement collaboratif : lorsqu’une sauvegarde était annulée, le serveur répondait à chaque trame cliente destinée à maintenir la session ouverte quelque chose du genre « Bien reçu, mais s’il te plaît arrête ta sauvegarde et déconnecte toi ! ». Les premières versions de l’agent client ne comprenaient tout simplement pas le message et continuaient la sauvegarde. D’autres versions un peu plus récentes terminaient l’envoi du bloc en cours avant de se déconnecter. La version 4.5 fermait manuellement le canal entre le client et le serveur pour forcer la déconnexion de l’agent quoi qu’il arrive, mais il restait un dernier problème. En effet, l’agent client voyait la sauvegarde comme anormalement interrompue, et reprenait au bout de quelques minutes l’exécution de la tâche si l’administrateur ne l’avait pas verrouillée dans l’intervalle.

Pour améliorer ce comportement, un nouvel indicateur interne a été ajouté sur les sauvegardes permettant de mémoriser si une sauvegarde a été annulée durant sa dernière exécution. Dans ce cas particulier :

  • Si la sauvegarde est planifiée, elle sera relancée automatiquement lors de la prochaine date satisfaisant les critères de planification,
  • Si la sauvegarde a été exécutée via une demande d’exécution serveur, cette dernière passera à l’état « La sauvegarde a été déclenchée mais son exécution a été annulée ».
  • Si la sauvegarde a été exécutée par un plan d’exécution, la sauvegarde ne sera pas relancée dans le cadre du plan d’exécution jusqu’à que celui-ci s’achève.

Autrement dit, les sauvegardes annulées ne seront plus automatiquement relancées par l’agent client car elle ne seront plus vues comme des tâches anormalement interrompue. Si vous avez annulé l’exécution d’une sauvegarde et que vous désirez la relancer par la suite, effectuez une demande d’exécution de la tâche depuis la console d’administration serveur.

NS5 : L’alerte de désynchronisation de l’horloge cliente

En tant que développeur, nous sommes parfois confrontés à de « drôles de bugs », pas vraiment critiques mais difficilement explicables, souvent induits par la complexité d’un système qui doit gérer des systèmes hétérogènes et de très multiples cas de figure. Voici l’histoire un peu longue d’un problème bénin qui fut une sorte de « fil rouge » pendant les derniers mois, jusqu’à que l’on puisse enfin récemment mettre le doigt sur sa cause.

Chez plusieurs clients, la ligne suivante réapparaissait à plusieurs reprises dans le journal des défaillances système, de manière assez aléatoire et uniquement sur certaines sauvegardes :

Backup write error for backup #XXX : cannot delete file #YYYYY created inside the same transaction.

Continuer la lecture de NS5 : L’alerte de désynchronisation de l’horloge cliente