Restauration du système ne fonctionne pas ? Réparez-la avant d’en avoir besoin

Cet article vous a aidé ?

La restauration du système est censée être la ceinture de sécurité. Vous ne la remarquez pas jusqu’au jour où vous freinez brutalement — mauvais pilote de périphérique, tweak du registre cassé, antivirus qui décide que votre chargeur d’amorçage est « suspect », choisissez votre poison.

Quand la restauration du système est cassée, vous n’obtiendrez pas un avertissement poli. Vous aurez un point de restauration qui échoue à 3 % avec une erreur vague, ou pire : aucun point de restauration du tout. Ce n’est pas une fonctionnalité ; c’est une dette technique qui accumule des intérêts.

Ce qu’est vraiment la restauration du système (et ce qu’elle n’est pas)

La restauration du système n’est pas une « sauvegarde ». C’est un mécanisme d’annulation pour un sous-ensemble de l’état système : les ruches du registre, les fichiers système, certains pilotes et certaines configurations d’applications. Elle repose sur le Volume Shadow Copy Service (VSS) et un ensemble de filtres et d’écrivains qui coordonnent les instantanés.

Voici ce qu’elle fait bien :

  • Annuler des changements problématiques comme l’installation d’un pilote, une mise à jour Windows qui casse le démarrage, ou des modifications du registre qui empêchent la connexion.
  • Agir rapidement comparé à l’imagerie complète d’un disque — quand elle fonctionne.
  • Vous sauver de vous-même quand vous avez fait « un petit changement » à 16h59 le vendredi.

Voici ce qu’elle fait mal — ou pas du tout :

  • Récupérer vos documents de façon fiable. Elle n’est pas destinée à la protection des données utilisateur.
  • Protéger contre une défaillance disque. Les points de restauration sur le même disque physique que Windows ne constituent pas un plan de reprise après sinistre.
  • Garantir la cohérence de tout. Les applications doivent fournir des écrivains compatibles VSS ; certaines ne le font pas.

La restauration du système est comme un extincteur : peu coûteuse, utile, et souvent périmée quand vous tirez sur la goupille.

Idée paraphrasée (attribuée) : Werner Vogels (CTO d’Amazon) promeut depuis longtemps l’état d’esprit « tout échoue » — concevoir et exploiter en supposant des pannes, et pratiquer la récupération comme si c’était une fonctionnalité.

Guide de diagnostic rapide (premier/deuxième/troisième)

Si vous êtes sous pression temporelle, ne vous égarez pas. Les problèmes de restauration du système se résument généralement à la configuration, la santé VSS ou la pression sur le stockage. Vérifiez dans cet ordre :

Premier : les points de restauration sont-ils même possibles sur cette machine ?

  1. Protection du système activée sur le volume OS ?
  2. Stockage shadow alloué (pas zéro, pas microscopique) ?
  3. Espace disque libre raisonnable (règle empirique : 10 % libres sur C:)?

Si une réponse est « non », corrigez cela d’abord. Ne touchez pas encore aux services.

Deuxième : VSS fonctionne-t-il actuellement ?

  1. Écrivains VSS stables (pas d’écrivains en échec) ?
  2. Services requis en cours (VSS, Microsoft Software Shadow Copy Provider, RPC) ?
  3. Erreurs VSS récentes dans l’Observateur d’événements (en particulier 8193, 12289, 13, 11) ?

Si des écrivains échouent, vous dépannez des dépendances (permissions COM, conflits de fournisseur, services cassés).

Troisième : quelque chose supprime ou invalide les points de restauration ?

  1. Outils de nettoyage de disque / suites « optimiseurs » / AV tiers qui font des choses « utiles » ?
  2. Dual-boot ou accès disque hors ligne (Linux/WinPE montant NTFS peut purger les instantanés) ?
  3. Mises à niveau de fonctionnalité ou workflows de réimagerie qui effacent le stockage shadow ?

