Objectif
Rétablir un état VSS stable pour permettre une sauvegarde cohérente de Windows et de ses applications, en identifiant le writer ou provider réellement défaillant, en contrôlant l’espace de shadow storage et en appliquant la correction minimale avant de relancer le job complet.
Prérequis
- Message exact du logiciel de sauvegarde avec code et heure de l’échec.
- Accès administrateur au serveur et aux journaux Application/System.
- Fenêtre de maintenance si un service applicatif ou le serveur doit être redémarré.
- Espace disque disponible et visibilité sur le shadow storage.
- Sauvegarde ou plan de retour si vous devez modifier provider, stockage VSS ou configuration applicative.
Procédure pas à pas
Collecter l’erreur avant toute relance
Conservez le rapport du job, le code VSS et la phase où la sauvegarde échoue. Notez l’heure à la seconde si possible et ouvrez Event Viewer sur les journaux Application et System autour de cet instant. Recherchez les sources VSS, VolSnap et le writer applicatif. Cette corrélation évite de traiter un événement ancien sans rapport avec le job actuel.
- Le code d’erreur et les événements associés au même créneau sont conservés.
Lister les writers VSS
Exécutez vssadmin list writers et relevez chaque writer dont l’état n’est pas Stable ou dont Last error n’est pas No error. Notez le nom exact et l’ID. Si aucun writer n’est listé, il s’agit d’un symptôme différent qui peut indiquer un composant VSS non enregistré ou une panne plus générale du service.
vssadmin list writers- Les writers défaillants sont identifiés précisément, ou l’absence complète de writers est constatée.
Lister providers, shadows et shadow storage
Contrôlez les providers installés, les shadow copies existantes et les associations de stockage. Un provider tiers peut interagir avec celui de Microsoft. Un shadow storage trop petit ou un volume presque plein peut provoquer l’abandon du cliché. Ne supprimez rien à ce stade : collectez d’abord l’état.
vssadmin list providersvssadmin list shadowsvssadmin list shadowstorage- Les providers et la capacité réservée aux clichés sont connus.
Vérifier l’espace libre des volumes concernés
Contrôlez l’espace du volume sauvegardé et celui qui héberge le shadow storage. Recherchez une croissance récente, des logs, snapshots ou fichiers temporaires. Libérez de l’espace non critique si le volume est proche de la saturation. Évitez de redimensionner arbitrairement le shadow storage sans connaître sa taille actuelle et le besoin du serveur.
Get-Volume | Select-Object DriveLetter,FileSystemLabel,Size,SizeRemaining- Les volumes disposent d’une marge suffisante pour créer un nouveau cliché.
Associer le writer en erreur à son service ou application
Identifiez le composant qui fournit le writer : System Writer, WMI Writer, Hyper-V VSS Writer, SQL Server Writer, etc. Consultez les événements spécifiques de l’application et vérifiez son état de service. Ne redémarrez pas plusieurs services à la fois ; vous perdriez la capacité à identifier la correction réellement efficace.
Get-Service VSS,swprv | Format-Table Name,Status,StartType- Le writer est rattaché à un composant et une cause probable est documentée.
Appliquer la correction minimale
Corrigez le problème identifié : espace, service arrêté, application en erreur, provider défaillant ou composant non enregistré. Si un redémarrage de service est supporté, réalisez-le pendant la fenêtre prévue puis relistez les writers. Si plusieurs writers restent incohérents et qu’aucune cause précise n’est disponible, un redémarrage planifié du serveur peut être plus sûr qu’une série de manipulations VSS destructives.
vssadmin list writers- Les writers reviennent Stable et No error après correction.
Traiter le cas aucun writer listé
Si vssadmin list writers ne retourne aucun writer, consultez les événements VSS et suivez la procédure Microsoft correspondante. Ce cas peut être lié à un composant requis non enregistré et ne se corrige pas en supprimant des snapshots. Vérifiez l’intégrité système et les mises à jour avant de réenregistrer manuellement des composants sur la base de scripts non validés.
sfc /scannowDISM /Online /Cleanup-Image /ScanHealth- Le diagnostic traite l’absence de writers comme un problème distinct.
Tester un petit job ou un cliché contrôlé
Une fois les writers stables, relancez une sauvegarde limitée ou le job concerné pendant une période où vous pouvez observer les événements. Vérifiez que le cliché se crée puis est libéré correctement. Si le job de sauvegarde utilise des composants applicatifs supplémentaires, contrôlez aussi leurs logs avant de déclarer VSS corrigé.
- Le test se termine sans nouvelle erreur VSS.
Relancer le job complet et tester une restauration
Relancez le job complet seulement après le test court. Après succès, restaurez au moins un fichier ou un élément de test pour vérifier que le backup produit est utilisable. Un job marqué Success ne garantit pas à lui seul la cohérence applicative ; conservez le résultat de restauration avec le ticket.
- Le job complet réussit et une restauration test est possible.
Documenter la cause et la prévention
Consignez le writer concerné, le code, la correction et les valeurs d’espace. Si l’incident est récurrent, ajoutez une surveillance de capacité, une mise à jour de l’agent/provider ou une vérification périodique des writers. Évitez les tâches planifiées qui purgent automatiquement tous les clichés en réponse à n’importe quelle erreur.
- La cause et l’action préventive sont intégrées à la documentation d’exploitation.
Validation
La procédure est validée lorsque :
- vssadmin list writers retourne les writers attendus en état Stable sans erreur.
- Le shadow storage et les volumes possèdent une capacité suffisante.
- Un job de test puis le job complet se terminent sans erreur VSS.
- Une restauration de contrôle réussit depuis le backup produit.
Retour arrière
- Restaurer la configuration du shadow storage si elle a été modifiée et documentée avant l’intervention.
- Réactiver les services arrêtés temporairement et vérifier leur mode de démarrage.
- Réinstaller ou réactiver un provider uniquement selon la procédure de son éditeur si sa suppression faisait partie du diagnostic.
- Si les writers restent instables après corrections ciblées, revenir à l’état applicatif précédent ou planifier un redémarrage plutôt que supprimer massivement les clichés.
Dépannage / erreurs fréquentes
- Writer spécifique en Failed : traiter d’abord son application/service et les événements correspondants.
- Tous les writers sont absents : suivre le diagnostic Microsoft du composant VSS non enregistré plutôt qu’une purge de snapshots.
- Writers stables mais job échoue : vérifier provider utilisé, agent de backup, permissions et phase exacte du job.
- Shadow copy échoue faute d’espace : augmenter la marge du volume ou du shadow storage après analyse.
- Erreur revient après quelques heures : rechercher une tâche concurrente, un provider tiers, une application qui laisse le writer incohérent ou une saturation récurrente.