Points de restauration manquants : le paramètre que Windows désactive sans cesse

Ce qui se passe réellement quand les points de restauration « disparaissent »

Les points de restauration de Windows reposent sur le Volume Shadow Copy Service (VSS). System Restore (la fonctionnalité que vous utilisez) est essentiellement un consommateur des clichés VSS plus un ensemble de suivi d’état système : les ruchettes du registre, certains fichiers système, pilotes et métadonnées de configuration. Ce n’est pas une sauvegarde complète, ce n’est pas une « image disque », et ce n’est certainement pas une machine à remonter le temps qui résiste au ransomware.

Alors pourquoi les points de restauration disparaissent-ils ?

• La Protection du système est réellement désactivée pour le lecteur système, souvent après une mise à niveau de l’OS, l’application d’une stratégie ou une « optimisation ».
• Le quota d’espace disque est trop faible. Les points de restauration sont stockés dans la zone de « shadow storage ». Quand elle est pleine, Windows supprime les points anciens. Si le quota est ridiculement petit, vous avez une porte tournante : les points sont créés puis immédiatement évincés.
• VSS est en mauvais état (writers bloqués, services désactivés, erreurs de fournisseur). Les points de restauration échouent silencieusement ou ne laissent rien d’utilisable.
• Des outils de nettoyage les suppriment : Nettoyage de disque, Storage Sense, « cleaners » tiers, certaines suites de maintenance OEM.
• Les copies d’ombre sont supprimées par des actions administratives (y compris des scripts), ou par certains flux de mise à jour/mise à niveau de fonctionnalité.

Ce qui rend cela exaspérant, c’est que Windows peut sembler en ordre jusqu’au moment où vous avez besoin de revenir en arrière. Les points de restauration sont comme des extincteurs : personne n’en prévoit jusqu’à ce que la cuisine soit en feu.

Une citation pour rester lucide : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan. Les opérationnels n’ont pas inventé la formule, mais nous l’avons adoptée.

Et voici votre première plaisanterie : System Restore est le parachute qu’on ne remarque que lorsqu’on a déjà sauté.

Faits intéressants et contexte historique (oui, ça compte)

1. System Restore a fait ses débuts dans Windows ME (2000) puis est devenu courant avec Windows XP. Les premières versions étaient controversées parce qu’elles pouvaient gonfler l’utilisation du disque et parfois restaurer des malwares en même temps que le système.
2. VSS est arrivé à l’époque de Windows XP/Server 2003 comme infrastructure standard et est devenu une couche de plomberie pour les sauvegardes, les points de restauration et les « Versions précédentes » au niveau fichier.
3. Les points de restauration ne sont pas identiques aux « Versions précédentes » même si les deux utilisent des shadow copies. Les Versions précédentes dépendent de l’existence des clichés pour les fichiers ; System Restore dépend de la protection activée et du choix par l’OS de ce qu’il suit.
4. Les mises à niveau de fonctionnalité Windows (sauts de version) réinitialisent souvent ou désactivent les paramètres de protection sur certaines machines, surtout lorsque la disposition des volumes change ou que l’identification du volume « système » devient floue.
5. Le stockage des clichés est par volume, et il peut être situé sur un volume différent. C’est puissant—et aussi source de confusion quand on pense avoir activé C: mais les snapshots ont disparu.
6. VSS utilise des « writers » (composants qui préparent les données pour le cliché). Quand les writers restent bloqués, vous pouvez avoir un PC qui fonctionne mais qui refuse de prendre des clichés de manière fiable.
7. Certaines images d’entreprise désactivent volontairement System Restore pour réduire la variance de support ou parce qu’elles reposent sur l’imagerie complète/MDM pour le retour arrière. Si cette stratégie fuit vers des machines non gérées, vous obtenez une surprise.
8. Le Nettoyage de disque proposait historiquement des options qui peuvent supprimer des points de restauration (en ne conservant que le plus récent). Les gens cliquent sur « Nettoyer les fichiers système » comme si c’était de l’argent gratuit.
9. System Restore ne protège pas les fichiers utilisateur comme les utilisateurs le supposent. Il est destiné à la restauration de l’état système, pas à récupérer votre rapport écrasé à 2h du matin.

Mode opératoire de diagnostic rapide

Voici la séquence « ne pas vouloir résoudre tout le réseau ». Suivez-la dans l’ordre. Elle trouve le goulot rapidement et évite de chasser des fantômes.