Les points de restauration qui disparaissent fonctionnent souvent « comme prévu » sous pression de stockage — ou fonctionnent « comme commercialisé » par un outil de nettoyage.

Faits et historique intéressants (les parties qui comptent)

  • La restauration du système est apparue pour la première fois dans Windows ME (2000), et elle y a gagné sa réputation. L’implémentation moderne est meilleure, mais les mèmes persistent.
  • VSS est arrivé à l’époque de Windows XP/Server 2003 pour coordonner des instantanés cohérents entre applications et composants de système de fichiers.
  • Les points de restauration utilisent des instantanés VSS, mais tous les instantanés VSS ne sont pas des points de restauration ; de nombreux produits (sauvegarde, imagerie) créent aussi des instantanés.
  • Les points de restauration sont soumis à un budget de stockage. Quand le quota du stockage shadow est atteint, Windows supprime les points plus anciens sans demander.
  • Certaines mises à niveau Windows désactivent ou réinitialisent la protection du système selon l’édition, la politique ou les changements de configuration disque.
  • Le dual-boot avec d’anciennes versions de Windows faisait disparaître les points de restauration car l’autre OS ne comprenait pas les métadonnées d’instantané.
  • VSS a des « écrivains » par application/composant. SQL Server, Hyper-V et d’autres fournissent des écrivains pour que les instantanés soient cohérents.
  • Il peut y avoir plusieurs « fournisseurs » VSS. Microsoft en fournit un ; des fournisseurs tiers provenant d’éditeurs de stockage/sauvegarde peuvent s’y ajouter — et des conflits surviennent.
  • La restauration du système ne revient pas de tout de façon fiable. Les paramètres de firmware, certains changements côté pilote bas niveau et les données utilisateur ne relèvent pas de sa responsabilité.

Comment la restauration du système échoue en pratique

1) La fonctionnalité est désactivée (silencieusement)

Sur de nombreuses flottes, la protection du système est désactivée par politique, par défaut d’image ou par un réglage « réduire l’amplification d’écriture » bien intentionné. Les utilisateurs supposent que les points de restauration existent parce que l’UI est là. C’est comme supposer que vous avez une assurance santé parce que vous avez un portefeuille.

2) Le stockage shadow est trop petit, donc les points de restauration tournent

Windows a besoin d’espace pour les instantanés. Si la taille maximale du stockage shadow est minuscule (ou mal configurée), des points de restauration sont créés puis rapidement supprimés. Symptômes : « Je jure que j’avais un point de restauration hier. » Vous en aviez un. Il a été expulsé.

3) Les écrivains VSS sont cassés ou bloqués

Un écrivain VSS en échec bloque la création d’instantanés. Coupables fréquents : Windows Update dans un état bizarre, services d’applications défaillants, permissions de sécurité COM ou VSS lui-même bloqué.

4) Le disque est défaillant ou le système de fichiers est corrompu

Si NTFS renvoie des erreurs, VSS ne vous rendra pas service. De plus : les erreurs de stockage se déguisent souvent en « bizarreries Windows aléatoires ».

5) Le logiciel de sécurité ou les outils de « nettoyage » suppriment les points de restauration

Certaines suites endpoint et outils d’optimisation traitent les copies shadow comme des « déchets ». Ce ne sont pas des déchets. Ce sont une couche d’annulation bon marché. Si votre outil les supprime, votre outil est le problème.

6) La restauration réussit… et rien ne change

La restauration du système peut se terminer sans résoudre le problème réel — parce que l’échec n’entrait pas dans le périmètre que la restauration peut annuler (par ex. chiffrement disque, firmware, certaines piles de pilotes). Elle ne ment pas ; elle a des limites.

Blague #1 : La restauration du système est comme un parachute — quand vous découvrez qu’il est mal plié, vous êtes déjà en train d’avoir une journée excitante.

Tâches pratiques : 12+ vérifications avec commandes, sorties et décisions

