Windows Server 2016 : libérer l’espace disque occupé par System Volume Information (VSS, Shadow Copies)

Sur un volume de ~1,8 To sous Windows Server 2016, seuls 66 Go libres alors que ~400 Go de fichiers sont visibles ? Le dossier System Volume Information gonflé par VSS est le coupable typique. Voici comment diagnostiquer, nettoyer et prévenir durablement.

Sommaire

Vue d’ensemble de la situation

Un serveur Windows Server 2016 Standard expose un partage de fichiers hébergé sur un volume de données proche de 1,8 To. L’explorateur et les outils de base n’affichent qu’environ 66 Go libres alors que la somme des fichiers visibles n’approche que ~400 Go. Le contrôle d’erreurs disque n’indique rien d’anormal. Les premières analyses avec TreeSize n’ont rien montré, jusqu’à ce que l’outil soit exécuté au niveau SYSTEM sur la racine du volume, révélant un System Volume Information (SVI) gigantesque. L’interface « Restauration du système » n’est pas disponible sur ce serveur, ce qui amène une question simple : comment récupérer l’espace occupé par SVI ?

Diagnostic le plus probable

Sur Windows Server, l’espace consommé dans SVI provient très souvent de clichés instantanés VSS (Shadow Copies) créés par la sauvegarde, un test ponctuel ou un paramétrage ancien. Même si l’onglet « Copies Shadow » des propriétés du volume n’est plus activé, des clichés peuvent subsister et occuper de larges quantités d’espace, car leur stockage (shadowstorage) demeure réservé.

Procédure recommandée

Mesurer précisément ce qui occupe la place

Visualiser SVI dans TreeSize en contexte SYSTEM (indispensable pour voir le contenu réel) :

psexec -s -i "C:\Chemin\TreeSize.exe"

Dans TreeSize, analysez la racine du volume (ex. E:\). Vous verrez alors la taille réelle du dossier System Volume Information et, le cas échéant, d’autres sous-dossiers techniques (Dedup, DFSR, etc.).

Interroger VSS depuis la ligne de commande pour connaître l’allocation et l’état des clichés :

vssadmin list shadowstorage /for=E:
vssadmin list shadows /for=E:

list shadowstorage affiche trois valeurs clefs : Used (utilisé), Allocated (réservé) et Maximum (limite). Si Used ou Allocated est très élevé, vous détenez la cause de l’espace manquant.

Supprimer les clichés VSS du volume

Méthode 1 – vssadmin (rapide)

vssadmin delete shadows /for=E: /all /quiet

Méthode 2 – diskshadow (outil intégré)

diskshadow
delete shadows volume E:
exit

Attention : ces commandes suppriment tous les clichés du volume. Assurez‑vous qu’aucune sauvegarde ni restauration attendue ne dépend de ces clichés. Sur des serveurs de fichiers, la suppression est généralement sans impact sur des sauvegardes modernes (l’outil de sauvegarde refera ses clichés), mais validez la stratégie de rétention avant d’exécuter la purge.

Limiter ou neutraliser la réapparition

Si VSS n’est pas requis sur ce volume, vérifiez depuis les Propriétés du volume → onglet Copies Shadow que la fonctionnalité n’est pas activée. Laissez-la désactivée.
Si VSS est utile (restauration de versions de fichiers, sauvegardes à chaud), caper la taille réservée :

vssadmin resize shadowstorage /for=E: /on=E: /maxsize=10%

Vous pouvez remplacer 10% par une taille explicite (100GB par exemple) ou UNBOUNDED (à éviter). Un plafond de 5 à 15 % est souvent un bon compromis sur des partages de fichiers.

Vérifications utiles après nettoyage

fsutil volume diskfree E:
vssadmin list shadowstorage /for=E:

Confirmez que l’espace libre reflète la réalité. Relancez TreeSize (en SYSTEM) pour valider que System Volume Information est revenu à une taille raisonnable.

