Cliché instantané de volume (VSS) : fonctionnement et pratique — Pourquoi peut-on sauvegarder des fichiers en cours d'utilisation ?

« En essayant de copier un fichier qu’une autre application avait ouvert, on m’a répondu sèchement que le processus ne pouvait pas accéder au fichier. » « On m’a demandé de sauvegarder le dossier de données sans arrêter le système central. » « Comment un logiciel de sauvegarde peut-il copier sans problème un fichier de base de données en cours d’utilisation ? » — Que ce soit dans le développement d’applications métier ou dans l’exploitation d’un serveur de fichiers, c’est une question à laquelle on finit tôt ou tard par se heurter.

Au cœur de la réponse se trouve le service de cliché instantané de volume (VSS : Volume Shadow Copy Service). C’est un mécanisme intégré à Windows depuis plus de vingt ans, sur lequel reposent Windows Server Backup, la restauration du système, et pratiquement tous les logiciels de sauvegarde du commerce.¹

Cet article s’adresse aux développeurs d’applications métier à qui l’on demande une « fonction de copie de fichiers en cours d’utilisation », ainsi qu’aux responsables informatiques qui exploitent la sauvegarde de serveurs de fichiers et de PC de bureau. Il présente les acteurs et le fonctionnement de VSS, la pratique d’exploitation avec vssadmin, ainsi que la question de savoir « jusqu’où un développeur doit-il s’impliquer dans VSS », le tout sur la base de sources primaires à jour au mois d’août 2026. La série « Les tréfonds des E/S Windows » a exploré l’intérieur du gestionnaire de cache et de NTFS ; cet article en est la suite et traite de la couche « instantané » qui s’intercale juste au-dessus du volume.

1. La conclusion, d’abord

• VSS est un ensemble d’interfaces COM et un service de coordination qui rendent possible la « sauvegarde d’un volume sur lequel une application continue d’écrire ». Il est intégré à Windows depuis Windows XP.²
• Les acteurs sont au nombre de trois rôles, plus un rôle de coordination. Le service VSS met en relation le demandeur (logiciel de sauvegarde) qui réclame le cliché instantané, l’enregistreur (SQL Server, etc.) qui garantit la cohérence des données côté application, et le fournisseur qui crée réellement le cliché instantané.¹
• Le fournisseur système standard de Windows utilise la méthode de la copie sur écriture. Plutôt que de dupliquer tout le volume, seuls les blocs réécrits après la création du cliché instantané sont mis de côté, avant réécriture, dans une zone de différence (diff area). Cette zone de différence doit se trouver sur un volume NTFS.¹
• Le point de cohérence est créé selon la séquence « gel des enregistreurs (60 secondes maximum) → création du cliché instantané (10 secondes maximum) → dégel ». Si ces délais sont dépassés, la création est annulée et le demandeur recommence.¹
• La qualité de la copie dépend de la coopération ou non de l’enregistreur. Un cliché instantané pris sans coopération équivaut à « l’état du disque au moment d’une coupure d’alimentation » (cohérence après incident, ou crash-consistent) ; avec coopération, les journaux sont roulés et le cache est vidé au préalable, ce qui produit un état cohérent que l’application elle-même garantit récupérable (cohérence applicative, ou application-consistent).³¹
• L’outil de vérification en exploitation est vssadmin. Utilisez list shadows / list writers / list shadowstorage pour observer l’état actuel, et resize shadowstorage pour ajuster la limite de la zone de différence. Une fois la zone de différence épuisée, les clichés instantanés les plus anciens sont supprimés silencieusement.⁴⁵¹
• Intégrer un demandeur VSS dans une application maison représente un gros chantier. L’API est native, basée sur COM, et il n’existe pas de wrapper officiel pour .NET. Dans la plupart des cas, une nouvelle tentative, un ajustement du mode de partage ou un arrêt de courte durée suffisent ; si VSS est réellement nécessaire, un script DiskShadow constitue la solution réaliste (réservé à Windows Server).⁶⁷
• Un cliché instantané n’est pas une sauvegarde en soi. La différence issue de la copie sur écriture dépend des blocs intacts du volume d’origine ; elle est donc impuissante face à une panne qui emporte le volume d’origine tout entier, comme une panne de disque ou un vol. Elle n’est pas non plus fiable face à un rançongiciel, qui peut supprimer le cliché instantané lui-même (7.3) ou épuiser la zone de différence par des réécritures massives (7.4). Elle ne prend tout son sens que combinée à une sauvegarde sur un autre support.¹

