Share via

Disk Space Misreporting for VSS Shadow Copy Storage Volume Causing False Alerts

Miles Beckjorden 0 Reputation points
2025-12-12T18:02:05.67+00:00

Hello,

We are seeking assistance with an issue on our Windows Server 2019 regarding a disk space reporting discrepancy on a volume dedicated to VSS Shadow Copies. We are unable to account for a large amount of used space, which is preventing new shadow copies from being created and causing our monitoring systems to generate false "low disk space" alerts.

Here is a detailed breakdown of our configuration and the problem:

Objective: We are configuring VSS Shadow Copies for our D: drive.

Storage Location: The shadow copies are configured to be stored on our Y: drive.

Y: Drive Capacity: The total size of the Y: drive is 488 GB.

VSS Maximum Storage: We have set the maximum storage space for shadow copies on the Y: drive to 391 GB (which is 80% of the total volume capacity).

The Issue:

We are observing a significant conflict between the space reported as used by the Shadow Copies service and the space reported as used by Windows File Explorer.

  1. According to the Shadow Copies settings tab, the "Used" space for shadow copies on the Y: drive is currently 127 GB. Screenshot 2025-12-12 114125
  2. However, when viewing the Y: drive in "My Computer" or File Explorer, it shows the drive is almost completely full, with only 1.47 GB of free space remaining. Screenshot 2025-12-12 113540

If the total capacity is 488 GB and VSS is only using 127 GB, there should be approximately 361 GB of free space. Instead, File Explorer indicates that over 486 GB is consumed. This discrepancy is causing our infrastructure monitoring systems to constantly trigger alerts for the Y: drive being critically low on space, creating unnecessary alarm and alert fatigue for our team.

Troubleshooting Steps Already Taken

Rebooted the Server: A full server restart did not correct the space reporting.

Expanded the Drive: We previously expanded the Y: drive to its current size of 488 GB, but the problem has persisted.

Verified VSS Settings: We have confirmed through both the Shadow Copy settings GUI and the vssadmin list shadowstorage command that the settings are configured correctly. Both interfaces consistently report the same usage (127 GB) and limit (391 GB), which confirms the settings are applied but doesn't explain the discrepancy with File Explorer.

Could you please provide guidance on why Windows File Explorer would report the drive as full, while the VSS service itself reports a much lower usage? We need to reclaim this "ghost" space to resolve the false monitoring alerts and ensure our VSS snapshots can continue to be created successfully.

Hello,

We are seeking assistance with a critical issue on our Windows Server regarding a disk space reporting discrepancy on a volume dedicated to VSS Shadow Copies. We are unable to account for a large amount of used space, which is preventing new shadow copies from being created and causing our monitoring systems to generate false "low disk space" alerts.

Here is a detailed breakdown of our configuration and the problem:

Objective: We are configuring VSS Shadow Copies for our D: drive.

Storage Location: The shadow copies are configured to be stored on our Y: drive.

Y: Drive Capacity: The total size of the Y: drive is 488 GB.

VSS Maximum Storage: We have set the maximum storage space for shadow copies on the Y: drive to 391 GB (which is 80% of the total volume capacity).

The Issue:

We are observing a significant conflict between the space reported as used by the Shadow Copies service and the space reported as used by Windows File Explorer.

According to the Shadow Copies settings tab, the "Used" space for shadow copies on the Y: drive is currently 127 GB.

However, when viewing the Y: drive in "My Computer" or File Explorer, it shows the drive is almost completely full, with only 1.47 GB of free space remaining.

This creates a contradiction and a significant operational problem. If the total capacity is 488 GB and VSS is only using 127 GB, there should be approximately 361 GB of free space. Instead, File Explorer indicates that over 486 GB is consumed. This discrepancy is causing our infrastructure monitoring systems to constantly trigger alerts for the Y: drive being critically low on space, creating unnecessary alarm and alert fatigue for our team.

Troubleshooting Steps Already Taken

Before reaching out, we have performed the following actions, none of which have resolved the issue:

Rebooted the Server: A full server restart did not correct the space reporting.

Expanded the Drive: We previously expanded the Y: drive to its current size of 488 GB, but the problem has persisted.