Tableau d’aide au diagnostic

Symptôme observé	Test recommandé	Commande / Action	Interprétation & suite
Fichiers visibles < 500 Go mais < 100 Go libres	Mesurer SVI et VSS	`vssadmin list shadowstorage /for=E:`	Si Used/Allocated > plusieurs centaines de Go : clichés VSS volumineux → supprimer puis plafonner.
TreeSize « ne voit rien » d’anormal	Lancer TreeSize en SYSTEM	`psexec -s -i TreeSize.exe`	En SYSTEM, SVI apparaît. Sans SYSTEM, SVI est masqué par l’ACL.
SVI contient « Dedup » très gros	Vérifier Data Deduplication	`Get-WindowsFeature FS-Data-Deduplication` `Get-DedupStatus -Volume E:`	La chunk store de la dédup consomme de l’espace : agir avec les jobs dédiés (voir plus bas).
SVI contient « DFSR » imposant	Contrôler DFS Replication	Vérifier les quotas de staging / base DFSR	Adapter le quota de staging ou l’architecture DFSR si nécessaire.
Volume non système avec pagefile	Contrôler la mémoire virtuelle	Panneau → Système → Avancé → Mémoire virtuelle	Supprimer le pagefile du volume de données si non requis.
Corbeille volumineuse par utilisateur	Purger `$Recycle.Bin`	`rd /s /q E:\$Recycle.Bin`	Récupère rapidement l’espace si la corbeille était pleine.

Pourquoi System Volume Information grossit

System Volume Information est un dossier spécial à la racine de chaque volume NTFS. Il héberge notamment :

Les clichés VSS (métadonnées et données différentielles).
La chunk store de Data Deduplication si le rôle est installé/activé.
Les bases et staging DFS Replication sur les volumes participant à DFSR.
Le journal USN, l’index de Windows Search, et d’autres métadonnées NTFS.

Quand VSS est configuré (volontairement ou via un logiciel de sauvegarde), il réserve un espace (shadowstorage) dans lequel s’accumulent les blocs modifiés à mesure que les clichés se succèdent. Sur un volume de fichiers actifs (grosses suppressions, réorganisations, copier/coller), cet espace peut croître très vite. Si la limite est trop haute (ou illimitée), VSS consommera l’espace jusqu’à provoquer une alerte « disque presque plein » alors que les fichiers « utiles » ne représentent qu’une fraction du volume.

Scénarios de nettoyage en fonction des cas

Cas le plus fréquent : clichés VSS orphelins ou sans limite

Lister l’allocation avec vssadmin list shadowstorage /for=E:.
Supprimer tous les clichés avec vssadmin delete shadows /for=E: /all /quiet.
Plafonner la réserve : vssadmin resize shadowstorage /for=E: /on=E: /maxsize=10%.
Vérifier l’espace libéré : fsutil volume diskfree E:.

Cas Data Deduplication

Si FS-Data-Deduplication est installé, la majorité de l’espace de SVI peut provenir de la chunk store (c’est normal). Pour contrôler :

Get-WindowsFeature FS-Data-Deduplication
Get-DedupStatus -Volume E:

Après de grosses suppressions ou une migration, lancez des jobs afin de récupérer l’espace :

# Réévaluation &amp; collecte des objets obsolètes
Start-DedupJob -Volume E: -Type Optimization
Start-DedupJob -Volume E: -Type GarbageCollection

Important : n’intervenez ici que si la déduplication est réellement utilisée dans votre stratégie. Ne supprimez pas manuellement le contenu de SVI : passez par les cmdlets dédiés.

Cas DFS Replication (DFSR)

Lorsqu’un volume participe à DFSR, SVI contient une base et un staging. Si l’activité est intense (gros fichiers modifiés), le staging peut gonfler. Ajustez les quotas de staging (via la gestion DFS) et dimensionnez vos réplicas pour éviter les saturations.

Cas pagefile, indexation, USN