2. Poser le problème — pourquoi un fichier en cours d’utilisation ne peut-il pas être copié normalement ?

Le point de départ, c’est le mode de partage des fichiers sous Windows. Lorsqu’on ouvre un fichier (CreateFile), on déclare, via le mode de partage (dwShareMode), « ce que l’on autorise aux autres processus pendant que l’on tient le fichier ouvert ». Tant qu’un processus l’a ouvert sans autoriser le partage en lecture, tout processus qui tente ensuite de l’ouvrir en lecture échoue avec une violation de partage (ERROR_SHARING_VIOLATION, erreur 32).⁸ En .NET, cela se manifeste par la fameuse IOException (« le processus ne peut pas accéder au fichier car il est en cours d’utilisation par un autre processus »).

Ce qui compte, c’est que ce n’est pas un bug, mais un mécanisme légitime destiné à protéger les données. Si un fichier en cours d’écriture pouvait être lu à mi-chemin, le lecteur obtiendrait un « état intermédiaire, à moitié écrit ». La conception du contrôle d’exclusion, traitée en détail dans « Les bases du contrôle d’exclusion pour l’échange de fichiers », est le socle de toute intégration entre applications.

Mais ce mécanisme légitime entre fondamentalement en conflit avec la sauvegarde.

• Le mur de la violation de partage : un fichier laissé ouvert par une base de données ou une application métier peut tout simplement ne pas pouvoir être ouvert comme source de copie.
• Le mur de la cohérence : même si l’ouverture est possible (le partage en lecture est autorisé), la copie prend du temps. Comme l’application continue d’écrire pendant la copie, le début et la fin du fichier peuvent finir par refléter des instants différents, ou plusieurs fichiers (les données et leur journal, par exemple) peuvent devenir incohérents entre eux. De plus, comme on l’a vu dans l’épisode consacré au « gestionnaire de cache », une écriture passe d’abord par le cache en mémoire : regarder uniquement le fichier sur le disque ne garantit donc pas d’en voir la version la plus récente.
• Le mur de l’exploitation : « il suffit d’arrêter l’application avant de copier » est un raisonnement juste en théorie, mais inacceptable pour un système métier ou un serveur de fichiers actif 24 h/24.

Autrement dit, le besoin réel est : « obtenir, sans arrêter l’application, une copie cohérente prise à un instant donné ». C’est une charge trop lourde pour que chaque application la résolve seule ; VSS a été conçu comme un mécanisme au niveau du système d’exploitation pour y répondre. VSS est fourni comme un framework à base d’interfaces COM permettant de sauvegarder un volume alors même qu’une application continue d’y écrire.²

3. Les acteurs de VSS — demandeur, enregistreur et fournisseur

La composition de VSS s’organise autour de trois rôles et d’un service qui les met en relation.¹

Le mérite de cette répartition des rôles, c’est qu’elle permet à des produits qui s’ignorent mutuellement de coopérer. Le logiciel de sauvegarde (le demandeur) ne connaît rien de la structure interne de SQL Server, mais l’enregistreur de SQL Server déclare, sous forme de métadonnées, « l’ensemble de fichiers à sauvegarder (les composants) » et met ses propres données en ordre juste avant et après la création du point de cohérence ; le demandeur n’a alors qu’à s’y conformer pour obtenir une sauvegarde cohérente.¹⁹ Pratiquement tous les logiciels de sauvegarde tiers fonctionnant sous Windows sont des demandeurs VSS.¹

Dans la pratique informatique, c’est en dépannage que l’on prend conscience de ces trois rôles. Selon que l’échec d’un logiciel de sauvegarde relève du demandeur (côté logiciel), d’un enregistreur particulier (côté application) ou du fournisseur / de la zone de différence (côté infrastructure), l’endroit où chercher change complètement (chapitres 5 et 7).

4. Le mécanisme du cliché instantané — la copie sur écriture et le « point de cohérence »

4.1. La copie sur écriture — conserver « cet instant » sans dupliquer le volume