1) Confirmer l’état de la Protection du système pour le volume OS

Si c’est Désactivé, tout le reste est une quête secondaire. Réactivez-la et fixez un quota raisonnable.

2) Vérifier le quota et l’utilisation du shadow storage

Si la taille maximale est minuscule ou réglée à 0/« illimitée mais en pratique affamée », les points vont tourner en rond ou disparaître.

3) Vérifier la santé de VSS (writers + services)

Des writers en erreur ou des services désactivés signifient que les clichés ne seront pas créés même si l’interface dit que ça devrait marcher.

4) Examiner le comportement de suppression : nettoyage, stratégie, scripts

Storage Sense, tâches de nettoyage, outils « optimisateurs » et certains scripts d’entreprise suppriment régulièrement les shadow copies pour récupérer de l’espace.

5) Corréler avec les événements

VSS et System Restore consignent leurs plaintes. Le journal des événements est l’endroit où Windows avoue ce qu’il a fait.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement. Chacune inclut : commande, sortie d’exemple, ce que cela signifie et ce que vous faites ensuite.

Task 1 — Lister les points de restauration existants (si présents)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerRestorePoint | Select-Object SequenceNumber, Description, CreationTime | Format-Table -Auto"
SequenceNumber Description                     CreationTime
-------------- -----------                     ------------
           132 Windows Update                  1/31/2026 2:14:07 AM
           131 Installed NVIDIA Graphics Driver 1/30/2026 6:02:33 PM

Ce que cela signifie : Si cela retourne des lignes, System Restore possède au moins quelques métadonnées. Si cela renvoie une erreur (« Cannot find path » ou « System Restore is disabled »), c’est un indice.

Décision : Aucun point listé ? Passez aux vérifications Protection du système et VSS. Certains systèmes ont des snapshots VSS sans points SR ; ne les assumez pas équivalents.

Task 2 — Vérifier si System Restore est désactivé via des clés de stratégie de registre

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore' -ErrorAction SilentlyContinue | Format-List"
DisableConfig : 1
DisableSR     : 1
PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore

Ce que cela signifie : DisableSR=1 signifie que System Restore est désactivé par une stratégie. C’est courant en environnement domaine ou après des scripts de durcissement.

Décision : Si ces clés existent, vous ne « corrigez » pas cela dans l’interface. Vous corrigez la stratégie (GPO/MDM/baseline) ou supprimez la clé si c’est approprié et autorisé.

Task 3 — Vérifier la configuration de System Protection via WMI (contrôle rapide)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root/default -ClassName SystemRestoreConfig | Select-Object -Property * | Format-List"
RPLifeInterval : 7776000
DiskPercent    : 3
PSComputerName :

Ce que cela signifie : Cela montre la configuration de System Restore, comme le pourcentage disque réservé. DiskPercent très bas est un signal d’alarme sur les systèmes modernes.

Décision : Si DiskPercent est à 1–3% sur une station active, augmentez-le. Si la classe ne renvoie rien, SR peut être désactivé ou cassé.

Task 4 — Lister les shadow copies présentes (snapshots VSS)

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

Contents of shadow copy set ID: {6f5d1fe9-8d8d-4f1c-9b3a-6efaf7fadc1b}
   Contained 1 shadow copies at creation time: 2/3/2026 9:12:21 AM
      Shadow Copy ID: {c5e65b1e-0cbd-4f2d-96c2-4a0b9a3d6d62}
         Original Volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12
         Originating Machine: DESKTOP-OPS1
         Service Machine: DESKTOP-OPS1
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessible
         Attributes: Persistent, Client-accessible, No auto release, Differential

Ce que cela signifie : Si des shadows existent mais pas de points de restauration, vous avez peut-être VSS utilisé par des sauvegardes/Versions précédentes alors que System Restore est désactivé. Ou les métadonnées des points de restauration manquent.

Décision : S’il n’y a aucun shadow, soit vous n’en créez pas, soit ils sont supprimés, soit VSS échoue. Poursuivez avec les vérifications du quota de stockage et des writers VSS.

Task 5 — Inspecter l’utilisation et le quota du shadow storage (celui-ci explique les « disparitions »)

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

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 1.421 GB (1%)
   Allocated Shadow Copy Storage space: 1.500 GB (1%)
   Maximum Shadow Copy Storage space: 1.500 GB (1%)