Les tâches ci-dessous supposent que vous exécutez une invite de commandes élevée ou PowerShell (en tant qu’administrateur). J’utilise des commandes compatibles CMD quand c’est possible. L’objectif n’est pas de mémoriser la syntaxe ; c’est de construire une boucle de diagnostic répétable.

Task 1: Confirm System Protection configuration (quick reality check)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerRestorePoint | Select-Object -First 5 | Format-Table -AutoSize"
SequenceNumber Description                    CreationTime
-------------- -----------                    ------------
117            Windows Update                 1/29/2026 2:14:52 PM
116            Installed Driver               1/28/2026 9:01:10 AM

Ce que cela signifie : Si vous voyez des entrées, la restauration du système a créé des points de restauration récemment.

Décision : Si c’est vide, soit la protection est désactivée, soit les points sont supprimés, soit la création échoue. Poursuivez avec les vérifications de stockage et VSS.

Task 2: Check if protection is enabled per drive

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root/default -ClassName SystemRestoreConfig | Select-Object Drive,Enabled"
Drive Enabled
----- -------
C:\      True

Ce que cela signifie : La protection peut être activée/désactivée par volume.

Décision : Si C:\ est False, activez-la (voir section listes de contrôle) puis créez un point de restauration de test.

Task 3: Check shadow storage allocation and usage

cr0x@server:~$ vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{2f3f...}\
   Shadow Copy Storage volume: (C:)\\?\Volume{2f3f...}\
   Used Shadow Copy Storage space: 4.112 GB (3%)
   Allocated Shadow Copy Storage space: 6.000 GB (4%)
   Maximum Shadow Copy Storage space: 10.000 GB (7%)

Ce que cela signifie : Les points de restauration résident ici. Si le maximum est minuscule ou « UNBOUNDED » sur un petit disque, vous aurez des problèmes dans les deux cas.

Décision : Si le max est inférieur à ~5–10 GB sur un disque OS typique, augmentez-le. Si l’utilisation est proche du max, les points plus anciens vont tourner — augmentez-le aussi ou libérez de l’espace.

Task 4: Verify you have enough free disk space

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Name,Used,Free | Format-Table -AutoSize"
Name         Used          Free
----         ----          ----
C    203.41GB      12.58GB

Ce que cela signifie : 12.58 GB libres sur un disque de 256 GB est vivre dangereusement pour les mises à jour Windows et les copies shadow.

Décision : Si l’espace libre est faible, traitez cela comme l’incident principal. Libérez de l’espace avant de dépanner VSS ; VSS se comporte mal sous pression.

Task 5: List VSS writers and look for failures

cr0x@server:~$ vssadmin list writers
Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {9f6c...}
   State: [1] Stable
   Last error: No error

Writer name: 'WMI Writer'
   Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
   Writer Instance Id: {f1a2...}
   State: [9] Failed
   Last error: Timed out

Ce que cela signifie : Tout écrivain en état d’échec peut bloquer les opérations d’instantané.

Décision : Si un écrivain est en échec, identifiez son service/app et redémarrez-le ou corrigez son problème sous-jacent. Si plusieurs sont en échec, suspectez la santé du service VSS, des conflits de fournisseur ou une corruption des fichiers système.

Task 6: Check VSS providers (third-party conflicts show up here)

cr0x@server:~$ vssadmin list providers
Provider name: 'Microsoft Software Shadow Copy provider 1.0'
   Provider type: Software
   Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   Version: 1.0.0.7

Ce que cela signifie : Si vous voyez des fournisseurs supplémentaires provenant d’outils de sauvegarde/stockage, ils peuvent interférer.

Décision : En environnement d’entreprise, coordonnez-vous avec le propriétaire des outils de sauvegarde avant de supprimer des fournisseurs. Sur une machine personnelle, désinstallez les outils de sauvegarde abandonnés qui ont injecté des fournisseurs VSS.

Task 7: Verify key services are running and not disabled