Le mot « instantané » évoque une duplication complète du volume, mais le fournisseur système standard de Windows utilise la méthode de la copie sur écriture (copy-on-write). Au moment de la création du cliché instantané, presque rien n’est copié. Ensuite, lorsqu’un bloc du volume d’origine est réécrit, le bloc antérieur à la réécriture est mis de côté dans la zone de différence (diff area, la zone de stockage de cliché instantané) avant que l’écriture ne soit validée.¹ Cette mise de côté n’est nécessaire que lors de la première réécriture de chaque bloc ; réécrire à nouveau un bloc déjà mis de côté n’augmente pas la zone de différence.

Pour lire « le volume tel qu’il était à cet instant », les blocs inchangés sont lus depuis le volume d’origine et les blocs modifiés depuis la zone de différence, puis le tout est recomposé. Comme seule la partie modifiée est copiée, la création est instantanée et l’espace consommé se limite à la différence. À l’inverse, plus un volume reçoit d’écritures, plus vite sa zone de différence se remplit (c’est l’amorce du chapitre 7), et cette zone de différence se trouve sur un volume NTFS de la même machine que les données d’origine.¹ Ce mécanisme repose sur swprv.dll, le fichier de composant du fournisseur système, et sur volsnap.sys, le pilote qui s’intercale dans les E/S du volume.¹ Pour qui s’intéresse à la « façon de s’intercaler » dans la pile d’E/S, voir aussi « Pilotes de filtre et minifiltres ».

Il existe par ailleurs d’autres méthodes : la copie complète, qui sépare un miroir, et la redirection sur écriture, qui écrit les modifications vers un autre volume ; les fournisseurs matériels utilisent, côté baie de stockage, la méthode la plus adaptée.¹

4.2. Le déroulement de la création du point de cohérence — la coordination gel 60 secondes / création 10 secondes

Si la copie sur écriture répond à « comment sauvegarder », le cœur de VSS répond à « l’état de quel instant sauvegarder », c’est-à-dire à la façon de créer le point de cohérence. La création d’un cliché instantané suit le déroulement suivant.¹

flowchart TB
    R["Le demandeur demande la création<br/>Énumère les enregistreurs et collecte les métadonnées"] --> M["Chaque enregistreur déclare en XML<br/>les données à sauvegarder (composants)"]
    M --> P["Chaque enregistreur prépare ses données<br/>Roulement des journaux, vidage du cache, etc.<br/>Mise en état cohérent et récupérable"]
    P --> F["Gel des E/S d'écriture des enregistreurs<br/>(la lecture reste possible. 60 secondes maximum)"]
    F --> FS["VSS vide les tampons du système de fichiers<br/>et gèle le système de fichiers"]
    FS --> C["Le fournisseur crée le cliché instantané<br/>(en 10 secondes maximum. Les E/S d'écriture restent gelées durant ce temps)"]
    C --> T["Libération du système de fichiers → dégel des enregistreurs (thaw)<br/>L'application reprend ses écritures"]
    T --> B["Le demandeur exécute la sauvegarde<br/>à partir du cliché instantané, en prenant son temps"]

Figure 1 : le déroulement de la création d’un cliché instantané. L’arrêt ne dure que de quelques secondes à quelques dizaines de secondes ; la sauvegarde elle-même s’exécute sur le cliché instantané.

Trois points sont à retenir.

1. L’application n’est arrêtée que pendant l’instant de création du point de cohérence. Le gel est limité à 60 secondes maximum, et la création (le commit) par le fournisseur à 10 secondes maximum ; au-delà, la création est annulée et le demandeur recommence.¹ La sauvegarde proprement dite, qui peut durer plusieurs heures, s’exécute sur le cliché instantané en lecture seule ainsi obtenu, pendant que l’application continue de tourner.
2. La lecture reste possible pendant le gel. Seules les E/S d’écriture sont arrêtées.¹
3. Le système de fichiers est lui aussi gelé. VSS vide les tampons du système de fichiers avant de le geler, de sorte que les écritures encore en cache et les métadonnées du système de fichiers se retrouvent reflétées dans le cliché instantané dans un ordre cohérent.¹

4.3. Cohérence après incident et cohérence applicative

C’est ici qu’apparaît une distinction essentielle pour la qualité d’une sauvegarde.

