VSS (cliché instantané de volume) : 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 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 traite séparément « le mécanisme qui permet de copier un fichier en cours d’utilisation » et « jusqu’où cette copie protège réellement ». Il 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 métier.

Il commence par la conclusion et un guide de lecture par objectif, puis présente les acteurs de VSS, le mode de conservation, les vérifications en exploitation, les décisions du développeur et les pièges, dans cet ordre. Les explications techniques s’appuient sur des sources primaires à jour au mois d’août 2026.

La série « Les profondeurs de l’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. D’abord la conclusion

VSS est le mécanisme qui fige brièvement les écritures d’une application en coordination avec son rédacteur, afin de prendre une sauvegarde à partir de la copie faite à cet instant. Créer un cliché instantané ne rend pas inutile une sauvegarde sur un autre support.

Que fait ce mécanisme ?

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 coordinateur. Le service VSS met en relation le demandeur (logiciel de sauvegarde) qui réclame le cliché instantané, le rédacteur (SQL Server, etc.) qui garantit la cohérence des données côté application, et le fournisseur qui crée réellement l’instantané.¹

Le point de cohérence est créé selon la séquence « gel des rédacteurs (60 secondes au maximum) → création de l’instantané (en 10 secondes) → dégel ». Si un délai est dépassé, la création est annulée et le demandeur recommence.¹

Séparer le mode de conservation et la garantie de cohérence

Le fournisseur système standard de Windows utilise la copie sur écriture. Plutôt que de dupliquer tout le volume, seuls les blocs réécrits après l’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.¹

La qualité de la copie dépend de la coopération ou non du rédacteur. Un instantané pris sans coopération équivaut au disque à l’instant d’une coupure d’alimentation (cohérence après incident, 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, application consistent).³¹

Exploitation et développement ne vérifient pas les mêmes choses

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, à cause de la suppression des clichés instantanés eux-mêmes (7.3) ou de l’épuisement de 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.¹

Lire selon l’objectif ou le symptôme