Ce que cela signifie : La taille max est 1,5 Go. C’est dérisoire sur une installation Windows moderne. Une seule mise à jour peut tout faire tourner.

Décision : Augmentez le quota. Si vous ne pouvez pas allouer d’espace sur C:, envisagez de déplacer le shadow storage vers un autre volume (avec précaution).

Task 6 — Augmenter le quota du shadow storage à une valeur raisonnable

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é à VSS la marge pour conserver plusieurs points de restauration.

Décision : Si le disque est petit (ex. 128 Go), choisissez une taille proportionnelle (8–12 Go). Si les points sont cruciaux, 15–30 Go est raisonnable.

Task 7 — Vérifier que les services VSS sont en cours et pas désactivés

cr0x@server:~$ powershell -NoProfile -Command "Get-Service VSS,swprv | Select-Object Name,Status,StartType | Format-Table -Auto"
Name  Status  StartType
----  ------  ---------
VSS   Running Manual
swprv Stopped Manual

Ce que cela signifie : VSS tourne. Le fournisseur Microsoft Software Shadow Copy (swprv) est en type Manual et arrêté, ce qui est normal jusqu’à ce qu’il soit nécessaire.

Décision : Si l’un est Disabled, c’est problématique. Mettez sur Manual, démarrez VSS et retestez la création d’un point.

Task 8 — Vérifier l’état des writers VSS (le détecteur « pourquoi ça échoue ? »)

cr0x@server:~$ vssadmin list writers
Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {5d1aa4f8-8b6c-4a35-8571-34a13b2bfc4d}
   State: [1] Stable
   Last error: No error

Writer name: 'WMI Writer'
   Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
   Writer Instance Id: {0d54d70a-7f44-4af6-8a0f-778a85b54d1c}
   State: [9] Failed
   Last error: Timed out

Ce que cela signifie : Un writer est en échec. Les points de restauration peuvent échouer ou être incomplets quand des writers critiques sont cassés.

Décision : Corrigez le service sous-jacent pour ce writer (souvent des problèmes du dépôt WMI, des délais d’attente du fournisseur ou des services dépendants). Au minimum, redémarrez les services et recontrôlez. Si ça reste en échec, vous n’êtes pas « sauvé » juste parce que l’UI dit « Activé ».

Task 9 — Consulter les événements System Restore et VSS (arrêtez de deviner)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'; StartTime=(Get-Date).AddDays(-7)} | Select-Object TimeCreated,Id,LevelDisplayName,Message | Select-Object -First 5 | Format-List"
TimeCreated      : 1/31/2026 2:14:10 AM
Id               : 8193
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance.  Error: [0x80040154]

TimeCreated      : 1/31/2026 2:14:08 AM
Id               : 12289
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider.

Ce que cela signifie : 0x80040154 est « Classe non enregistrée » en termes COM. Cela pointe souvent vers un enregistrement de fournisseur cassé ou des composants corrompus.

Décision : Si vous voyez des erreurs répétées de fournisseur VSS, n’augmentez pas seulement les quotas. Réparez la pile VSS (vérifications du magasin de composants, nettoyage des fournisseurs) et envisagez de supprimer les fournisseurs tiers si présents.

Task 10 — Créer un point de restauration manuellement et observer les erreurs

cr0x@server:~$ powershell -NoProfile -Command "Checkpoint-Computer -Description 'Manual restore point for testing' -RestorePointType 'MODIFY_SETTINGS'"

Ce que cela signifie : L’absence de sortie signifie généralement le succès. Si une exception est levée (« System Restore is disabled » ou « The restore point could not be created »), vous avez un signal d’échec direct.

Décision : Si la création manuelle échoue, vous êtes face à une configuration/stratégie/santé VSS, pas à un « Windows qui oublie ». Revenez aux writers, services et clés de stratégie.

Task 11 — Vérifier les tâches planifiées qui influencent la création de points

cr0x@server:~$ schtasks /Query /TN "\Microsoft\Windows\SystemRestore\SR" /V /FO LIST
Folder: \Microsoft\Windows\SystemRestore
HostName:                             DESKTOP-OPS1
TaskName:                             \Microsoft\Windows\SystemRestore\SR
Next Run Time:                        2/4/2026 12:00:00 AM
Status:                               Ready
Logon Mode:                           Interactive/Background
Last Run Time:                        2/3/2026 12:00:00 AM
Last Result:                          0x0
Author:                               Microsoft Corporation
Task To Run:                          %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation

Ce que cela signifie : La tâche existe et le dernier résultat est 0x0 (succès). Si elle manque ou échoue, la création automatique peut ne pas se produire.

Décision : Si elle manque, vous pouvez toujours créer des points manuellement, mais le comportement automatique est cassé. Si elle échoue, examinez l’historique de la tâche et les journaux d’événements pour comprendre pourquoi.

Task 12 — Vérifier l’espace libre et si C: est sous pression

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive C | Select-Object Name,Free,Used | Format-List"
Name : C
Free : 6829434880
Used : 243915735040

Ce que cela signifie : Environ 6,8 Go libres. C’est « une mise à jour cumulative Windows loin d’un mauvais jour ». L’espace libre faible déclenche des nettoyages agressifs et l’éviction des snapshots.

Décision : Si l’espace libre est serré, corrigez cela d’abord : agrandissez la partition, désinstallez le superflu, déplacez des données ou changez la stratégie de rétention. Pas d’espace, pas de snapshots.

Task 13 — Identifier les fournisseurs VSS tiers (source fréquente d’anomalies)

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

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 : Seul le fournisseur Microsoft est présent. Bien. Si vous voyez des fournisseurs supplémentaires (agents de sauvegarde, outils de stockage), ils peuvent perturber VSS ou modifier les règles de rétention.

Décision : Si un fournisseur tiers est présent et que vous voyez des erreurs VSS, coordonnez-vous avec le propriétaire du logiciel. Ne le supprimez pas sans précaution sur une flotte en production.

Task 14 — Vérifier les paramètres Storage Sense qui peuvent déclencher des nettoyages

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy' -ErrorAction SilentlyContinue | Format-List"
01 : 1
04 : 1
08 : 1

Ce que cela signifie : Storage Sense est activé (01) et configuré pour certains comportements de nettoyage. Cela ne dit pas directement « supprimer les points de restauration », mais cela corrèle avec une récupération d’espace agressive sur systèmes à faible disque.

Décision : Si les points disparaissent pendant les « jours de nettoyage », révisez Storage Sense et les baselines de nettoyage entreprises. Assurez-vous de ne pas balayer le filet de sécurité pour gagner quelques gigaoctets.

Causes profondes qui poussent Windows à le désactiver (ou à agir comme si)

1) Les mises à niveau de fonctionnalité réinitialisent l’état de protection

Les grosses mises à jour Windows ne sont pas délicates. Elles réarrangent des fichiers système, réécrivent la configuration de démarrage et parfois réinterprètent quel volume est « système ». Dans ce processus, la Protection du système peut se retrouver Désactivée, ou ses paramètres revenir aux valeurs par défaut. Si vous gérez des flottes, supposez que cela arrive parfois et vérifiez après les vagues de mise à jour.

2) Group Policy / MDM baselines la désactivent

Les entreprises désactivent souvent System Restore parce qu’elles préfèrent l’imagerie standardisée et parce que les points de restauration peuvent compliquer les scripts de support. C’est une décision rationnelle—si vous avez une autre méthode de retour arrière. Le mode défaillant survient lorsque la stratégie désactive cela sur des machines qui n’ont pas d’alternative, comme des ordinateurs portables d’exécutifs ou des appareils sur le terrain.

3) Les routines « d’optimisation » et de nettoyage suppriment les shadow copies

Certains jobs de nettoyage traitent les shadow copies comme du cache. Ce n’est pas du cache. C’est de l’état. Les supprimer n’est pas de la « maintenance », c’est enlever la manette de retour arrière. Nettoyage de disque et outils tiers peuvent réduire les points à un seul récent, ou effacer les shadow copies complètement.

4) La pression d’espace disque force l’éviction

VSS a un quota. Quand il est atteint, les clichés anciens sont supprimés. Si votre quota est minuscule, vous avez en pratique des « points de restauration » de quelques minutes seulement. Si le disque est presque plein, Windows fera des choix impitoyables. Il préfère que l’OS continue de fonctionner plutôt que de préserver l’amertume de votre futur vous.

5) Échecs de writers/fournisseurs VSS

La création d’un point dépend d’une chaîne de composants : services, enregistrements COM, writers et fournisseurs. Un writer cassé peut bloquer toute l’opération de snapshot, ou produire des points de restauration non applicables.