Un cliché instantané créé sans la coopération d’un enregistreur se trouve dans ce que Microsoft appelle un état cohérent après incident (crash consistent). La définition officielle en fait « un état du disque équivalent à celui que l’on trouverait après une panne catastrophique ayant provoqué l’arrêt brutal du système », et la restauration à partir d’un tel état équivaut à « un redémarrage après un arrêt brutal ».³ Le système de fichiers n’est pas endommagé, mais du point de vue de l’application, c’est comme si on avait débranché l’alimentation en pleine écriture. Une base de données dotée d’un mécanisme de récupération par journal des transactions peut souvent s’en remettre, mais cela suppose un traitement de récupération.

Avec la coopération d’un enregistreur, chaque enregistreur roule ses journaux de transactions et vide son cache juste avant le point de cohérence, ce qui aboutit à un état cohérent dont l’application elle-même garantit qu’elle peut correctement en repartir.¹ C’est la cohérence applicative, la raison d’être du mécanisme des enregistreurs. Il faut noter que ce que garantit un enregistreur, c’est « un état cohérent et récupérable du point de vue de l’application » — il ne valide pas de force les transactions en cours pour les faire aboutir. Le travail non validé est annulé (rollback) lors de la restauration, exactement comme dans une récupération de base de données classique. L’enregistreur réalise cette garantie de qualité sans arrêter l’application, au prix d’un simple gel de quelques dizaines de secondes.

Si les logiciels de sauvegarde proposent des options comme « utiliser VSS » ou « garantir la cohérence applicative », c’est le reflet de cette distinction. Pour un simple ensemble de fichiers sur un serveur de fichiers, la cohérence après incident ne pose pratiquement pas de problème ; mais pour un serveur hébergeant une base de données ou un magasin de messagerie, le bon fonctionnement de l’enregistreur correspondant constitue la qualité même de la sauvegarde.

5. La pratique des commandes d’exploitation — vssadmin et les « versions précédentes »

L’outil qui permet de vérifier l’état de VSS dans la pratique informatique est vssadmin (à exécuter dans une invite de commandes en tant qu’administrateur). La référence de commande actuelle indique que list shadows / list writers / delete shadows / resize shadowstorage sont disponibles à la fois côté client et côté serveur.⁴ Les références propres à Windows Server mentionnent en plus create shadow / list shadowstorage / list providers, entre autres.⁵ Notez que vssadmin ne peut administrer que les clichés instantanés créés par le fournisseur système.¹

Si le résultat de list writers montre un enregistreur en état d’erreur, ce n’est pas VSS lui-même qu’il faut suspecter en premier lieu, mais l’application qui fournit cet enregistreur. Vérifiez l’état du service de l’application concernée ainsi que les journaux d’événements Application/Système (chapitre 7).

Pour resize shadowstorage, l’option /maxsize accepte une limite exprimée avec une unité (Ko, Mo, Go, etc.) ; sans elle, la limite devient illimitée. Il faut noter qu’il est explicitement indiqué que la modification de la limite de la zone de stockage (en particulier sa réduction) peut elle-même provoquer la perte de clichés instantanés.¹⁰ Ne réduisez pas à la légère la limite d’un volume dont vous souhaitez conserver les générations.

5.1. Le lien avec les « versions précédentes »

Sur un serveur de fichiers, activer les « clichés instantanés de dossiers partagés (Shadow Copies of Shared Folders) » permet de conserver périodiquement une copie, à un instant donné, des fichiers du partage ; les utilisateurs peuvent alors restaurer, sans l’aide d’un administrateur, un fichier supprimé ou écrasé par erreur, via les « versions précédentes ».¹ C’est l’application la plus familière de VSS, celle qui réduit à coup sûr la charge du support technique.

Il y a cependant des limites. Les clichés instantanés du fournisseur système sont plafonnés à 512 par volume au maximum, dont 64 au maximum conservés par défaut par la fonctionnalité de clichés instantanés de dossiers partagés (modifiable via la clé de registre MaxShadowCopies).¹ Et, comme on le verra dans les chapitres suivants, si la zone de différence vient à manquer, les générations les plus anciennes sont supprimées automatiquement. Il est plus sûr de considérer que « le nombre de générations conservées » n’est pas déterminé par le nombre de générations paramétré, mais par le volume des écritures et la taille de la zone de différence.

6. L’implication du développeur — une application maison a-t-elle besoin de VSS ?