cr0x@server:~$ sc query VSS

SERVICE_NAME: VSS
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
cr0x@server:~$ sc query swprv

SERVICE_NAME: swprv
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 3  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)

Ce que cela signifie : VSS peut être en cours d’exécution alors que le service fournisseur Microsoft est arrêté ; il peut démarrer à la demande, mais « désactivé » est mauvais.

Décision : Si l’un des services est désactivé ou refuse de démarrer, corrigez le type de démarrage du service et examinez les erreurs dans les journaux Système/Événements.

Task 8: Quick scan for VSS/System Restore errors in Event Viewer logs

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='VSS'] and (Level=2)]]" /c:5 /f:text
Event[0]:
  Provider Name: VSS
  Event ID: 8193
  Level: Error
  Description:
  Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr = 0x80040154, Class not registered.

Ce que cela signifie : 0x80040154 pointe vers des problèmes d’enregistrement COM — souvent des composants cassés ou une détérioration du registre.

Décision : Si des erreurs sont récurrentes, ne vous contentez pas de redémarrer les services ; procédez à la réparation des fichiers système (SFC/DISM) et vérifiez les permissions COM pour VSS (voir tâches ultérieures).

Task 9: Check for filesystem errors (the “boring but correct” move)

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
Windows has scanned the file system and found no problems.
No further action is required.

Ce que cela signifie : Si ceci signale des erreurs, VSS peut échouer ou créer des instantanés non fiables.

Décision : Si des erreurs sont trouvées, planifiez une réparation hors ligne : chkdsk C: /f (nécessite un redémarrage). Faites cela avant de faire confiance aux points de restauration.

Task 10: Repair system files (SFC)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.

Windows Resource Protection found corrupt files and successfully repaired them.

Ce que cela signifie : La corruption peut casser des composants VSS ou des écrivains.

Décision : Si SFC a réparé des fichiers, redémarrez, puis retestez la création de point de restauration. Si SFC ne peut pas tout réparer, passez à DISM.

Task 11: Repair component store (DISM)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : DISM répare le magasin de composants Windows, dont dépend SFC.

Décision : Après le succès de DISM, exécutez sfc /scannow à nouveau et redémarrez.

Task 12: Create a test restore point (don’t trust; verify)

cr0x@server:~$ powershell -NoProfile -Command "Checkpoint-Computer -Description 'SR smoke test' -RestorePointType 'MODIFY_SETTINGS'"

Ce que cela signifie : L’absence de sortie signifie généralement qu’il a été mis en file d’attente avec succès. Confirmez qu’il existe.

Décision : Listez immédiatement les points de restauration à nouveau (Task 1). S’il n’apparaît pas, la création a échoué — vérifiez l’Observateur d’événements pour les erreurs System Restore/VSS à ce moment.

Task 13: Inspect existing shadow copies (do they exist at all?)

cr0x@server:~$ vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool

Contents of shadow copy set ID: {1c2d...}
   Contained 1 shadow copies at creation time: 2/2/2026 10:21:05 AM
      Shadow Copy ID: {9aa1...}
      Original Volume: (C:)\\?\Volume{2f3f...}\
      Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12
      Provider: 'Microsoft Software Shadow Copy provider 1.0'
      Type: ClientAccessible
      Attributes: Persistent, Client-accessible, No auto release

Ce que cela signifie : S’il n’y a aucune copie shadow, soit les points de restauration ne sont jamais créés, soit ils sont purgés.

Décision : Si des shadows existent mais que les points de restauration n’apparaissent pas, suspectez la configuration/politiques de la restauration du système plutôt que VSS lui-même.

Task 14: Resize shadow storage (stop starving the mechanism)

cr0x@server:~$ vssadmin resize shadowstorage /for=C: /on=C: /maxsize=15GB
Successfully resized the shadow copy storage association.

Ce que cela signifie : Vous avez donné de l’espace de respiration à VSS.

