Volume Shadow Copy Service — How Shadow Copies Actually Work

What Is Volume Shadow Copy Service?

Volume Shadow Copy Service (VSS) is the Windows component that coordinates the creation of a consistent, point-in-time copy of a volume — commonly called a shadow copy or a snapshot — while the volume is still live and applications are still writing to it. It shipped first in Windows XP and Windows Server 2003, and it underpins nearly every backup and restore feature Windows has had since.

Think of VSS as a very brief, very well-coordinated pause button. A naive copy of files on a running server captures data mid-write: a database with a half-committed transaction, a mailbox with a message half-delivered. VSS solves that by asking every application that cares to finish its current unit of work, freeze writes for a moment, and only then does the actual copy happen — all inside a window measured in seconds.

VSS itself does not do any of the freezing or copying. It is the coordinator that sits between three other components: the requestor that asks for the shadow copy, the writer that makes the application’s data consistent, and the provider that actually creates the shadow copy on disk.

How a Shadow Copy Is Actually Created

The sequence below is what happens, in order, every time something asks Windows for a shadow copy — whether that something is Windows Server Backup, a SQL Server-aware backup agent, or a plain vssadmin create shadow from the command line.

The requestor asks VSS to enumerate the writers on the system and gather their metadata. Each writer responds with an XML description of what it needs backed up and how it should be restored. VSS then tells every writer to prepare — completing open transactions, rolling logs, flushing caches — and once every writer reports ready, VSS freezes application write I/O across the volume. Read I/O keeps working; only writes pause. The provider is told to create the shadow copy during that freeze, and as soon as it commits, VSS releases the freeze and writers resume normal writes.

That timing constraint is why a busy SQL Server or Exchange instance can occasionally fail a VSS snapshot under heavy load — the writer cannot finish preparing fast enough inside the freeze window, not because VSS itself is slow.

Complete Copy, Copy-on-Write, and Redirect-on-Write

A shadow copy provider — hardware or software — builds the actual point-in-time copy using one of three methods. The built-in Windows software provider (swprv.dll and the volsnap.sys driver) uses copy-on-write; SAN hardware providers often use one of the other two.

For the system provider’s copy-on-write method, that storage area is called the shadow copy storage area, or diff area. It must live on an NTFS volume, though the volume being shadow-copied doesn’t itself need to be NTFS — Windows just needs at least one NTFS volume mounted somewhere to host the diff area. This is also why a shadow copy is not a second full copy of a volume’s data: it is the original data plus an index of the blocks that changed since the snapshot, reconstructed on read.

Where Windows Actually Uses VSS

VSS is infrastructure, not a feature end users interact with directly. A handful of Windows features sit on top of it, and each one is really just a different requestor with its own idea of what to do with the shadow copy once it exists.

Windows Server Backup is a VSS requestor that turns a shadow copy into a VHD-format backup image, with the NTDS writer making sure a domain controller’s Active Directory database is flushed and consistent before the snapshot is taken. Shadow Copies of Shared Folders is a separate requestor built into the file server role that takes scheduled, client-accessible shadow copies of a whole volume so users can recover an earlier version of a file from a network share themselves, through the Previous Versions tab, without calling the help desk. System Restore on Windows client editions uses VSS the same way, to create system-level restore points before risky changes like driver or update installs. Nearly every third-party backup product for Windows — Veeam, Commvault, and the rest — is also just a VSS requestor with its own storage target.

Enabling Shadow Copies of Shared Folders

Shadow Copies of Shared Folders is not a separate installable role — it rides on the file server capabilities every Windows Server already has, and is turned on per volume rather than per share. You cannot pick individual folders on a volume to include or exclude; enabling it applies to everything on that volume.

In the GUI, open Computer Management, right-click Shared Folders, choose All Tasks → Configure Shadow Copies, select the volume, and click Enable. The same dialog is reachable from a volume’s own Properties → Shadow Copies tab in File Explorer. From there you can also set a custom schedule and a storage limit on the Settings button.

Scripts / Commands

vssadmin is the everyday tool for shadow copies created by the built-in system provider. diskshadow is the more capable interactive/scriptable tool, and it is the one to reach for when a shadow copy is not “client-accessible” and vssadmin refuses to touch it. Both require an elevated prompt and, for diskshadow, local Administrators group membership.

# --- INSPECTING VSS STATE ---

# List every VSS writer on the system and its current state (Stable, Waiting for completion, Failed, etc.)
vssadmin list writers

# List all registered shadow copy providers (system, and any hardware/SAN providers installed)
vssadmin list providers

# List every existing shadow copy on the system
vssadmin list shadows

# List shadow copies for a specific volume only
vssadmin list shadows /for=C:

# --- CREATING AND DELETING SHADOW COPIES ---

# Create a manual shadow copy of volume C: using the system provider
vssadmin create shadow /for=C:

# Delete only the oldest shadow copy of volume C:
vssadmin delete shadows /for=C: /oldest

# Delete every shadow copy of volume C: without a confirmation prompt
vssadmin delete shadows /for=C: /all /quiet

# --- MANAGING SHADOW COPY STORAGE (THE DIFF AREA) ---

# Cap shadow copy storage for C: at 900MB, stored on D:
vssadmin resize shadowstorage /for=C: /on=D: /maxsize=900MB

# Remove the storage cap entirely
vssadmin resize shadowstorage /for=C: /on=D: /maxsize=UNBOUNDED

# --- DISKSHADOW, FOR EVERYTHING VSSADMIN CAN'T TOUCH ---

# Launch the interactive diskshadow console
diskshadow

# Or run a saved script non-interactively (note: -s, not /s)
diskshadow -s C:\scripts\snapshot.dsh

A minimal diskshadow script that takes a persistent, application-consistent shadow copy of two volumes and exposes them as drive letters for a backup job to read from:

# snapshot.dsh - persistent shadow copy of C: and D:, exposed for backup
set context persistent nowriters
set metadata C:\diskshadowdata\example.cab
set verbose on

begin backup
add volume C: alias systemvolumeshadow
add volume D: alias datavolumeshadow

create

expose %systemvolumeshadow% P:
expose %datavolumeshadow% Q:
exec C:\diskshadowdata\backupscript.cmd
end backup

There is no dedicated PowerShell module for VSS the way there is for Windows Server Backup — shadow copy management from PowerShell goes through the Win32_ShadowCopy WMI/CIM class instead.

# List existing shadow copies via CIM (the modern replacement for Get-WmiObject)
Get-CimInstance -ClassName Win32_ShadowCopy |
    Select-Object ID, VolumeName, InstallDate, ClientAccessible

# Create a new client-accessible shadow copy of C:\ via the class's static Create method
Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create `
    -Arguments @{ Volume = 'C:\'; Context = 'ClientAccessible' }

# Confirm the volume you're about to target before running any of the above
Get-Volume -DriveLetter C

Version Boundaries and What Changed

Troubleshooting Cheat Sheet

Final Thoughts

VSS is one of those Windows components that is easy to take for granted precisely because it works quietly in the background of features that get all the attention — backup jobs, restore points, that “Previous Versions” tab nobody thinks about until they need it. Understanding the requestor/writer/provider split, and the hard 60-second freeze and 10-second commit limits underneath it, turns a mysterious VSS error in a backup log into a component you can actually diagnose: is it the requestor asking for the wrong thing, a writer that couldn’t get ready in time, or a provider that ran out of storage.

Windows Server Backup is the most common place engineers run into VSS directly, since every system state and bare-metal backup it takes is a VSS operation end to end — the requestor/writer/provider model in this post is exactly what is happening under the hood when that backup job runs.