À partir d’ici, place au point de vue du développeur. Quand on vous demande d’ajouter « une fonction de sauvegarde capable de copier même les fichiers en cours d’utilisation », comment aborder VSS ?

6.1. Développer son propre demandeur est un gros chantier

L’API de VSS, aussi bien pour le demandeur que pour l’enregistreur, est fournie sous forme d’interfaces COM et C++ (le cœur du demandeur est IVssBackupComponents).⁶ Aucun wrapper officiel n’est fourni pour .NET, et il faut implémenter correctement la collecte des métadonnées des enregistreurs, la gestion des jeux de clichés instantanés, ainsi que le nettoyage en cas d’erreur : ce n’est pas quelque chose que l’on intègre à la légère comme une simple fonctionnalité d’une application métier. Dans nos devis de développement sous contrat également, « développer un demandeur VSS maison » est traité comme une ligne de développement à part entière.

Deux solutions réalistes existent. La première consiste à s’appuyer sur un logiciel de sauvegarde existant compatible VSS. La seconde, réservée à Windows Server, consiste à piloter DiskShadow depuis un script. DiskShadow est un demandeur VSS fourni avec l’OS ; en plus de son mode interactif, il dispose d’un mode script (diskshadow /s script.txt) qui permet d’écrire, en un seul script, la création du cliché instantané, son exposition sous une lettre de lecteur (expose), l’exécution d’un traitement de copie par lots (exec), puis le nettoyage final.⁷¹ On peut ainsi construire le déroulement « créer le cliché instantané → en extraire les fichiers avec son propre traitement de copie → le supprimer » sans écrire une seule ligne de COM. Toutefois, DiskShadow est réservé à Windows Server et n’est pas inclus dans les OS clients.¹ Si les PC clients font aussi partie du périmètre, cela penche déjà vers l’adoption d’un logiciel de sauvegarde existant.

6.2. VSS est-il seulement nécessaire ? — Tableau de décision

L’expérience montre que la plupart des demandes concernant la « copie de fichiers en cours d’utilisation » se résolvent sans VSS. Évaluez le niveau réel du besoin avant de choisir l’outil.

6.3. Une application maison doit-elle enregistrer un writer ?

Examinons aussi la question inverse : « une application métier maison doit-elle fournir un writer VSS ? » En écrivant un writer, on permet à ses propres données d’être récupérées avec une cohérence applicative, quel que soit le logiciel de sauvegarde utilisé par le client. Il existe aussi un mécanisme plus léger qu’un writer classique, l’express writer (IVssExpressWriter), mais celui-ci se contente d’enregistrer une déclaration de métadonnées — quels fichiers inclure ou exclure.⁶ Comme il ne reçoit pas les notifications de gel/dégel, il ne permet pas de figer les écritures de l’application au moment de la création du cliché instantané. On ne peut recourir à l’express writer que lorsqu’il est associé à une conception de sauvegarde qui ne casse rien même prise en cours d’écriture (la cohérence après incident suffit) ; si une coordination au point de cohérence est nécessaire, un writer classique doit être implémenté.

Cela dit, les critères de décision restent simples.

• Si les données résident dans une base comme SQL Server, ce n’est pas nécessaire. L’enregistreur côté base de données garantit déjà la cohérence.¹
• Pour un simple stockage de fichiers, la solution passe d’abord par la conception du traitement d’enregistrement lui-même. En écrivant intégralement dans un fichier temporaire puis en le substituant par renommage — un enregistrement atomique —, même un cliché instantané pris en cohérence après incident ne laissera jamais de « fichier d’enregistrement corrompu ».
• Envisager l’enregistrement d’un writer ne vaut la peine que pour des applications qui possèdent un magasin de données propriétaire réparti sur plusieurs fichiers et qui nécessitent une cohérence mutuelle au point de cohérence. Il vaut peut-être mieux, avant cela, remettre en question le fait même de conserver des données de cette ampleur dans un format propriétaire.

7. Les pièges — quatre points qui comptent vraiment en exploitation

7.1. VSS n’est pas une sauvegarde en soi