Décision : Après le redimensionnement, créez un nouveau point de restauration et vérifiez qu’il persiste après un redémarrage.

Task 15: Check policy that disables System Restore

cr0x@server:~$ reg query "HKLM\Software\Policies\Microsoft\Windows NT\SystemRestore" /v DisableSR
ERROR: The system was unable to find the specified registry key or value.

Ce que cela signifie : Aucune clé de politique trouvée (bon). Si DisableSR est défini sur 1, c’est désactivé par politique.

Décision : Si la politique le désactive, corrigez-la dans la stratégie de groupe (en entreprise) ou supprimez la clé (sur une machine personnelle, si vous en êtes le propriétaire et comprenez pourquoi elle existe).

Task 16: Validate restore from Windows Recovery Environment when Windows is unstable

cr0x@server:~$ reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Windows RE status:         Enabled
Windows RE location:       \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE

Ce que cela signifie : Si WinRE est désactivé, les options de récupération sont limitées lorsque l’OS ne démarre pas.

Décision : Si désactivé, activez WinRE dans le cadre du « réparez-le avant d’en avoir besoin ». Si activé, vous pouvez compter sur les flux de restauration hors ligne lorsque l’interface graphique est absente.

Blague #2 : Si votre « optimiseur PC » promet d’accélérer Windows en supprimant les copies shadow, ce n’est pas de l’optimisation — c’est de la démolition avec un meilleur marketing.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’organisation était en pleine migration vers une nouvelle plateforme de gestion des endpoints. L’image de base Windows semblait propre, les applications s’installaient correctement et le volume de tickets helpdesk avait baissé. Tout le monde a pris la victoire et est passé à autre chose. L’hypothèse : les points de restauration existent par défaut.

Puis une mise à jour de pilote a été déployée — liée à l’affichage, « sûre », signée par le fournisseur. Sur un sous-ensemble de portables, elle a provoqué une boucle de démarrage après le premier redémarrage. Classique. Le helpdesk a suivi le playbook : démarrer en récupération, lancer la restauration du système, sélectionner le dernier point de restauration.

Il n’y avait aucun point de restauration. Aucun. Pas « trop vieux ». Juste absent. L’équipe a découvert que la protection du système avait été désactivée dans l’image des mois plus tôt lors d’un effort de réduction d’espace disque, puis propagée par automatisation. Ce n’était pas malveillant ; c’était invisible.

La récupération a donc changé : au lieu d’un rollback, ce fut une réimagerie. Ce sont des heures d’indisponibilité utilisateur, des données dispersées et une longue semaine pour le support. Le pire n’était pas le pilote — c’était la fausse croyance qu’un rollback existait.

La correction était ennuyeuse : réactiver la protection du système pour C:, allouer un stockage shadow sensé et ajouter un contrôle de conformité dans la gestion des endpoints qui alerte si la restauration est désactivée. L’enseignement post-incident était plus franc : si vous ne testez pas la récupération, vous n’avez pas de récupération.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe de virtualisation est devenue agressive sur le stockage. L’image golden pour une ferme VDI avait un script qui s’exécutait chaque semaine : nettoyage des temporaires, caches Windows Update obsolètes et — parce que quelqu’un avait trouvé un article de blog — des copies shadow. Le script semblait « sûr » car il ne supprimait que des choses anciennes, et il améliorait les métriques d’espace libre.

Puis un patch fournisseur a cassé une application de comptabilité sur des centaines de postes. L’application dépendait d’un composant COM qui se mettait à jour avec le patch ; le rollback aurait été une réparation rapide pendant que le fournisseur réglait le problème.

Sauf que la restauration du système ne pouvait pas revenir en arrière. Les points de restauration avaient été purgés chaque semaine, et les restants étaient trop récents pour aider. Pire, le modèle VDI « non persistant » empêchait les utilisateurs d’essayer une restauration localement ; tout était une réparation centrale ou une reconstruction.