Pour comprendre le mécanisme, lisez à partir du chapitre 2 ; pour l’exploitation, les chapitres 5 et 7 ; pour le développement, commencez par le tableau de décision du 6.2.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (26 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

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

Commencer par la raison pour laquelle on ne peut même pas l’ouvrir

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 bogue, 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’intégration par fichiers », est le socle de toute intégration entre applications.

Mais ce mécanisme légitime entre fondamentalement en conflit avec la sauvegarde. Il y a ici trois murs distincts.

Mur 1 : une violation de partage empêche d’ouvrir la source

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.

Mur 2 : même ouvert, le contenu copié n’est pas cohérent

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 la partie consacrée 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. Pouvoir le lire et pouvoir le copier dans un état cohérent sont deux problèmes distincts.

Mur 3 : on ne peut pas arrêter l’application assez longtemps pour copier

« Alors 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 d’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, rédacteur et fournisseur

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

Le logiciel de sauvegarde et l’application se répartissent le travail

L’élégance de cette répartition, c’est que des produits qui ne se connaissent pas peuvent néanmoins coopérer. Un logiciel de sauvegarde (le demandeur) ne connaît pas la structure interne de SQL Server. Il peut pourtant prendre une sauvegarde cohérente grâce à la répartition suivante.¹⁹

1. Le rédacteur SQL Server déclare, sous forme de métadonnées, l’ensemble des fichiers (les composants) qui doivent être sauvegardés.
2. Le rédacteur met ses propres données en ordre avant et après la création du point de cohérence.
3. Le demandeur prend la sauvegarde selon cette déclaration et cette coopération.

Presque tous les logiciels de sauvegarde tiers qui s’exécutent sous Windows sont des demandeurs VSS.¹

En cas d’échec, les trois rôles indiquent où chercher

Le moment où les trois rôles comptent le plus dans le travail quotidien de l’informatique, c’est le dépannage. Selon qu’un échec de sauvegarde est un problème du demandeur (le logiciel), d’un rédacteur précis (l’application), ou du fournisseur et de la zone de différence (l’infrastructure), l’endroit où l’on cherche change complètement (chapitres 5 et 7).

4. Le fonctionnement des instantanés — copie sur écriture et point de cohérence

4.1. Copie sur écriture — conserver cet instant sans dupliquer le volume

Seuls les blocs antérieurs à la réécriture sont mis de côté

Le mot « instantané » évoque une copie de tout le volume, mais ce que le fournisseur système standard de Windows utilise, c’est la copie sur écriture (copy-on-write). Au moment de la création de l’instantané, presque rien n’est copié.

Ensuite, lorsqu’un bloc du volume d’origine est sur le point d’être réécrit, le bloc antérieur à la réécriture est mis de côté dans la zone de différence (diff area, zone de stockage des clichés instantanés) avant que la réécriture ne s’achève, et ce n’est qu’alors que l’écriture est laissée passer.¹ La mise de côté n’est nécessaire qu’à la première réécriture de chaque bloc ; réécrire un bloc déjà mis de côté n’agrandit pas la zone de différence.

À la lecture, on combine le volume d’origine et la zone de différence

Pour lire le volume tel qu’il était à cet instant, les blocs inchangés se lisent depuis le volume d’origine et les blocs changés depuis la zone de différence, puis les deux sont combinés. Comme on ne copie que ce qui a changé, la création est instantanée et l’espace consommé n’est que la différence.

L’envers de la médaille, c’est que plus un volume est écrit, plus la zone de différence se consomme vite. Ce qui détermine la consommation est traité en détail au 7.4. La zone de différence est placée sur un volume NTFS de la même machine que les données d’origine.¹

Ce qui fait fonctionner tout cela, ce sont swprv.dll, le fichier de composant du fournisseur système, et volsnap.sys, le pilote qui s’intercale dans les E/S de volume.¹ Si la façon dont les choses s’intercalent dans la pile d’E/S vous intéresse, voir aussi « Pilotes filtres et minifiltres ».

Il existe d’autres méthodes : la copie complète, qui détache un miroir, et la redirection à l’écriture (redirect-on-write), qui écrit les modifications sur un autre volume. Les fournisseurs matériels utilisent la méthode la mieux adaptée côté baie de stockage.¹

4.2. Le flux du point de cohérence — 60 secondes pour geler, 10 secondes pour créer

Si la copie sur écriture est « comment on conserve », le vrai apport de VSS est « quel instant on conserve », c’est-à-dire la façon de créer le point de cohérence. La création d’un cliché instantané avance selon le flux suivant.¹

flowchart TB
    R["Le demandeur demande la création<br/>énumère les rédacteurs et collecte les métadonnées"] --> M["Chaque rédacteur déclare ses cibles de sauvegarde<br/>(composants) en XML"]
    M --> P["Chaque rédacteur prépare ses données<br/>roulement des journaux, vidage des caches, etc.<br/>vers un état cohérent récupérable"]
    P --> F["Gel des E/S d'écriture des rédacteurs<br/>(les lectures restent possibles, 60 s au maximum)"]
    F --> FS["VSS vide les tampons du système de fichiers<br/>et fige le système de fichiers"]
    FS --> C["Le fournisseur crée le cliché instantané<br/>(en 10 s, E/S d'écriture figées pendant ce temps)"]
    C --> T["Système de fichiers libéré → dégel (thaw) des rédacteurs<br/>les applications reprennent d'écrire"]
    T --> B["Le demandeur prend la sauvegarde depuis le<br/>cliché instantané, au rythme qui lui convient"]

Figure 1 : Le flux de création d’un cliché instantané. Seules quelques secondes à quelques dizaines de secondes sont figées ; la sauvegarde elle-même s’exécute contre l’instantané.

Le temps d’arrêt et le temps de sauvegarde sont distincts

Trois points à retenir.

1. L’application ne s’arrête que le temps de créer le point de cohérence. Le gel est plafonné à 60 secondes et la création (commit) par le fournisseur à 10 secondes ; si l’un ou l’autre est dépassé, la création est annulée et le demandeur recommence.¹ La sauvegarde elle-même, qui peut durer des heures, s’exécute contre le cliché instantané en lecture seule une fois celui-ci terminé, pendant que l’application continue de tourner.
2. Les lectures restent possibles pendant le gel. Seules les E/S d’écriture s’arrêtent.¹
3. Le système de fichiers est figé lui aussi. VSS vide les tampons du système de fichiers avant de le figer, de sorte que les écritures qui se trouvaient dans le cache et les métadonnées du système de fichiers se reflètent dans l’instantané dans un ordre cohérent.¹

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

Voici la distinction qui sépare une bonne sauvegarde d’une mauvaise.

Sans rédacteur : le même état que lors d’une récupération après un arrêt brutal

Un cliché instantané créé sans la coopération d’un rédacteur est, dans la terminologie Microsoft, un état cohérent après incident (crash consistent). La définition officielle est « un état de disque équivalent à celui que l’on trouverait après une panne catastrophique qui arrête brusquement le système », et la restauration à partir de cet état est « équivalente à un redémarrage après un arrêt brutal ».³ Le système de fichiers n’est pas cassé, mais du point de vue de l’application, c’est l’instant où l’on a tiré le cordon d’alimentation en pleine écriture. Une base de données dotée d’un mécanisme de récupération à partir du journal des transactions peut souvent récupérer, mais le traitement de récupération est une condition préalable.

Avec un rédacteur : l’application prépare un état cohérent récupérable

Avec la coopération d’un rédacteur, chaque rédacteur roule ses journaux de transactions et vide ses caches juste avant le point de cohérence, mettant les données dans un état cohérent que l’application elle-même garantit pouvoir récupérer correctement.¹ C’est la cohérence applicative, et c’est la raison d’être du mécanisme de rédacteur.

Attention : ce qu’un rédacteur garantit, c’est un état cohérent et récupérable du point de vue de l’application ; il ne valide pas de lui-même les transactions en cours pour les mener à terme. Le travail non validé est annulé (rollback) à la restauration (le même comportement que la récupération ordinaire d’une base de données). Le rédacteur apporte cette garantie de qualité sans arrêter l’application, en n’utilisant qu’un gel de quelques dizaines de secondes.

Les logiciels de sauvegarde proposent des options du type « utiliser VSS » ou « garantir la cohérence applicative » précisément à cause de cette distinction. Pour de simples fichiers sur un serveur de fichiers, la cohérence après incident pose rarement problème ; en revanche, sur un serveur qui héberge une base de données ou un magasin de courrier, la santé du rédacteur correspondant est la qualité de la sauvegarde.

5. Commandes d’exploitation en pratique — vssadmin et les versions précédentes

L’outil pour vérifier l’état de VSS dans le travail quotidien de l’informatique est vssadmin. Exécutez-le depuis une invite de commandes élevée. Dressez d’abord la liste de l’état actuel, et ne changez la limite de la zone de différence qu’après avoir confirmé à la fois le besoin et le risque de perdre des copies.

Ce que l’on peut vérifier, et quelles commandes sont disponibles

La référence de commandes actuelle présente list shadows / list writers / delete shadows / resize shadowstorage comme disponibles à la fois sur client et sur serveur.⁴ La référence Windows Server documente en plus create shadow / list shadowstorage / list providers et d’autres.⁵ Notez que vssadmin ne peut gérer que les clichés instantanés créés par le fournisseur système.¹

Distinguer les commandes de vérification d’état de celle qui change la limite

Si list writers montre un rédacteur en état d’erreur, le suspect n’est pas VSS lui-même mais l’application qui fournit ce rédacteur. Vérifiez l’état du service de l’application concernée et les journaux d’événements Application et Système (chapitre 7).

Traiter le changement de limite à part des vérifications

Le /maxsize de resize shadowstorage prend une limite avec une unité telle que KB, MB ou GB ; s’il n’est pas spécifié, il n’y a pas de limite. Ce qui compte, c’est l’avertissement documenté selon lequel changer la limite de stockage, et la réduire en particulier, 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 voulez conserver les générations.

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

Activer les clichés instantanés des dossiers partagés (Shadow Copies of Shared Folders) sur un serveur de fichiers conserve, selon un calendrier, des copies à un instant donné des fichiers du partage, et les utilisateurs peuvent restaurer un fichier qu’ils ont supprimé ou écrasé depuis les versions précédentes sans l’aide d’un administrateur.¹ C’est l’application la plus accessible de VSS, et un moyen fiable de réduire la charge du support.

Il y a toutefois des limites. Un cliché instantané du fournisseur système est plafonné à 512 par volume, et parmi ceux-ci, les clichés instantanés des dossiers partagés n’en conservent que 64 par défaut (modifiable via la valeur de Registre MaxShadowCopies).¹

Et, comme les sections suivantes l’expliquent, les générations les plus anciennes sont supprimées automatiquement si la zone de différence vient à manquer. Il est plus sûr de comprendre que le nombre de générations qui survivent n’est pas décidé par le nombre que l’on a configuré, mais par le volume d’écritures et la taille de la zone de différence.

6. Comment le développeur doit s’impliquer — votre application a-t-elle besoin de VSS ?

À partir d’ici, le point de vue est celui du développeur. Lorsqu’on vous demande d’ajouter une fonction de sauvegarde capable de copier des fichiers même pendant qu’ils sont utilisés, comment s’impliquer avec VSS ?

Servez-vous d’abord du tableau de décision du 6.2 pour déterminer si VSS est réellement nécessaire, et seulement ensuite choisissez une implémentation. Le 6.1 concerne le demandeur, le côté qui demande une copie ; le 6.3 concerne le rédacteur, le côté qui permet à quelqu’un d’autre de sauvegarder les données de votre propre application.

6.1. Écrire son propre demandeur est un gros chantier

L’API VSS est fournie sous forme d’interfaces COM et C++ pour les demandeurs comme pour les rédacteurs (IVssBackupComponents est le centre du côté demandeur).⁶ Aucun wrapper officiel n’est fourni pour .NET, et il faut implémenter correctement la collecte des métadonnées des rédacteurs, la gestion du jeu d’instantanés et le nettoyage après erreur : ce n’est pas quelque chose que l’on ajoute à la légère comme une fonction d’une application métier. Dans nos propres devis de Custom Software Development, « écrire un demandeur VSS » est traité comme un poste de développement distinct.

Regarder d’abord un logiciel existant, ou DiskShadow sur Windows Server

Il y a deux réponses pratiques. Premièrement, laisser faire un logiciel de sauvegarde déjà compatible VSS. Deuxièmement, sur Windows Server, piloter DiskShadow depuis un script.

DiskShadow est un demandeur VSS livré avec le système. Outre un mode interactif, il a un mode script (diskshadow /s script.txt), de sorte que la création du cliché instantané, l’exposition sous une lettre de lecteur (expose), l’exécution d’un lot qui effectue la copie (exec), et le nettoyage peuvent tous s’écrire dans un seul script.⁷¹ On peut assembler le flux « créer un cliché instantané → en extraire les fichiers avec sa propre routine de copie → le supprimer » sans écrire une seule ligne de COM.

Cependant, DiskShadow est réservé à Windows Server et n’est pas inclus dans les éditions cliente du système.¹ Si des PC clients font aussi partie du périmètre, cela suffit à faire pencher la décision vers un produit de sauvegarde existant.

6.2. VSS est-il même nécessaire ? — Un tableau de décision

D’après notre expérience, la plupart des demandes de copie de fichiers en cours d’utilisation se résolvent sans VSS. Déterminez le niveau du besoin avant de choisir l’outil.

6.3. Votre application doit-elle enregistrer un rédacteur ?

Il faut aussi traiter la question dans l’autre sens : une application métier que vous avez écrite doit-elle fournir un rédacteur VSS ? Si vous en écrivez un, les données de votre application pourront être sauvegardées en cohérence applicative, quel que soit le produit de sauvegarde utilisé par le client.

Un rédacteur express ne fige pas les écritures

Il existe aussi un mécanisme plus léger qu’un rédacteur complet, le rédacteur express (IVssExpressWriter), mais tout ce qu’il fait, c’est enregistrer une déclaration de métadonnées sur les fichiers à inclure et ceux à exclure.⁶

Comme il ne reçoit pas les notifications telles que gel et dégel, il ne peut pas figer les écritures de l’application en cadence avec la création de l’instantané. Un rédacteur express n’est approprié qu’aux côtés d’une conception de sauvegarde qui ne casse pas lorsqu’elle est capturée en cours d’écriture, c’est-à-dire pour laquelle la cohérence après incident suffit. Si une coopération au point de cohérence est requise, une implémentation de rédacteur complète est nécessaire.

Décider si vous avez besoin de votre propre rédacteur d’après la façon dont vous stockez les données

Le critère est simple.

• Vous n’en avez pas besoin si vos données vivent dans une base telle que SQL Server. Le rédacteur de la base garantit la cohérence.¹
• Pour un stockage de fichiers simple, résolvez d’abord le problème dans la conception de la routine de sauvegarde. Si vous écrivez dans un fichier temporaire et le substituez par un renommage, de sorte que la sauvegarde soit atomique, même un instantané cohérent après incident ne laissera jamais derrière lui un fichier de sauvegarde cassé.
• N’envisager d’enregistrer un rédacteur n’a de sens que pour les applications qui tiennent un magasin de données personnalisé réparti sur plusieurs fichiers et ont besoin que ces fichiers soient cohérents entre eux au point de cohérence. Avant cela, il peut valoir la peine de se demander si l’on devrait vraiment tenir autant de données dans son propre format.

7. Pièges — quatre qui comptent vraiment en exploitation

Vérifiez non seulement si l’on a créé un point de cohérence, mais aussi s’il survivra et s’il est d’une qualité dont on peut restaurer. Les quatre points suivants doivent être considérés séparément en exploitation.

7.1. VSS n’est pas une sauvegarde en soi

C’est le piège le plus important. Un cliché instantané du fournisseur système est une différence sur le disque de la même machine que les données d’origine. Ce n’est pas une réplique complète séparée : les lectures combinent les blocs non encore réécrits du volume d’origine avec la zone de différence.

Pour cette raison, il ne peut pas couvrir les événements qui emportent le volume d’origine, comme une panne de disque ou une machine volée ou perdue. Placer seulement la zone de différence sur un autre volume ne change pas cette dépendance. Et si la zone de différence elle-même est perdue, la combinaison n’est plus possible non plus.

On ne peut pas non plus s’appuyer sur les clichés instantanés face à un rançongiciel qui chiffre tout le volume. Les écritures effectuées pendant le chiffrement mettent bien de côté le contenu antérieur, mais dans une attaque réelle ils sont perdus par la suppression des clichés instantanés ou par l’épuisement de la zone de différence sous l’effet de réécritures massives. Les sections 7.3 et 7.4 traitent de ce point.

La documentation Microsoft trace aussi une ligne claire entre un cliché instantané et une sauvegarde : la sauvegarde, c’est ce qui a été copié du cliché instantané vers un support comme une bande, et le cliché instantané peut être supprimé une fois la copie faite.¹ Un cliché instantané est un point de cohérence et un moyen rapide de se remettre d’une erreur. Ce n’est pas un substitut à une sauvegarde sur un autre support, dans un autre site.

7.2. Les erreurs de rédacteur sont des problèmes côté application

Lorsqu’un logiciel de sauvegarde échoue avec une erreur VSS, vérifiez dans l’ordre suivant.

1. Identifiez quel rédacteur est en échec avec vssadmin list writers.
2. Vérifiez l’état du service de l’application ou du composant Windows qui fournit ce rédacteur.
3. Consultez les journaux d’événements Application et Système et enquêtez sur la cause du côté de l’application concernée.

Un rédacteur est, en substance, un composant du côté de l’application (ou d’un composant Windows).¹ Se laisser entraîner par l’apparence d’une erreur du logiciel de sauvegarde et continuer à n’enquêter que du côté du produit de sauvegarde, c’est le chemin le plus long. La démarche générale pour isoler une panne suit le schéma « réduire les suspects à partir des faits observables » traité dans « Quand vous héritez d’un système sans code source ni documentation ».

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

C’est un fait que les défenseurs doivent connaître. Si les versions précédentes peuvent ramener un fichier en arrière, on a naturellement envie de croire que des fichiers chiffrés par un rançongiciel peuvent l’être aussi — mais il est largement connu que beaucoup de rançongiciels suppriment les clichés instantanés avant ou après le chiffrement, précisément pour fermer cette voie de récupération. La suppression d’un cliché instantané peut s’effectuer avec des commandes légitimes dès lors que l’appelant a des droits d’administrateur, donc ce n’est pas une dernière ligne de défense contre un attaquant déjà à l’intérieur. La réponse repose donc sur trois points.

• Traiter les clichés instantanés non comme une partie du plan de récupération mais comme un plus s’ils survivent.
• Conserver une sauvegarde hors ligne, hors site, distincte, à laquelle un attaquant ne peut pas accéder.
• Ne pas donner de droits d’administrateur aux comptes utilisés pour le travail quotidien.

Pour la défense de tout le cycle de vie du PC, y compris sauvegardes, chiffrement et mise au rebut, voir aussi « Guide pratique de BitLocker » et « Liste de contrôle avant mise au rebut d’un PC ».

7.4. Quand la zone de différence s’épuise, les générations les plus anciennes disparaissent silencieusement

La consommation se décide par l’étendue, pas par le nombre d’écritures

Comme le chapitre 4 l’a montré, la copie sur écriture consomme la zone de différence lorsque chaque bloc est réécrit pour la première fois après la prise de l’instantané. Réécrire un bloc déjà mis de côté, quel que soit le nombre de fois, n’ajoute rien, donc la consommation n’est pas déterminée par le nombre d’écritures mais par quelle étendue de blocs a été réécrite depuis les instantanés que l’on conserve.

Confirmer aussi les générations perdues dans le journal Système

Lorsque la zone de différence atteint sa limite, les clichés instantanés de ce volume sont supprimés en commençant par les plus anciens.¹ Rien n’est signalé aux utilisateurs interactifs, donc cela tend à n’apparaître que lorsque « nous devrions pouvoir revenir à la version de la semaine dernière » se révèle faux. Ce n’est toutefois pas complètement silencieux : des événements de la source volsnap sont enregistrés dans le journal Système (événement 25 lorsqu’une copie a été supprimée parce que la zone de différence n’a pas pu être assurée, et événements 35 et 36 lorsque l’extension a échoué ou que l’opération a été interrompue à l’atteinte de la limite, entre autres). En plus des vérifications périodiques, inclure ces événements volsnap dans la surveillance et les alertes permet de remarquer une perte immédiatement.

Comparer la conservation dont on a besoin à l’utilisation de la zone de différence

Les opérations qui balayent une large partie du volume, comme les mises à jour massives de fichiers, les conversions par lots ou la défragmentation, mangent la zone de différence d’un coup précisément à cause de ce comportement décidé par l’étendue réécrite.

Vérifiez périodiquement, avec vssadmin list shadowstorage, si les générations conservées satisfont l’exigence métier (au plus tard combien de jours après s’aperçoit-on d’une suppression accidentelle), et augmentez la limite si nécessaire.⁵¹⁰

8. Synthèse

VSS se retient plus facilement si on le découpe en trois questions : ce que l’on met en ordre, comment on le conserve, et comment on l’exploite.

Qu’est-ce que l’on met en ordre : un point de cohérence, même en cours d’utilisation

Un fichier en cours d’utilisation ne peut pas être copié normalement à cause des violations de partage et de la cohérence, et c’est le mécanisme légitime pour protéger les données. VSS est la réponse, au niveau du système d’exploitation, à « nous voulons une copie cohérente sans arrêter ».

VSS est un cadre dans lequel le service VSS met en relation trois rôles — demandeur (requête), rédacteur (garantie de cohérence) et fournisseur (création) — afin que des logiciels de sauvegarde et des applications métier qui ne se connaissent pas puissent coopérer.

Comment on le conserve : créer vite un point de cohérence, puis sauvegarder à part

Le fournisseur système utilise la copie sur écriture, et le point de cohérence est créé par « gel des rédacteurs (60 secondes au maximum) → création (en 10 secondes) → dégel ». Sans coopération du rédacteur, on obtient une cohérence après incident ; avec elle, une cohérence applicative.

Un cliché instantané n’est pas une sauvegarde. Ce n’est rien de plus qu’une différence qui dépend des blocs intacts du volume d’origine ; il est impuissant face à la perte du volume d’origine dans une panne de disque, et on ne peut pas s’y fier face à un rançongiciel, à cause de la suppression des clichés instantanés et de l’épuisement de la zone de différence. Combinez-le à une sauvegarde hors ligne, hors site.

Comment on l’exploite : vérifier l’état, et ne s’impliquer que dans la mesure nécessaire

Pour l’exploitation, vérifiez avec vssadmin (list shadows / list writers / list shadowstorage). Pour les erreurs de rédacteur, suspectez le côté application, et surveillez régulièrement l’utilisation de la zone de différence.

Les développeurs doivent d’abord se servir du tableau de décision pour confirmer si de nouvelles tentatives, les modes de partage, une fenêtre d’arrêt ou une conception d’intégration résolvent le problème, et ne se tourner vers VSS que lorsqu’il est vraiment nécessaire. Un script DiskShadow (Server uniquement) ou un logiciel existant est une réponse plus pratique qu’une implémentation maison.

Articles connexes

• Les bases du contrôle d’exclusion pour l’intégration par fichiers - bonnes pratiques de verrouillage de fichiers et de claim atomique
• Les profondeurs de l’E/S Windows (partie 4) — Le gestionnaire de cache : quand votre WriteFile atteint-il vraiment le disque ?
• Les profondeurs de l’E/S Windows (partie 5) — Structure interne de NTFS : comprendre le système de fichiers à travers la MFT
• Quand vous héritez d’un système sans code source ni documentation — Procédure pratique pour l’exploiter et le maintenir sans interruption
• Guide pratique de BitLocker — Le chiffrement de disque en partant de la gestion de la clé 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éconnexion des comptes et les sauvegardes

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception et le développement d’applications métier qui incluent la copie et la sauvegarde de fichiers en cours d’utilisation, l’investigation des causes de violations de partage autour de l’intégration par fichiers et des échecs de sauvegarde (erreurs de rédacteur VSS), et la mise en ordre de l’exploitation des sauvegardes de serveurs de fichiers et de la gestion des générations. Commencer par la question de savoir si VSS est même adapté au besoin convient parfaitement.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Nous contacter

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. Les clichés instantanés créés par le fournisseur système standard de Windows sont des différences en copie sur écriture : ils ne conservent pas à part une réplique complète à cet instant, et dépendent des blocs non réécrits du volume d'origine. Même si l'on place la zone de différence (diff area) sur un autre volume, rien ne peut être restauré une fois le volume d'origine perdu ; le cliché instantané est donc impuissant face à une panne de disque ou au vol ou à la perte d'un PC, qui emportent le volume d'origine tout entier. Pour un rançongiciel aussi, les écritures du chiffrement mettent bien de côté les blocs antérieurs dans la zone de différence, mais les attaques réelles suppriment les clichés instantanés ou épuisent la zone de différence par des réécritures massives : on ne peut pas s'y fier. La documentation Microsoft distingue elle-même les deux : la sauvegarde, ce sont les données copiées du cliché instantané vers un support comme une bande, et le cliché instantané lui-même peut être supprimé après cette copie. Un 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. Ce n'est 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 ; si le partage en lecture est autorisé, ouvrir avec un mode de partage correspondant 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 rédacteur apparaît en état d'erreur. Que faire ?

La base consiste à enquêter du côté de l'application qui fournit ce rédacteur. vssadmin list writers affiche la liste des rédacteurs enregistrés avec leur état ; commencez donc par identifier lequel est en échec. Les rédacteurs 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 et 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 des clichés instantanés). 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 des 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.