C’est le piège le plus important. Le cliché instantané du fournisseur système est une différence stockée sur le disque de la même machine que les données d’origine. Si la zone de différence est perdue, la recomposition devient impossible : il n’offre donc aucune protection contre une panne de disque, le vol ou la perte de la machine, ou le chiffrement de tout le volume. La documentation Microsoft distingue elle-même clairement le cliché instantané de la sauvegarde : « le contenu copié depuis le cliché instantané vers un support comme une bande constitue la sauvegarde, et le cliché instantané peut être supprimé une fois cette copie effectuée ».¹ Le cliché instantané est un point de cohérence et un moyen de restauration rapide après une erreur de manipulation ; il ne remplace pas une sauvegarde sur un autre support, dans un autre site.

7.2. Une erreur de writer est un problème côté application

Quand un logiciel de sauvegarde échoue avec une « erreur VSS », commencez par identifier, avec vssadmin list writers, quel enregistreur est en échec. L’enregistreur est concrètement un composant fourni par l’application (ou par un composant Windows)¹, donc l’essentiel de l’enquête se joue du côté de l’état du service de l’application concernée et de ses journaux d’événements. Se laisser entraîner par l’apparence d’une « erreur du logiciel de sauvegarde » et ne creuser que ce côté-là fait perdre du temps. La démarche générale de tri, « restreindre les suspects à partir des faits observables », est la même que celle traitée dans « Maintenir un système sans code source ni documentation ».

7.3. Les rançongiciels viennent supprimer les clichés instantanés

C’est un fait à connaître pour la défense. On aimerait croire que, puisque les « versions précédentes » permettent de revenir en arrière, on pourrait aussi s’en servir pour se remettre d’un chiffrement par rançongiciel — mais il est largement documenté que de nombreux rançongiciels suppriment les clichés instantanés avant ou après le chiffrement, précisément pour couper cette voie de restauration. La suppression d’un cliché instantané peut s’effectuer avec une commande parfaitement légitime dès lors que l’on dispose de droits d’administrateur ; ce n’est donc pas le dernier rempart contre un attaquant déjà entré dans le système. L’axe de défense repose donc sur : (1) considérer le cliché instantané non pas comme « un élément du plan de reprise » mais tout au plus comme « pratique s’il est encore là » ; (2) disposer par ailleurs d’une sauvegarde hors ligne, dans un autre site, inaccessible à l’attaquant ; (3) ne pas accorder de droits d’administrateur aux comptes d’exploitation courante. Pour une défense du cycle de vie du PC incluant sauvegarde, chiffrement et mise au rebut, voir aussi « Guide pratique de BitLocker » et « Liste de contrôle pour la mise au rebut d’un PC ».

7.4. Quand la zone de différence est épuisée, les générations les plus anciennes disparaissent silencieusement

Comme on l’a vu au chapitre 4, la copie sur écriture consomme de la zone de différence lorsque chaque bloc est réécrit pour la première fois après la prise du cliché instantané. Réécrire à nouveau un bloc déjà mis de côté n’augmente pas la consommation ; celle-ci ne dépend donc pas du « nombre d’écritures » mais de l’étendue des blocs réécrits depuis les clichés instantanés en cours de conservation. Et une fois la zone de différence à sa limite, les clichés instantanés du volume sont supprimés en commençant par les plus anciens.¹ Comme aucune notification n’est envoyée à l’utilisateur interactif, on ne s’en aperçoit souvent qu’au moment où l’on découvre que « la version de la semaine dernière, censée être récupérable, ne l’est plus ». Ce n’est cependant pas totalement silencieux : le journal Système enregistre des événements de la source volsnap (l’ID 25 lorsque la suppression survient faute d’espace disponible dans la zone de différence, les ID 35/36 lors de l’échec d’une extension ou de l’atteinte de la limite, etc.). En plus des vérifications régulières, surveiller ces événements volsnap et les inclure dans vos alertes permet de détecter rapidement une telle perte. C’est justement parce que la consommation « dépend de l’étendue réécrite » que des opérations qui balaient largement le volume — mises à jour massives de fichiers, conversion en masse, défragmentation — peuvent épuiser la zone de différence d’un coup. Vérifiez régulièrement l’utilisation avec vssadmin list shadowstorage pour vous assurer que le nombre de générations conservées répond au besoin métier (« au bout de combien de jours, au maximum, remarque-t-on une suppression accidentelle ? »), et augmentez la limite si nécessaire.⁵¹⁰

8. Conclusion