Ils ont récupéré, mais le chemin fut moche : packaging d’urgence de l’application, un package de rollback, et des fenêtres de changement après heures. L’« optimisation » a économisé quelques Go et coûté beaucoup de travail et de confiance.

La nouvelle norme : si vous allez supprimer des copies shadow, vous devez fournir un mécanisme de rollback équivalent ou meilleur (instantanés au niveau hyperviseur, rollback au niveau de la couche applicative, ou pipeline d’imagerie testé). Ne supprimez pas les parachutes parce qu’ils pèsent un peu.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite société financière avait l’habitude qui ressemblait à de la paranoïa : après Patch Tuesday, un ingénieur desktop créait manuellement un point de restauration sur un échantillon de machines, puis réalisait un test de restauration contrôlé sur une machine sacrificielle.

Ce n’était pas sophistiqué. Pas de tableaux de bord. Pas d’IA. Juste un rappel calendrier, une checklist et une machine qu’ils étaient prêts à casser volontairement. Ils avaient aussi une politique : maintenir le stockage shadow à un minimum fixe et alerter si cela diminue.

Un mois, une mise à jour Windows a mal interagi avec un agent de chiffrement endpoint. Les machines démarraient mais ne pouvaient pas authentifier les utilisateurs de façon fiable — pannes sporadiques, journaux confus. L’équipe n’a pas tergiversé. Ils ont restauré la machine sacrificielle d’abord, confirmé la récupération, puis appliqué l’action de restauration aux systèmes affectés tout en mettant en pause le déploiement de la mise à jour.

Les utilisateurs ont connu une matinée difficile, pas une semaine perdue. La direction a reçu un résumé d’incident d’une page au lieu d’un appel de crise. L’astuce salvatrice n’était pas magique ; c’était une voie de rollback testée.

Voilà tout le jeu : la fiabilité est rarement héroïque. C’est surtout des routines qui semblent ennuyeuses jusqu’à ce qu’elles comptent.

Erreurs courantes : symptôme → cause racine → correction

Les points de restauration sont manquants

  • Symptôme : L’interface de restauration du système n’affiche aucun point de restauration ; Get-ComputerRestorePoint ne renvoie rien.
  • Cause racine : Protection du système désactivée pour C:, ou clé de politique DisableSR=1.
  • Correction : Activez la protection du système ; supprimez/ajustez la politique ; allouez du stockage shadow ; créez et vérifiez un point de restauration de test.

Les points de restauration apparaissent, puis disparaissent après un jour ou deux

  • Symptôme : Vous pouvez créer un point, mais il a disparu plus tard.
  • Cause racine : Max du stockage shadow trop petit ; pression disque ; outil de nettoyage supprimant les copies shadow.
  • Correction : Augmentez le stockage shadow (vssadmin resize shadowstorage), libérez de l’espace, retirez ou reconfigurez le logiciel de nettoyage, et surveillez used/allocated/max.

La restauration échoue avec des erreurs vagues (0x8000ffff, 0x81000203, etc.)

  • Symptôme : La restauration échoue tôt ; les erreurs sont inconsistantes.
  • Cause racine : Échecs d’écrivains VSS, problèmes d’enregistrement COM, fichiers système corrompus.
  • Correction : Vérifiez les écrivains ; réparez avec DISM/SFC ; redémarrez ; assurez-vous que VSS et les services fournisseurs sont sains ; inspectez l’Observateur d’événements pour le code spécifique proche du moment d’échec.

La restauration est bloquée ou prend une éternité

  • Symptôme : « Restauration des fichiers… » reste bloqué des heures.
  • Cause racine : Problèmes disque, interférence antivirus, forte contention IO, ou réparations du système de fichiers nécessaires.
  • Correction : Vérifiez la santé du disque (chkdsk), désactivez temporairement l’AV tiers pour la restauration (selon la politique), essayez une restauration hors ligne depuis WinRE, et assurez un espace libre adéquat.