Verified VSS Settings: We have confirmed through both the Shadow Copy settings GUI and the vssadmin list shadowstorage command that the settings are configured correctly. Both interfaces consistently report the same usage (127 GB) and limit (391 GB), which confirms the settings are applied but doesn't explain the discrepancy with File Explorer.

Why Windows File Explorer would report the drive as full, while the VSS service itself reports a much lower usage? We need to reclaim this space to resolve the false monitoring alerts and ensure our VSS snapshots can continue to be created successfully.

Windows for business | Windows Server | Devices and deployment | Other

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 35,285 Reputation points Independent Advisor
    2025-12-14T17:56:36.8166667+00:00

    Hi Miles Beckjorden,

    I am following up to see if the vssadmin resize shadowstorage command successfully forced the reclamation of the ghost space on your Y: drive. If that solution resolved the discrepancy and your monitoring alerts have ceased, please take a moment to mark the answer as accepted so we can close this case.

    However, if you executed the resize command and Windows Explorer still reports the drive as full, despite VSS confirming a 1GB limit, we need to investigate a potential mismatch in the NTFS Master File Table (MFT) or the volume bitmap. It is possible that the file system itself has lost track of the free clusters, causing the operating system to report space as "allocated" when it is actually empty. To verify this without taking the volume offline, please open an elevated Command Prompt and run chkdsk Y: /scan. This command will perform an online analysis of the file system logic and the $Bitmap metadata file. If chkdsk reports errors such as "Volume Bitmap is incorrect" or "Free space marked as allocated," you will need to schedule a maintenance window to run chkdsk Y: /f to repair the volume structure and correct the free space reporting.

    Additionally, if chkdsk returns no errors, there is a possibility that a non-VSS system file within the System Volume Information folder has grown uncontrollably. A common culprit on older volumes is the Distributed Link Tracking log (tracking.log). Since standard permissions prevent you from seeing inside this folder, you should run a disk usage analyzer tool (like TreeSize Free) specifically as Administrator. If you identify a massive tracking.log, you can safely stop the "Distributed Link Tracking Client" service and delete that specific log file to reclaim the space.

    VP

    Was this answer helpful?

    0 comments
  2. VPHAN 35,285 Reputation points Independent Advisor
    2025-12-12T20:38:23.18+00:00

    Hi Miles Beckjorden,

    The discrepancy you are seeing between vssadmin reporting 127 GB used and Windows File Explorer showing the drive as full is a classic symptom of "orphaned" shadow copy data or an unreclaimed "high-water mark" within the System Volume Information folder. While the Volume Shadow Copy Service (VSS) believes it is only tracking 127 GB of live snapshots, the physical container on the Y: drive (the System Volume Information directory) has allocated blocks that it has not released back to the NTFS file system. This often occurs after a disk expansion, which you mentioned performing, where the VSS bitmap does not automatically realign with the new geometry, or if a previous backup job terminated unexpectedly, leaving data chunks that are no longer indexed by VSS but still consume physical disk space.

    To resolve this and reclaim the "ghost" space immediately, you need to force the VSS driver to purge the storage area container. The most reliable method to do this without breaking the association is to temporarily resize the shadow storage to a minimal value. Open an elevated Command Prompt and execute vssadmin resize shadowstorage /For=D: /On=Y: /MaxSize=1GB. This command forces the system to aggressively delete both visible and orphaned shadow copies to comply with the new, tiny 1GB limit, triggering the garbage collection process for the System Volume Information folder.

    Once you execute that command, check File Explorer; you should see the free space on the Y: drive jump up significantly, likely reclaiming nearly all the 486 GB. After confirming the space is reclaimed, you can safely set the configuration back to your desired policy by running vssadmin resize shadowstorage /For=D: /On=Y: /MaxSize=391GB. This resets your 80% buffer limit while leaving the drive clean for new snapshots.

    If the resize command does not clear the space, it is possible that the System Volume Information folder contains non-VSS data, such as old Deduplication chunks or localized backup catalogs. You cannot view the size of this folder accurately in Explorer by default due to permissions. I recommend running a tool like TreeSize Free as Administrator to inspect the contents of the Y: root. However, based on your description and the screenshot provided, the resize toggle method described above is the standard "best practice" fix for re-syncing the VSS accounting with the NTFS file system reporting.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VPHAN

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.