• Un fichier en cours d’utilisation ne se copie pas normalement à cause de la violation de partage et du problème de cohérence, un mécanisme légitime destiné à protéger les données. VSS est la réponse au niveau du système d’exploitation au besoin « obtenir une copie cohérente sans arrêter l’application ».
• VSS est un cadre dans lequel le service VSS met en relation trois rôles — le demandeur (la requête), l’enregistreur (la garantie de cohérence) et le fournisseur (la création) —, permettant à un logiciel de sauvegarde et une application métier qui s’ignorent mutuellement de coopérer.
• Le fournisseur système utilise la copie sur écriture, et le point de cohérence est créé selon la séquence « gel des enregistreurs (60 secondes maximum) → création (10 secondes maximum) → dégel ». Sans coopération des enregistreurs, on obtient une cohérence après incident ; avec, une cohérence applicative.
• La vérification en exploitation passe par vssadmin (list shadows / list writers / list shadowstorage). En cas d’erreur d’un enregistreur, suspectez d’abord l’application concernée, et surveillez régulièrement l’utilisation de la zone de différence.
• Le développeur doit d’abord vérifier, à l’aide du tableau de décision, si une nouvelle tentative, un ajustement du mode de partage, un arrêt temporaire ou une conception de liaison peuvent suffire, et ne recourir à VSS que lorsque c’est vraiment nécessaire. Un script DiskShadow (réservé à Server) ou un logiciel existant constituent des solutions plus réalistes qu’une implémentation maison.
• Un cliché instantané n’est pas une sauvegarde. Ce n’est qu’une différence qui dépend des blocs intacts du volume d’origine : elle est impuissante face à la perte du volume d’origine, comme une panne de disque, et n’est pas fiable non plus face à un rançongiciel, qui peut supprimer le cliché instantané ou épuiser la zone de différence. Combinez-la avec une sauvegarde hors ligne, dans un autre site.

Articles connexes

• Les bases du contrôle d’exclusion pour l’échange de fichiers — verrouillage de fichiers et bonnes pratiques du claim atomique
• Les tréfonds des E/S Windows (4e partie) — le gestionnaire de cache : quand votre WriteFile atteint-il vraiment le disque ?
• Les tréfonds des E/S Windows (5e partie) — la structure interne de NTFS : comprendre le système de fichiers à partir de la MFT
• Reprendre un système sans code source ni documentation — la démarche pratique pour l’exploiter et le maintenir sans l’arrêter
• Guide pratique de BitLocker — le chiffrement de disque, en commençant par la gestion des clés de récupération
• Ce qu’il faut faire avant de mettre au rebut un PC Windows — liste de contrôle pratique pour l’effacement des données, la désactivation des comptes et la sauvegarde

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge la conception et le développement d’applications métier incluant une « fonction de copie et de sauvegarde de fichiers en cours d’utilisation », l’investigation des violations de partage liées à l’échange de fichiers et des échecs de sauvegarde (erreurs de writer VSS), ainsi que la mise au point de l’exploitation de la sauvegarde et de la gestion des générations sur les serveurs de fichiers. Vous pouvez nous solliciter dès le stade du tri de « savoir si VSS est seulement nécessaire pour ce besoin ».

• Développement d’applications Windows
• Diagnostic de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Un cliché instantané suffit-il à remplacer une sauvegarde ?

Non, cela ne suffit pas. Le cliché instantané créé par le fournisseur système standard de Windows est une différence issue de la copie sur écriture : il ne conserve pas séparément « une réplique complète à cet instant », mais dépend des blocs non réécrits du volume d'origine. Même en plaçant la zone de différence (diff area) sur un autre volume, la perte du volume d'origine rend toujours la restauration impossible ; le cliché instantané est donc impuissant face à une panne de disque ou au vol/à la perte d'un PC, qui emportent le volume d'origine tout entier. Pour un rançongiciel aussi, bien que l'écriture du chiffrement mette de côté les blocs antérieurs dans la zone de différence, les attaques réelles suppriment le cliché instantané ou épuisent la zone de différence par des réécritures massives, si bien qu'on ne peut pas s'y fier. La documentation Microsoft distingue elle-même clairement les deux : les données copiées du cliché instantané vers un support comme une bande constituent la sauvegarde, et le cliché instantané lui-même peut être supprimé après cette copie. Le cliché instantané est « un point de cohérence pour prendre une sauvegarde » et « un moyen de restauration rapide après une erreur de manipulation mineure », pas un substitut à une sauvegarde sur un autre support, dans un autre site.

