Cet article un peu technique vise à expliciter l’introduction d’une nouvelle fonctionnalité visant à sécuriser la création de clichés VSS, permettant la copie des fichiers ouverts dans UltraBackup NetStation.

Par défaut, les sauvegardes créées avec UltraBackup NetStation exploitent le composant Volume Snapshot Service qui permet l’accès aux fichiers ouverts et la sauvegarde d’un état cohérent (non mouvementé) d’un ensemble de fichiers. L’utilisation de VSS est vivement recommandée pour permettre d’inclure tous les fichiers prévus pour la sauvegarde sans en manquer un lors du processus. Dans le cas contraire, les sauvegardes peuvent être incomplètes car certaines applications exploitaient des fichiers ouverts contenus dans la sauvegarde.

VSS collabore avec des « fournisseurs » installés sur le poste, fournis par Microsoft ou des éditeurs tiers, pour obtenir un état stable et sauvegardable des fichiers sur un volume donné. Par exemple, si Microsoft Office est installé, le service VSS demandera au fournisseur VSS Office de présenter pour les documents ouverts une version cohérente pouvant être sauvegardée par UltraBackup.

Tout se passe bien pour les applications les plus répandues : Microsoft Word, Excel, Outlook, SQL Server, etc.. mais que se passe t-il lorsque des fichiers ouverts sont sauvegardés grâce à VSS sans qu’un fournisseur VSS correspondant soit installé sur le poste ?

Pour les applications non compatibles VSS, le composant garantit une consistance au niveau du système de fichiers, mais non au niveau du contenu des données. Autrement dit, les fichiers contenus dans le cliché VSS correspondront à l’état du disque tel qu’il pourrait l’être si le poste avait crashé au moment de l’ouverture du cliché. Prenons le cas d’un fichier de type « base de données », exploité par un logiciel de base de données quelconque.

En théorie, les logiciels de base de données sont conçus pour être tolérants aux fautes, c’est-à-dire que si le poste client crashe alors que le fichier était ouvert, l’application doit être capable de le récupérer lors de la prochaine utilisation. Il n’est pas question du cas où le fichier est en cours d’écriture, seulement du cas où le fichier est ouvert (en cours d’utilisation) sans modification particulière en cours. Evidemment, l’application doit être conçue manière « propre » : si une application utilise abusivement le cache mémoire sans sérialiser de manière régulière les données à écrire,  il n’y aura aucun moyen de faire une sauvegarde cohérente sans collaborer avec elle (au pire : l’arrêter, au mieux : lui dire d’écrire tout ce qu’elle a à écrire avant la sauvegarde).

Si l’on suppose qu’on travaille avec des applications conçues pour protéger correctement leur données, alors on sait qu’en cas de crash du système d’exploitation les données seront préservées (ou du moins récupérables). Reste le cas problématique du crash en cours d’écriture : soit le programme comporte un système de journalisation qui lui permettra de récupérer au dernier état stable (ou de rejouer l’écriture), soit rien n’a été prévu dans ce cas (cas rare pour un SGBD…) dans ce cas on a un fichier dans un état indéterminé, et on ne sait pas quoi en faire. C’est ce dernier cas qu’on veut par sécurité à tout prix éviter.

Comme nous l’avons dit précédemment, la sauvegarde de fichiers ouverts via VSS de bases de données ne fournissant pas de provider VSS s’apparente à une copie binaire du fichier à un instant T, correspondant exactement à un état après crash du poste à l’instant de la création du cliché. Comme précédemment dit, le seul cas réellement problématique dans cette configuration se produit lorsque le programme écrivait des données au moment de la création du cliché.

L’idée est donc de monitorer les écriture dans les éléments à sauvegarder pour attendre un état de stabilité certes heuristique, mais à priori valide.  Certes, si l’application écrit répétitivement et perpétuellement quelque chose toutes les 0.5s dans un fichier à sauvegarder on n’atteindra jamais un état stable des données, mais cela impliquerait dans ce cas un sérieux problème de conception… Par conséquent, l’attente de la fin des entrées/sorties en écriture sur le jeu de données à sauvegarder pendant une durée courte mais probante (quelques secondes) puis la création immédiate d’un cliché de données et la sauvegarde de ce cliché constitue la solution la plus simple et la plus sûre pour sauvegarder des fichiers ouverts n’ayant pas forcément de fournisseur VSS associé.