Pagefile : ne placez pas de fichier d’échange sur un volume de données de partage, sauf besoin précis. Utilisez le disque système ou un disque dédié performant.
Indexation/Windows Search : sur des serveurs de fichiers, l’indexation peut être limitée à ce qui est utile. Réduire l’index baisse parfois la pression sur SVI.
Journal USN : composant NTFS normal, sa taille reste modérée sauf cas particuliers.

Bonnes pratiques pour éviter la récidive

Plafonner systématiquement l’espace VSS sur les volumes de données (5–15 %).
Nettoyer périodiquement les clichés anciens via une tâche planifiée si VSS est utilisé pour la restauration de versions.
Paramétrer les outils de sauvegarde pour qu’ils n’augmentent pas indéfiniment la réserve VSS et qu’ils purgent leurs clichés après usage (notamment en cas d’échec).
Surveiller SVI avec un script simple qui alerte lorsque Used dépasse un seuil.
Limiter les opérations massives (copier/supprimer des millions de fichiers en une fois) hors fenêtres de snapshots, ou forcer un nettoyage après coup.

Exemple de script de contrôle (PowerShell)

$volume = "E:"
$thresholdGB = 300
$shadowInfo = (&amp; vssadmin list shadowstorage /for=$volume) -join "`n"
if ($shadowInfo -match "Used Shadow Copy Storage space:\s+([0-9\.,]+)\s+GB") {
    $used = [double]$matches[1]
    if ($used -gt $thresholdGB) {
        Write-Output ("Alerte: VSS utilise {0} GB sur {1}" -f $used, $volume)
        # Ici: envoyer un mail, écrire dans l'EventLog, etc.
    } else {
        Write-Output ("OK: VSS utilise {0} GB sur {1}" -f $used, $volume)
    }
} else {
    Write-Output "Impossible de parser la sortie VSSADMIN."
}

Foire aux questions

Pourquoi je ne vois pas SVI même en administrateur ?

Les ACL de SVI restreignent l’accès aux comptes système. TreeSize (ou tout autre explorateur de taille) doit être exécuté en SYSTEM pour afficher fidèlement son contenu.

Supprimer SVI manuellement est‑il dangereux ?

Oui. Ne supprimez ni ne modifiez directement SVI. Utilisez les outils dédiés : vssadmin, diskshadow, cmdlets de déduplication, gestion DFSR. La suppression « à la main » peut corrompre des métadonnées et n’est pas supportée.

« Restauration du système » n’existe pas sur mon serveur. Est-ce normal ?

Oui. Sur Windows Server, on ne gère pas la restauration client mais VSS. L’absence de l’onglet « Protection du système » est normale. L’onglet pertinent est Copies Shadow dans les propriétés du volume.

Quelle taille de réserve VSS choisir ?

Sur des partages de fichiers classiques, un plafond de 5–15 % du volume suffit souvent. Si vous proposez la « Restauration des versions précédentes » aux utilisateurs, ajustez selon la rétention souhaitée et la volatilité des données.

Mon logiciel de sauvegarde utilise VSS : puis‑je supprimer les clichés ?

Oui, mais planifiez‑le : la plupart des sauvegardes se contentent de clichés éphémères. Si des clichés persistent, c’est souvent le signe d’échecs ou d’une configuration qui n’a pas purgé. Supprimez les clichés puis vérifiez la configuration des jobs.

Checklist d’intervention rapide

Exécuter TreeSize en SYSTEM sur E:\, confirmer la taille de SVI.
Vérifier l’allocation VSS : vssadmin list shadowstorage /for=E:.
Supprimer les clichés : vssadmin delete shadows /for=E: /all /quiet.
Plafonner la réserve : vssadmin resize shadowstorage /for=E: /on=E: /maxsize=10%.
Contrôler l’espace réel : fsutil volume diskfree E:.
Valider les rôles voisins : déduplication (Get-DedupStatus), DFSR, pagefile, indexation.
Mettre en place la surveillance (script ou supervision).

