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é :

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

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.

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 →

Deux nouveautés importantes relatives aux rapports d’exécution sont incluses dans la nouvelle version 5 d’UltraBackup NetStation.

La première nouveauté concerne diverses optimisations qui permettent une génération et un chargement bien plus rapide des rapports par rapport aux versions antérieures. Jusqu’ici, nous utilisions comme format intermédiaire un document XML, stocké dans la base de données, qui contenait les divers éléments à mettre en forme dans les rapports affichés dans la console d’administration ou le gestionnaire de sauvegarde. De fait, le format XML est relativement verbeux et l’espace occupé en base de données pour de « grosses » sauvegarde était souvent assez démesuré… Par ailleurs, le parseur Microsoft MSXML n’est pas non plus un foudre de guerre, surtout dans le cas de documents volumineux, et les temps de génération pouvaient parfois être excessivement longs pour des sauvegardes contenant de nombreux fichiers modifiés.

La version 5 utilise désormais le format JSON, beaucoup plus compact, associé à un parseur natif bien plus rapide que celui de Microsoft. Les temps d’accès aux rapports sont donc drastiquement améliorés par rapport à la version 4 ! Pour des raisons de compatibilité la génération au format JSON est activée uniquement pour les agents clients en version 5 et les deux formats internes cohabitent de manière transparente pour les utilisateurs.

La seconde nouveauté est la possibilité de stocker les rapports de sauvegarde en dehors de la base de données. Par défaut, ceux-ci sont insérés dans une table contenant le résumé de toutes les exécutions. Lorsque de nombreuses sauvegardes contenant un nombre important de fichiers modifiés s’exécutent, des rapports de plusieurs kilo-octets (voire méga-octets, lorsque plusieurs centaines de milliers de fichiers sont régulièrement modifiés) sont générés et stockés dans le fichier de base de données.  Dans ce cas, il peut être pratique de déporter ce stockage dans un répertoire sur le disque serveur, pour éviter d’alourdir inutilement la base. Cette option peut être configurée dans la vue « Rapports de sauvegarde » des options serveur :

La version 5 de l’agent client UltraBackup fusionne les travaux ayant aboutis à UltraBackup Home et intègre un moteur de sauvegarde local permettant de réaliser la copie de données sur des disques attachés à l’ordinateur. Les deux types de sauvegardes sont totalement indépendants et les mêmes données peuvent à la fois être sauvegardés sur une clé USB ou un disque dur externe et sur le serveur de sauvegarde.

Pour proposer cette nouvelle fonctionnalité, le gestionnaire de sauvegardes possède un nouveau volet « Destinations », sur la gauche, permettant d’afficher les tâches en fonction de leur cible :

• Un clic sur la ligne « Sauvegardes sur le serveur » affiche les sauvegardes dont la destination est le serveur UltraBackup (l’ancienne vue par défaut dans les versions précédentes du logiciel),
• Un clic sur la ligne « Sauvegardes sur cet ordinateur » affiche les sauvegardes dont la destination est un disque local attaché au poste.

Les disques de stockage locaux utilisés par les sauvegardes apparaissent sous le nœud « Sauvegardes sur cet ordinateur », et il est possible d’afficher uniquement les sauvegardes stockées sur un disque spécifique en cliquant sur son nom. Une puce grise indique que le disque n’est pas connecté, une puce verte que le disque est connecté, une puce rouge que le disque est connecté mais que le volume contient moins de 10% d’espace de stockage libre.

La création de nouvelles sauvegardes reste quasiment inchangée – un sous-menu apparaît simplement lors du clic sur le bouton « Nouvelle sauvegarde » permettant de choisir entre la création d’une sauvegarde sur le serveur et une sauvegarde locale :

Nous avons veillé à ce que les sauvegardes locales soient intégrées de manière transparentes au logiciel et que les mêmes fonctionnalités soient, dans la mesure du possible, applicables de manière similaire aux deux types de tâches. Par exemple, l’exécution des sauvegardes locales déclenche la création de rapports similaires à ceux produits par les sauvegardes sur le serveur, consultables dans la vue « Rapports » du gestionnaire de sauvegarde.

Pour permettre à l’administrateur de contrôler le statut global des sauvegardes et ainsi détecter toute erreur de copie ou de configuration des tâches, les rapports d’exécution des sauvegardes locales sont par défaut transmis au serveur de sauvegarde. La vue de l’historique des opérations dans la console d’administration intègre donc les résumés et les rapports d’exécution des tâches locales et centralisées, permettant d’embrasser une vue globale sur le système de sauvegarde.

Nous pensons que l’intégration d’une fonctionnalité de sauvegarde locale ajoute un niveau de sécurité supplémentaire pour vos données et vous permettra de tirer parti d’un nouveau mode de protection adapté à des usages alternatifs !

Voici quelques liens supplémentaires relatifs aux fonctionnalités de sauvegarde locale :

• Options de sauvegarde
• Gestion des disques amovibles
• Exécution des sauvegardes en arrière-plan
• Conservation de l’historique des versions avec l’horodatage des sauvegardes
• Informations de suivi d’exécution