Archives de catégorie : Développement

UltraBackup NetStation 6.1 est sorti

Nous avons publié aujourd’hui la nouvelle version d’UltraBackup NetStation.

Outre les habituels correctifs de sécurité et de performance, les nouveautés incluent :

  • Nouvelles vues d’audit dans la console d’administration, permettant de tracker de manière générale l’activité des agents, des sauvegardes, et des utilisateurs,
  • Les alertes sont automatiquement réinitialisées tous les jours à minuit si la condition critique monitorée n’est plus active,
  • Possibilité de rechercher des fichiers par utilisateur depuis la console,
  • Amélioration de la vitesse du processus d’extraction des fichiers depuis la console d’administration.
  • Le serveur peut être démarré directement en mode maintenance,
  • Client et serveur : affichage d’un avertissement graphique lorsque les services ne sont pas démarrés,
  • Envoi d’un e-mail en cas d’impossibilité de réaliser le backup automatique de la base de données, d’erreur lors du nettoyage de la base ou du recalcul de la sélectivité des indexs.

La mise à jour doit être affichée dans la console d’administration. Si ce n’est pas le cas, vous pouvez télécharger la nouvelle version ici.

UltraBackup NetStation – Le transfert Delta (« sauvegarde bloc »)

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.

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.

 

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