Deuxième (et dernière) plaisanterie : les erreurs VSS sont la façon dont Windows dit « j’ai essayé » tout en n’essayant pas vraiment.

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

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

L’environnement : une flotte mixte de portables Windows 10 et 11, plus quelques postes de travail pour CAO. Une équipe a déployé une mise à jour de pilote pour une station d’accueil. Ce n’était pas malveillant. Juste… ambitieux.

À midi, le nombre d’appels au helpdesk a explosé : écrans externes devenant noirs, périphériques USB déconnectés, machines gelant de façon intermittente. L’ingénieur d’astreinte a fait ce que toute personne sensée ferait : « Pas de problème, revenir en arrière via des points de restauration. » Sauf que les points manquaient sur une grande partie des machines.

L’hypothèse était subtile : « Windows garde toujours des points de restauration. » En réalité, la Protection du système avait été désactivée des mois auparavant dans une baseline de standardisation conçue pour des machines de labo réimaginées chaque semaine. Cette baseline a été réutilisée pour des portables. Personne ne l’a remarqué parce que tout allait bien—jusqu’à ce que ça n’aille plus.

La réparation n’a pas été héroïque. Ils ont reverti la stratégie pour l’unité d’organisation des portables, réactivé la protection, défini un quota capable de survivre à deux mises à jour cumulatives, et ajouté une étape de vérification post-changement : confirmer qu’au moins un nouveau point existe sur les appareils de test avant le déploiement. La leçon : si un mécanisme de sécurité n’est pas explicitement surveillé, il n’existe pas.

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

Un autre service, une autre volonté de « récupérer du stockage ». Les SSD se remplissaient, et quelqu’un a déployé un script de nettoyage agressif. Il supprimait fichiers temporaires, caches de navigateurs, anciens téléchargements de mises à jour et—parce que cela semblait raisonnable—les shadow copies.

Le script a merveilleusement fonctionné. Les graphiques d’espace disque remontaient. Tout le monde a applaudi. Deux semaines plus tard, une mauvaise mise à jour Windows a provoqué des problèmes de démarrage sur une partie des machines. Les options de récupération se sont rapidement réduites : les clés BitLocker étaient disponibles, mais les points de restauration auraient été le moyen le plus propre de revenir en arrière pour de nombreux systèmes.

Ils avaient disparu, parce que le script les supprimait selon un calendrier. Pire, le script s’exécutait juste après Patch Tuesday, moment où on a le plus besoin de points de restauration. L’optimisation a atteint la métrique (espace libre) en sabordant la capacité de récupération (rétablissement rapide).

La correction a été de traiter les shadow copies comme une capacité protégée. Ils ont remanié la politique de nettoyage pour cibler des zones sûres et ont instauré des seuils minimum d’espace libre, mais sans jamais supprimer massivement les shadow copies. L’échec n’était pas technique : c’était un mauvais ordre de priorité.

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

Un service financier suivait une pratique classique : avant la clôture mensuelle, ils exécutaient une « checklist de stabilité » sur les postes critiques. Un élément était d’une insipidité douloureuse : vérifier que la Protection du système est activée pour C: et qu’au moins un point de restauration existe créé dans les sept derniers jours.

Pendant une semaine de clôture, une mise à jour d’une application métier a été livrée avec un pilote noyau. Elle a déclenché des BSOD intermittents sur des machines avec un firmware particulier de contrôleur de stockage. Pas toutes les machines—juste assez pour coûter cher.

Parce que des points de restauration existaient et que le quota suffisait pour survivre à la rotation habituelle, l’équipe desktop a rapidement restauré les systèmes, stabilisé l’activité, puis corrigé la cause racine (combinaison firmware + pilote). Pas de réimagerie d’urgence. Pas d’« envoyez l’ordinateur au service et attendez trois jours ». Juste l’hygiène ennuyeuse qui rapporte.

La morale : la réponse spectaculaire aux incidents est une taxe. La préparation silencieuse est un dividende.

Erreurs courantes : symptôme → cause → correctif

1) Symptôme : « Aucun point de restauration n’a été créé »

Cause profonde : Protection du système Désactivée pour C: (ou le volume OS).

Correctif : Activez la Protection du système pour le volume correct, puis créez un point de test. Confirmez son apparition via Get-ComputerRestorePoint.

2) Symptôme : Les points existent brièvement, puis disparaissent dans la journée