Cette fonctionnalité est désormais disponible dans UltraBackup NetStation 4, et activée par défaut. Elle peut être modifiée dans les options avancées du logiciel :

Lorsque UltraBackup NetStation est utilisé en contexte de télésauvegarde, le « coût » de la première sauvegarde peut être important, du fait du volume de données à transférer entre le client et le serveur et du débit relativement modeste d’une ligne ADSL classique. Pour faciliter la sauvegarde dans un tel contexte, UltraBackup NetStation 4 propose désormais un outil de pré-chargement de données (seed loading).

Pour ce faire, vous devez créer la sauvegarde sur le poste client (sans l’exécuter, bien sûr), puis copier – par exemple sur un disque dur amovible ou une clé USB – les données à sauvegarder. Côté serveur, il vous suffit d’utiliser la fonction « Pré-charger des données » dans la vue des sauvegardes :

Le logiciel va créer un compte utilisateur temporaire sur le serveur et installer le client de sauvegarde. Vous serez ensuite invité pour chaque élément de la sauvegarde à choisir une source locale à traiter, correspondant à l’élément stocké sur le disque amovible contenant les données d’origine du poste client :

L’assistant va ensuite exécuter la sauvegarde de données à partir des sources locales :

Une fois terminé, les données auront été injectées dans le serveur de sauvegarde comme si elles avaient été sauvegardées sur le poste d’origine. La prochaine exécution de la sauvegarde sur le poste client n’enverra que les fichiers modifiés depuis cette sauvegarde initiale, ce qui représente normalement un volume et un temps d’envoi tout à fait raisonnable.

UltraBackup NetStation permettant de centraliser le stockage de documents sur un serveur central, le sens par défaut de communication des données est des clients vers le serveur, ce qui nécessite simplement pour l’administrateur système d’ouvrir sur le serveur le port utilisé pour transférer les données. Lorsque des exécutions de sauvegardes sont programmées depuis le serveur de sauvegarde (ou plus généralement que des informations doivent être transmises aux clients) cela était réalisé grâce à un système de synchronisation automatique impliquant que le client demande régulièrement au serveur quelles tâches il devait traiter. De cette manière, il n’était pas nécessaire d’ouvrir un port particulier au niveau des clients pour que le serveur puisse s’y adresser.

Ce mode de communication posait problème dans le cas ou le serveur devait communiquer avec les clients en temps réel, par exemple pour créer une sauvegarde et parcourir les données à copier depuis la console d’administration. Jusqu’ici, un module dit « d’accès à distance » était installé sur le clients, et implémentait un petit serveur FTP offrant la possibilité de lister les dossiers du poste depuis la console UltraBackup. Néanmoins, cela impliquait forcément qu’il fallait ouvrir des ports au niveau de chaque client devant être administrable à distance, ce qui en réalité était trop contraignant pour être réellement utile.

UltraBackup NetStation 4 introduit un canal de communication du serveur vers les clients, qui utilise un système de communication inversé (le client est dans un état permanent d’attente de requêtes de la part du serveur) permettant un échange bi-directionnel de données sans que des ports aient besoin d’être ouverts au niveau des postes client. Ce canal est principalement exploité pour parcourir les données des clients à distance (et donc pour créer des sauvegardes très facilement depuis la console d’administration), et pour déclencher des sauvegardes en temps réel sur les postes.

Le canal est par défaut activé sur les clients en version 4. Côté serveur, les clients connectés et pouvant être contrôlés à distance apparaissent en vert dans la liste des utilisateur. Les clients connectés dont le canal client à serveur n’est pas actif apparaissent en jaune :

Ainsi, il est aisé de créer et déclencher des sauvegardes à distance. La capture d’écran ci-dessous présente l’interface de parcours des fichiers distants :

L’accès aux fichiers est réalisé de manière transparente pour le client et l’administrateur. Aucun port supplémentaire n’est à ouvrir côté client et la fonctionnalité est exploitable « out of the box », sans paramétrage particulier. L’administration des sauvegardes est donc grandement améliorée par rapport aux versions précédentes du logiciel.