Commandes utiles (récapitulatif)

:: Inspecter VSS
vssadmin list shadowstorage /for=E:
vssadmin list shadows /for=E:

\:: Supprimer tous les clichés du volume
vssadmin delete shadows /for=E: /all /quiet

\:: ou via diskshadow
diskshadow
delete shadows volume E:
exit

\:: Limiter l’espace VSS (ex. 10 %)
vssadmin resize shadowstorage /for=E: /on=E: /maxsize=10%

\:: Vérifier l’espace disque réel
fsutil volume diskfree E:

\:: Déduplication (si installée)
Get-WindowsFeature FS-Data-Deduplication
Get-DedupStatus -Volume E:
Start-DedupJob -Volume E: -Type Optimization
Start-DedupJob -Volume E: -Type GarbageCollection

\:: Purger la Corbeille du volume
rd /s /q E:\$Recycle.Bin

Exemple d’investigation de bout en bout

Constat : l’explorateur affiche 66 Go libres sur 1,8 To alors que le total des dossiers visibles est ~400 Go.
Hypothèse : clichés VSS volumineux.
Preuve : vssadmin list shadowstorage /for=E: retourne Used ≈ 1,2 To, Allocated ≈ 1,3 To, Maximum = 1,5 To.
Action : suppression des clichés (vssadmin delete shadows /for=E: /all /quiet).
Prévention : vssadmin resize shadowstorage /for=E: /on=E: /maxsize=10%.
Résultat : fsutil volume diskfree E: remonte ~1,4 To libres. TreeSize montre un SVI < 10 Go.

Précisions d’implémentation et pièges à éviter

Incohérences d’affichage : après une grosse purge VSS, l’explorateur peut retarder l’actualisation. Utilisez fsutil ou relancez l’explorateur pour constater la libération.
Snapshots en cours d’usage : ne purgez pas VSS pendant une sauvegarde active. Attendez la fin du job.
Limite trop basse : un plafond VSS minuscule peut engendrer des échecs de clichés et des journaux d’erreurs. Ajustez prudemment.
Droits : évitez toute modification directe des ACL de SVI. Utilisez des outils supportés.
Unités d’allocation NTFS : lors d’un reformatage de « remise à plat », choisissez une taille d’unité adaptée à vos fichiers (par ex. 64 K pour de gros fichiers) afin d’optimiser la fragmentation et les performances.

Dernier recours : remise à plat contrôlée

Si un doute persiste ou si le volume cumule des couches vieillissantes (VSS, dédup, réplicas), envisagez une migration contrôlée :

Copiez les données vers un support temporaire :

robocopy E:\ X:\ /MIR /R:1 /W:1 /COPY:DATSO /DCOPY:T /MT:16 /LOG+:C:\Temp\robocopy.log

Formatez E: en NTFS avec la taille d’unité d’allocation adéquate.
Recopiez les données depuis X: et restaurez les partages/ACL.

Cette approche réinitialise intégralement SVI et élimine les « fantômes » de configurations passées, au prix d’une fenêtre d’indisponibilité à planifier.

Conclusion

Le décalage « fichiers visibles ≈ 400 Go » vs « espace libre ≈ 66 Go sur 1,8 To » est caractéristique d’un System Volume Information hypertrophié, le plus souvent à cause de clichés VSS non maîtrisés. La recette gagnante tient en quatre temps : mesurer (TreeSize en SYSTEM + vssadmin list), supprimer les clichés obsolètes, plafonner strictement la réserve VSS, puis vérifier et surveiller. Les cas particuliers (déduplication, DFSR, pagefile, Corbeille) doivent être évalués selon le rôle du serveur. En suivant cette méthode, vous récupérez immédiatement l’espace manquant et évitez la récidive.

Windows Server 2016 : libérer l’espace disque occupé par System Volume Information (VSS, Shadow Copies)