La restauration se termine, mais le problème persiste

  • Symptôme : « Restauration du système terminée avec succès » mais le problème demeure.
  • Cause racine : Le changement est hors du périmètre de la restauration du système (firmware, pilotes de chiffrement, certains composants bas niveau), ou le point de restauration a été pris après le changement problématique.
  • Correction : Choisissez un point antérieur ; s’il n’en existe aucun, utilisez une vraie sauvegarde/imagerie ; traitez la restauration du système comme un rollback pour l’état système, pas comme un voyage temporel universel.

La restauration échoue uniquement sur certaines machines d’une flotte

  • Symptôme : Même build, même patch, mais seuls certains appareils ne peuvent pas créer/restaurer.
  • Cause racine : Différences d’agents fournisseurs, fournisseurs VSS tiers, permissions de services cassées, ou usure disque.
  • Correction : Comparez les listes de fournisseurs VSS et d’écrivains, vérifiez les politiques, et validez SMART/état du disque via vos outils. Standardisez les agents endpoints.

Listes de contrôle / plan étape par étape

Checklist A : baseline « Réparez-le avant d’en avoir besoin » (20–30 minutes par machine)

  1. Activez la protection du système pour le volume OS (C:). Décidez d’une politique d’allocation (GB fixe ou pourcentage) et standardisez-la.
  2. Définissez un max de stockage shadow adapté à la classe d’appareil :
    • Petits portables SSD : 8–15 GB (ou ~5–10 % du disque OS si vous pouvez vous le permettre).
    • Stations de travail : 15–30 GB selon le taux de changements.
  3. Assurez-vous d’au moins ~10 % d’espace libre sur C: comme objectif opérationnel.
  4. Confirmez que WinRE est activé afin de pouvoir restaurer quand Windows ne démarre pas.
  5. Créez un point de restauration de test et vérifiez qu’il apparaît.
  6. Redémarrez une fois, puis confirmez que le point de restauration existe toujours.
  7. Enregistrez une référence : sortie de vssadmin list shadowstorage, vssadmin list writers, et erreurs VSS récentes (idéalement aucune).

Checklist B : Quand la restauration du système échoue (triage vers correction)

  1. Arrêtez de deviner. Rassemblez les faits :
    • Points de restauration présents ?
    • Capacité du stockage shadow ?
    • Espace disque libre ?
    • État des écrivains ?
    • Codes d’erreur dans l’Observateur d’événements ?
  2. Corrigez d’abord la pression disque. Si C: est presque plein, tout le reste est du bruit.
  3. Corrigez les échecs des écrivains VSS :
    • Redémarrer (oui, vraiment — les écrivains sont à état).
    • Redémarrer les services affectés (ciblé, pas au hasard).
    • Réparer les fichiers système (DISM puis SFC).
  4. Éliminez les conflits :
    • Désinstallez les outils de sauvegarde abandonnés avec fournisseurs VSS.
    • Désactivez les tâches « optimiseurs » qui suppriment les copies shadow.
  5. Retester : Créez un point de restauration, vérifiez qu’il existe, redémarrez, vérifiez à nouveau.

Checklist C : Hygiène de flotte (à quoi ressemblent les instincts SRE sur postes)

  1. Contrôle de conformité : alerter si la protection du système est désactivée sur les endpoints où elle devrait l’être.
  2. Contrôle de capacité : alerter si l’espace libre descend sous le seuil ou si le max du stockage shadow est inférieur à la politique.
  3. Gestion des changements : tout outil qui supprime des copies shadow nécessite une stratégie de rollback explicite en remplacement.
  4. Test de restauration trimestriel : choisissez une machine sacrificielle par classe matérielle et effectuez une vraie restauration.
  5. Standardisez les agents endpoints : moins de « cas particuliers », moins d’effets de bord VSS.

FAQ

La restauration du système est-elle la même chose qu’une sauvegarde ?