Je veux copier des fichiers en cours d'utilisation depuis une application métier maison : dois-je utiliser VSS ?

Le plus réaliste est d'abord de chercher à s'en passer. Le demandeur VSS doit être écrit avec l'API native basée sur COM (IVssBackupComponents, etc.), et aucun wrapper officiel n'est fourni pour .NET : l'intégrer dans une application maison représente donc un travail conséquent. Si le besoin se limite à « pouvoir lire, tôt ou tard, un fichier qu'un autre processus est en train d'écrire », une nouvelle tentative suffit ; s'il se limite à « le partage en lecture est autorisé », ouvrir avec le même mode de partage suffit. Si l'application peut être arrêtée un court instant, copier pendant une pause dans l'activité reste la solution la plus sûre. Seul le besoin de « dupliquer, dans un état cohérent, l'ensemble des données d'une application qui ne peut pas être arrêtée » relève vraiment de VSS, et même dans ce cas, mieux vaut d'abord envisager un logiciel de sauvegarde compatible VSS ou un script DiskShadow plutôt qu'une implémentation maison.

Avec vssadmin list writers, un enregistreur apparaît en état d'erreur. Que faire ?

La base consiste à enquêter du côté de l'application qui fournit cet enregistreur. vssadmin list writers affiche la liste des enregistreurs enregistrés avec leur état ; commencez donc par identifier lequel est en échec. Les enregistreurs sont fournis par des applications comme SQL Server ou par des composants Windows (le Registre, etc.), donc la cause de l'erreur se trouve, dans la plupart des cas, du côté de l'état du service de l'application concernée ou des erreurs consignées dans les journaux d'événements Application/Système, plutôt que dans VSS lui-même. Redémarrez le service concerné, isolez les conditions de reproduction, et si le problème persiste, consultez les informations de support de cette application. C'est également la même démarche à suivre en premier lieu lorsqu'un logiciel de sauvegarde échoue avec une erreur VSS.

Un cliché instantané a disparu sans que je m'en aperçoive. Pourquoi ?

La cause la plus fréquente est le manque d'espace dans la zone de différence (la zone de stockage de cliché instantané). Avec la copie sur écriture, le contenu antérieur à la réécriture est mis de côté dans la zone de différence lors de la première réécriture de chaque bloc après la prise du cliché instantané ; plus l'étendue réécrite est large, plus la zone de différence est consommée. Une fois la limite allouée atteinte, Windows supprime les clichés instantanés les plus anciens pour libérer de l'espace. Comme aucune notification n'est envoyée à l'utilisateur interactif, la disparition passe inaperçue et se découvre souvent seulement au moment où l'on constate que « la version de la semaine dernière, que l'on pensait pouvoir restaurer via les versions précédentes, n'est plus là » (le journal Système enregistre néanmoins des événements de la source volsnap, comme l'ID 25 ; les surveiller permet de s'en apercevoir). Vérifiez l'utilisation et la limite avec vssadmin list shadowstorage, et augmentez la limite si nécessaire avec vssadmin resize shadowstorage. Attention toutefois : la modification de la limite (en particulier sa réduction) peut elle-même provoquer la perte de clichés instantanés.

Quel est le lien entre les « versions précédentes » de l'Explorateur et VSS ?

Les « versions précédentes » sont l'un des points d'accès permettant d'extraire, depuis un cliché instantané créé par VSS, une version passée d'un fichier. Sur un serveur de fichiers, activer les « clichés instantanés de dossiers partagés » (Shadow Copies of Shared Folders) crée périodiquement des clichés instantanés ; les utilisateurs peuvent alors, par un clic droit sur un fichier du dossier partagé, se restaurer eux-mêmes une version précédente. L'avantage est de pouvoir corriger une suppression ou un écrasement accidentel sans l'aide d'un administrateur. Mais comme il s'agit en réalité de clichés instantanés, le nombre de générations conservées a une limite, et si la zone de différence vient à manquer, les générations les plus anciennes disparaissent. Comme indiqué dans le corps de l'article, « avoir des versions précédentes » ne dispense pas d'avoir une sauvegarde.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.