Nous avons le plaisir de vous annoncer que la prochaine version d’UltraBackup NetStation intégrera une fonctionnalité longuement attendue : le transfert de fichiers en « mode bloc », appelée ici « Transfert Delta ». Celle-ci permet de ne transférer que les blocs de données modifiés par rapport aux précédentes versions du fichier transféré.

Autrement dit, si vous sauvegardez un fichier de 50 Go dont seulement quelques méga octets ont été modifiés depuis la dernière sauvegarde, seules ces nouvelles données seront envoyées au serveur plutôt que la totalité du document. Le serveur reconstruira la nouvelle version du fichier à partir des données portées par les anciennes versions.

Comment ça marche ? Le transfert Delta consiste à découper les fichiers à sauvegarder en blocs. Chaque bloc est haché (ou « signé »), c’est-à-dire associé à une valeur numérique unique dépendante de son contenu. Lors de l’envoi, le serveur établit une liste complète des blocs qu’il possède en fonction des anciennes versions déjà stockées, et ne demande au client que les blocs qu’il ne possède pas déjà. Au final, le fichier à envoyer est reconstruit sur le serveur en ne transférant que les nouvelles données, apportant un important gain de vitesse de transfert.

Le logiciel proposera donc deux modes de transfert : la version originale par compatibilité avec les anciens agents clients, et la version Delta, par défaut activée pour toutes les nouvelles sauvegardes créées par des agents compatibles.

Nous prévoyons la sortie d’UltraBackup NetStation 6 pour le début de l’année 2017.

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 :