Non. C’est un rollback pour l’état système. Si vous tenez à vos fichiers, utilisez de vraies sauvegardes (historique des fichiers, imagerie, sauvegarde d’entreprise).

Pourquoi mes points de restauration disparaissent-ils ?

Généralement parce que le stockage shadow a atteint son maximum et Windows a purgé les points plus anciens, ou un outil de nettoyage/optimisation a supprimé les copies shadow. Vérifiez vssadmin list shadowstorage et auditez les tâches de nettoyage.

Combien de stockage shadow devrais-je allouer ?

Assez pour conserver plusieurs points de restauration pendant votre fenêtre de changements typique (patching, mises à jour pilotes). Sur Windows moderne, 8–15 GB est un bon départ pour les portables ; ajustez selon le churn et la taille du disque.

Quel est le moyen le plus rapide pour voir si VSS est cassé ?

vssadmin list writers. Si vous voyez des écrivains en état d’échec, VSS n’est pas sain pour les opérations d’instantané/restauration.

Puis-je compter sur la restauration du système si Windows ne démarre pas ?

Seulement si WinRE est activé et que des points de restauration existent. Validez avec reagentc /info et un test de restauration périodique.

L’antivirus interfère-t-il avec la restauration du système ?

Ça peut arriver. Certains AV accrochent fortement les opérations fichier et registre. Si la restauration échoue systématiquement, testez la désactivation temporaire de l’AV tiers pendant la restauration (dans le respect de la politique) et privilégiez la restauration hors ligne depuis WinRE.

Dois-je supprimer tous les points de restauration pour « réparer » la restauration du système ?

Parfois réinitialiser le stockage shadow aide lorsque celui-ci est corrompu, mais c’est un dernier recours car vous effacez votre historique de rollback. Essayez d’abord de redimensionner le stockage et de réparer la santé VSS.

Pourquoi la restauration du système dit qu’elle a réussi mais rien n’a changé ?

Parce que le problème n’était pas dans le périmètre contrôlé par la restauration du système, ou le point de restauration a été pris après le changement néfaste. Vérifiez l’horodatage du point de restauration par rapport à l’incident.

Que faire si VSS affiche une erreur COM comme 0x80040154 ?

Cela indique souvent un enregistrement COM cassé ou une corruption de composant. Exécutez DISM et SFC, examinez les erreurs VSS dans l’Observateur d’événements, et vérifiez la présence d’outils de sauvegarde à moitié désinstallés.

Est-il sûr de définir le stockage shadow sur UNBOUNDED ?

Sur un volume OS unique, je n’aime pas ça. Cela peut silencieusement consommer l’espace disque jusqu’à rendre la machine malade. Fixez un maximum et surveillez l’espace libre.

Prochaines étapes pratiques

  1. Exécutez le guide de diagnostic rapide sur une machine aujourd’hui. Pas quand vous êtes déjà en panne.
  2. Allouez le stockage shadow délibérément (Task 3 + Task 14). Priver VSS, c’est se saboter.
  3. Faites un test fumée de point de restauration (Task 12), puis redémarrez et confirmez qu’il persiste (Task 1).
  4. Corrigez les problèmes de santé sous-jacents : erreurs disque (chkdsk), corruption système (DISM/SFC) et échecs d’écrivains VSS.
  5. Supprimez les « nettoyeurs » de copies shadow ou placez-les derrière une alternative de rollback approuvée.
  6. En entreprise : construisez des contrôles de conformité pour que « Protection du système désactivée » soit une alerte, pas une surprise.

La restauration du système n’est pas glamour. Les interventions à 2 h du matin non plus. L’une de ces deux choses est optionnelle à pratiquer à l’avance. Choisissez la moins chère.

← Précédent
Boucle de crash du pilote NVIDIA/AMD : réinstallation propre correctement (DDU + Mode Sans Échec)
Suivant →
Docker : « Ça marche sur ma machine » — La règle du tag d’image qui met fin au drame

Laisser un commentaire