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 :
Notez que les techniques de détection d’écritures ne fonctionnent que sur des disques locaux, et non sur des volumes réseau.