Cause profonde : Taille maximale du shadow storage trop petite ; VSS évince immédiatement les anciens points.

Correctif : Augmentez le quota (vssadmin resize shadowstorage). Assurez-vous que l’espace disque libre soutient ce quota.

3) Symptôme : L’interface indique Protection « Activée », mais la création échoue

Cause profonde : Échecs de writers VSS, problèmes de fournisseur ou services désactivés.

Correctif : Vérifiez vssadmin list writers, examinez les journaux VSS, réparez les services/composants sous-jacents. Puis retentez Checkpoint-Computer.

4) Symptôme : Les points de restauration ont disparu juste après avoir lancé Nettoyage de disque

Cause profonde : Le nettoyage a supprimé les points ou réduit au plus récent.

Correctif : Ajustez la pratique de nettoyage. Traitez les points de restauration comme protégés. Augmentez le quota pour éviter que l’exploitation normale vous pousse au « jeu de la roulette de nettoyage ».

5) Symptôme : Les points ont disparu après une mise à jour majeure de Windows

Cause profonde : La mise à niveau a réinitialisé les paramètres de protection ou invalidé les anciens snapshots.

Correctif : Vérification post-mise à jour : assurez-vous que la protection est activée et créez un nouveau point de restauration. N’attendez pas à ce que les anciens survivent aux grosses mises à jour.

6) Symptôme : Sur les machines de domaine, la Protection du système se désactive de nouveau

Cause profonde : Application de stratégie via registres ou GPO de domaine.

Correctif : Corrigez la baseline. Ne vous battez pas contre la stratégie localement ; elle gagnera à chaque cycle de rafraîchissement.

7) Symptôme : Les Versions précédentes fonctionnent, mais System Restore non (ou inversement)

Cause profonde : Consommateurs différents de VSS. L’un peut être activé tandis que l’autre est effectivement désactivé.

Correctif : Vérifiez les deux : la liste des points de restauration et vssadmin list shadows. Configurez explicitement System Protection pour le volume système.

8) Symptôme : Les points échouent surtout sur les portables plutôt que les postes fixes

Cause profonde : Espace disque réduit, transitions d’alimentation fréquentes et politiques de nettoyage agressives qui frappent les appareils mobiles plus fort.

Correctif : Augmentez le quota, imposez un espace libre minimum et n’exécutez pas le nettoyage juste après le déploiement de correctifs.

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

Checklist A — Une machine, maintenant (15–30 minutes)

1. Confirmer le volume OS : généralement C:, mais vérifiez si Windows est installé ailleurs.
2. Vérifier la liste des points de restauration avec Get-ComputerRestorePoint. Si vide, continuer.
3. Vérifier les clés de stratégie sous HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore.
4. Vérifier le quota du shadow storage avec vssadmin list shadowstorage.
5. Redimensionner le quota à un nombre raisonnable (8–30 Go selon la taille du disque et le taux de changement).
6. Vérifier les writers VSS via vssadmin list writers.
7. Examiner les journaux VSS de la semaine passée. Cherchez des IDs répétitifs comme 8193, 12289, 13.
8. Créer un point de restauration manuel avec Checkpoint-Computer.
9. Relister les points. Si le nouveau existe, la chaîne est rétablie.

Checklist B — Hygiène de flotte (ce que vous standardisez)

1. Définir une politique de rétention des points : cible de quota et fraîcheur minimale attendue (ex. au moins un point dans les 7 derniers jours sur les postes qui le permettent).
2. Fixer des quotas cohérents en fonction de paliers de taille disque. Les quotas ridicules provoquent de la rotation et une fausse confiance.
3. Arrêter la suppression des shadow copies dans les baselines de nettoyage sauf si vous avez une meilleure stratégie de retour arrière et que vous l’assumez.
4. Vérification post-mise à niveau : après les mises à jour de fonctionnalité, confirmez que la protection est activée et créez un nouveau point.
5. Surveiller la santé des writers VSS sur des machines représentatives ; un writer cassé précède souvent des échecs de sauvegarde aussi.
6. Former les playbooks du helpdesk : « Pas de points de restauration » est un état diagnostiquable, pas une malédiction mystique.

Checklist C — Quand les retours arrière doivent absolument fonctionner

1. Ne comptez pas uniquement sur System Restore. Associez-le à de l’imagerie ou une vraie stratégie de sauvegarde si possible.
2. Avant les changements risqués (déploiement de pilotes, agents de sécurité, composants noyau) : créez un point de restauration et vérifiez son existence.
3. Après les changements risqués : confirmez que vous avez toujours des points de restauration et que le shadow storage n’est pas saturé.
4. Garder une réserve d’espace libre. Si C: descend sous 10–15 Go libres sur les builds modernes, vous flirtiez avec l’entropie.

FAQ

1) Pourquoi la Protection du système se désactive-t-elle sans cesse ?

Le plus souvent : stratégie (GPO/MDM), mises à niveau de fonctionnalité qui réinitialisent les paramètres, ou outils tiers d’« optimisation ». Parfois ce n’est pas « désactivé », c’est rendu inutile par un quota trop faible.

2) Les points de restauration sont-ils identiques aux sauvegardes ?

Non. Les points de restauration servent à revenir sur l’état système (pilotes, registre, fichiers système). Ils ne sont pas fiables pour récupérer des données utilisateur ou l’état complet d’un disque.

3) Combien d’espace disque faut-il allouer aux points de restauration ?

Assez pour survivre à la rotation normale : mises à jour, installations de pilotes et changements d’applications. Sur un disque système 256 Go+, 15–30 Go est généralement raisonnable pour des postes qui comptent sur SR. Le bon chiffre dépend du taux de changement et de l’espace libre.

4) Pourquoi les points de restauration disparaissent-ils après une mise à jour Windows ?

Certaines mises à jour créent des points de restauration ; d’autres déclenchent un nettoyage ou consomment suffisamment de shadow storage pour évincer les anciens points. Les mises à niveau majeures peuvent invalider ou supprimer complètement d’anciens snapshots.

5) Nettoyage de disque ou Storage Sense peuvent-ils supprimer les points ?

Oui. Nettoyage de disque peut supprimer des points (souvent en ne conservant que le plus récent). Storage Sense et les comportements en cas d’espace faible peuvent indirectement provoquer l’éviction en mettant la pression sur l’espace disque.

6) J’ai des shadows VSS, mais System Restore n’affiche rien. Pourquoi ?

Les shadows VSS peuvent être créés par des sauvegardes ou pour les « Versions précédentes » sans que System Restore soit activé. System Restore nécessite la Protection du système activée et suit séparément les métadonnées des points.

7) Est-il sûr de déplacer le shadow storage vers un autre lecteur ?

Ça peut l’être, mais cela ajoute de la complexité. Si le volume secondaire est amovible, instable ou fortement utilisé, vous pouvez échanger un mode de panne contre un autre. Si vous le faites, surveillez et documentez la configuration.

8) Que signifie un writer VSS en état « Failed » ?

Cela signifie qu’un composant qui doit quiescer les données pour les clichés est en mauvaise santé. Les points de restauration et les sauvegardes peuvent échouer ou être incomplets. Réparez le service/composant sous-jacent puis revérifiez l’état du writer.

9) Les entreprises doivent-elles désactiver System Restore ?

Uniquement si vous avez une meilleure stratégie de retour arrière qui fonctionne sur de vrais postes sous vraie pression. Désactiver sans alternative, c’est comme enlever la ceinture de sécurité parce qu’on préfère les airbags.

10) Quel est le meilleur test pour confirmer que ça marche ?

Créez un point manuel avec Checkpoint-Computer, confirmez son existence via Get-ComputerRestorePoint, et vérifiez que le shadow storage dispose d’une marge suffisante.

Étapes pratiques suivantes

Si les points de restauration sont absents, cessez de traiter cela comme de la malchance. Il s’agit presque toujours d’une configuration, d’un quota ou de la santé de VSS.

1. Vérifiez la Protection du système pour le volume OS et assurez-vous que la politique ne la désactive pas.
2. Corrigez le quota du shadow storage afin que les points puissent survivre au roulement normal de Windows.
3. Validez l’état des writers VSS et les journaux d’événements ; une pile VSS cassée sabotera points de restauration et sauvegardes.
4. Chassez les comportements de nettoyage qui suppriment les shadow copies, surtout après les patchs.
5. Institutionnalisez une vérification ennuyeuse : « Avons-nous un point de restauration récent ? » Intégrez-la à votre playbook de changement.

Les points de restauration ne sont pas glamour. Windows ne les adore pas non plus. Mais quand vous en avez besoin, vous en avez vraiment besoin. Rendez-les fiablement ennuyeux.