What Is the Volume Shadow Copy Service?
The Volume Shadow Copy Service (VSS) is a Windows infrastructure component that enables the creation of consistent, point-in-time snapshots of disk volumes without requiring application downtime. Introduced in Windows Server 2003, VSS has been refined through every subsequent release and remains a cornerstone feature in Windows Server 2022. It underpins Windows Server Backup, Azure Backup, Veeam, and virtually every enterprise backup product that runs on Windows.
The core value of VSS is application consistency: when a backup initiates a shadow copy, VSS coordinates with running applications to flush in-memory data to disk and quiesce writes temporarily, ensuring that the captured snapshot reflects a transactionally consistent state. A shadow copy of a SQL Server volume taken through VSS captures the database in a state that can be recovered cleanly, not mid-transaction with corrupted log files.
VSS Architecture: Requestors, Providers, and Writers
VSS has a three-component architecture that coordinates the snapshot process:
VSS Requestors are applications that initiate shadow copy creation. Backup software (Windows Server Backup, Veeam, Acronis, etc.) acts as a requestor. When a backup job starts, the requestor calls the VSS API to create a shadow copy of the target volume(s).
VSS Providers are the components that actually create and maintain the shadow copy. There are two types:
System Provider (Software): Built into Windows, implemented as a kernel-mode driver (volsnap.sys). Creates Copy-on-Write (COW) shadow copies stored in a special area of the volume called the shadow copy storage area (diff area). When a block on the original volume is about to be overwritten, the original block is first copied to the diff area. This ensures the snapshot always reflects the state at the moment of creation.
Hardware Provider: Implemented by storage vendors (SAN/NAS manufacturers). Hardware providers use storage-level snapshot mechanisms (LUN clones, copy-on-write at the storage controller) to create shadow copies far more efficiently than software shadow copies, with zero performance impact and no diff area storage requirements. Hardware providers register with VSS via a COM-based interface.
VSS Writers are application-specific components that ensure their application is in a consistent state before a shadow copy is taken. Each writer has two responsibilities: before the snapshot, it flushes in-memory buffers to disk and temporarily pauses new writes (freeze phase); after the snapshot, it resumes normal write activity (thaw phase). The freeze/thaw window is typically under one second.
Key VSS writers in Windows Server 2022:
System Writer: Protects OS files and the registry.
Registry Writer: Ensures registry hives are flushed to disk.
NTDS Writer: Handles the Active Directory database (NTDS.DIT) on domain controllers.
IIS Metabase Writer: Quiesces IIS configuration.
SqlServerWriter: Coordinates SQL Server database consistency — truncates log if performing VSS full backup.
MSExchangeWriter: Handles Exchange Server database consistency.
WMI Writer: Protects WMI repository data.
Bits Writer: Handles BITS (Background Intelligent Transfer Service) data.
Enabling Shadow Copies on Volumes
Shadow Copies (the Windows feature for Previous Versions / user-facing VSS snapshots) must be explicitly enabled on a per-volume basis. Note that VSS itself is always running as a system service — “enabling shadow copies” specifically refers to configuring the scheduled snapshot feature that creates previous versions accessible to users.
Via command line with vssadmin:
To create a single shadow copy of a volume immediately:
vssadmin create shadow /for=C:To create a shadow copy on a different storage location (storing the diff area on a separate volume for performance):
vssadmin create shadow /for=D: /onvolume=E:Via GUI: Right-click a drive in File Explorer or Disk Management > Properties > Shadow Copies tab. Select the volume, click Enable. The default schedule runs at 07:00 AM and 12:00 PM on weekdays. To modify this, click Settings after enabling and adjust the schedule.
Via PowerShell (WMI): The PowerShell cmdlets for managing scheduled shadow copies interact with the Task Scheduler-based shadow copy task:
# Enable shadow copies with a custom schedule on D: (7 AM and noon weekdays)
# This creates the shadow copy task via WMI
$volume = Get-WmiObject -Class Win32_Volume -Filter "DriveLetter='D:'"
# Create 7 AM shadow copy task
$taskAction = New-ScheduledTaskAction -Execute "C:WindowsSystem32vssadmin.exe" -Argument "create shadow /for=D: /quiet"
$taskTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At "07:00"
Register-ScheduledTask -TaskName "ShadowCopy_D_0700" -Action $taskAction -Trigger $taskTrigger -RunLevel Highest -User "SYSTEM"
# Create noon shadow copy task
$taskTrigger2 = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At "12:00"
Register-ScheduledTask -TaskName "ShadowCopy_D_1200" -Action $taskAction -Trigger $taskTrigger2 -RunLevel Highest -User "SYSTEM"Configuring Shadow Copy Storage
By default, shadow copy storage (the diff area) is located on the same volume being shadowed. For high-write volumes, this can degrade performance and cause shadow copies to be deleted prematurely when space runs low. Best practice is to store shadow copies on a separate, dedicated volume.
Set a custom storage location and maximum size limit:
# Store shadow copies for D: on E:, with a 20 GB maximum size
vssadmin add shadowstorage /for=D: /on=E: /maxsize=20GBTo update an existing shadow storage association:
vssadmin resize shadowstorage /for=D: /on=E: /maxsize=30GBList all current shadow storage associations:
vssadmin list shadowstorageWhen the diff area reaches its maximum size limit, Windows automatically deletes the oldest shadow copies to make room for new ones. Set the limit large enough to retain the desired number of versions. For a volume with 50 GB of data and 5% daily change rate, storing 30 days of shadow copies requires approximately 50GB × 5% × 30 = 75 GB of diff area storage.
Listing and Viewing Shadow Copies
To list all shadow copies on the system:
vssadmin list shadowsTo list shadow copies for a specific volume:
vssadmin list shadows /for=D:The output shows: the Shadow Copy ID (GUID), Shadow Copy Volume (the device name like \?GLOBALROOTDeviceHarddiskVolumeShadowCopy3), the creation time, type (ClientAccessible for user-facing Previous Versions, ClientAccessibleWriters for app-consistent), and the provider.
To access a shadow copy’s contents from the command line, create a symbolic link to the shadow copy device:
# Link shadow copy to a browseable directory
mklink /d C:ShadowMount \?GLOBALROOTDeviceHarddiskVolumeShadowCopy3
# Browse the shadow copy contents
dir C:ShadowMountUsers
# When done, remove the link
rmdir C:ShadowMountPowerShell can enumerate shadow copies via WMI:
Get-WmiObject -Class Win32_ShadowCopy | Select-Object ID, VolumeName, InstallDate, SetID | Format-Table -AutoSizeRestoring Previous Versions
Previous Versions (the user-facing feature backed by VSS shadow copies) allows users to restore individual files or folders to a prior state without involving IT, as long as shadow copies are enabled on the volume.
To restore a file via GUI: Right-click the file or folder in File Explorer > Properties > Previous Versions tab. A list of available versions appears, each with a date/time. Select the desired version and click Restore (overwrites current) or Copy To (saves to an alternate location). The Copy To option is safer for initial assessment.
To restore a previous version from the command line (using shadow copy mount technique):
# Find the shadow copy ID for the volume (D:)
$shadowCopy = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.VolumeName -eq "\?Volume{GUID}" } | Sort-Object InstallDate -Descending | Select-Object -First 1
# Create a mount point
cmd /c mklink /d C:VSS_Mount "$($shadowCopy.DeviceObject)"
# Copy the desired file from the shadow copy
Copy-Item "C:VSS_MountDataReportsQ1-Report.xlsx" -Destination "D:DataReportsQ1-Report-Recovered.xlsx"
# Remove the mount point
cmd /c rmdir C:VSS_MountVSS Writer List and Status
Monitoring VSS writer health is essential for ensuring application-consistent backups. A failed or retrying writer means backup software cannot safely capture that application’s data.
vssadmin list writersEach writer entry shows: Writer Name, Writer Id, Writer Instance Id, State, and Last error. Normal state values are:
[1] Stable: Writer is idle and healthy. This is the expected state between backups.
[5] Waiting for completion: Writer has completed its backup participation and is waiting for the backup to finish.
Problem state values that indicate issues:
[7] Failed: Writer encountered an error. The Last error field provides more detail.
[8] Error: Writer has experienced a fatal error and may not recover without a service restart.
To restart a failed writer, you typically restart the Windows service associated with it:
# Restart the SQL Server VSS Writer service
Restart-Service -Name SQLWriter
# Restart the VSS service itself (resets all writers - use with caution during backup windows)
Restart-Service -Name VSS
# For NTDS writer on a domain controller (restart AD DS services)
Restart-Service -Name NTDSAlways run vssadmin list writers before critical backup operations to confirm all required writers are in [1] Stable state.
Troubleshooting VSS Errors
VSS errors surface in the Windows Application event log, System event log, and in the specific application logs. Key Event IDs:
Event ID 8193 (VSS): Volume Shadow Copy Service error. This is a generic VSS error event that appears when a VSS operation fails. The event description includes the failed operation name and HRESULT error code. Common causes: insufficient disk space for shadow storage, VSS service misconfiguration, or a writer timeout.
# Query for VSS errors in the last 24 hours
Get-WinEvent -LogName Application -FilterXPath "*[System[Provider[@Name='VSS'] and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | Where-Object { $_.Id -in @(8193, 8194, 8004) } | Select-Object TimeCreated, Id, Message | Format-ListEvent ID 12289 (VSS): Indicates a VSS error that occurred during a backup operation. Often caused by a writer returning an error during the freeze phase. The event usually names the writer that failed (e.g., SqlServerWriter, Exchange Writer).
Common VSS troubleshooting steps:
Check disk space for shadow storage:
vssadmin list shadowstorage
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, FreeReset VSS by re-registering DLLs (when VSS state is corrupted — run from elevated command prompt):
net stop vss
net stop swprv
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
net start swprv
net start vssCheck for writer-specific errors (for SqlServerWriter failures, also check SQL Server logs):
Get-WinEvent -LogName Application | Where-Object { $_.ProviderName -eq "MSSQLSERVER" -and $_.LevelDisplayName -eq "Error" } | Select-Object -First 10 TimeCreated, MessageVSS with Backup Products
All enterprise backup products (Windows Server Backup, Veeam, Acronis, Commvault, etc.) use VSS to create application-consistent snapshots. The backup software acts as the VSS Requestor. The typical flow is:
1. Requestor calls VSS API: CreateVssBackupComponents(), InitializeForBackup().
2. VSS notifies all registered writers to prepare (PrepareForBackup event). Writers flush I/O buffers.
3. VSS freezes volume writes (DoSnapshotSet call).
4. Provider creates the shadow copy (software: marks blocks in diff area; hardware: triggers LUN clone).
5. VSS thaws volume writes (PostSnapshot event). Applications resume normal I/O within milliseconds to under a second.
6. Backup software reads data from the shadow copy volume (not the live volume), ensuring a consistent snapshot even while production writes continue.
7. Requestor calls BackupComplete(). VSS writers finalize (e.g., SQL Server writer can truncate transaction logs if backup type is Full and truncation was requested).
8. Shadow copy is deleted after backup software finishes reading from it (for transient backup shadows) or retained for Previous Versions (persistent shadows).
VSS Hardware Providers and SAN Integration
Hardware VSS providers enable storage-level snapshots that are far more performant and scalable than software shadow copies. Storage vendors (NetApp, Dell EMC, HPE, Pure Storage, IBM) provide hardware VSS providers as part of their Windows integration kits (e.g., NetApp SnapDrive, Dell EMC VSS Provider, HPE VSS Provider).
When a hardware provider is installed and a VSS requestor initiates a backup, VSS discovers the hardware provider and delegates the shadow copy creation to it. Instead of a copy-on-write diff area on the volume, the storage controller creates a point-in-time snapshot at the LUN level — typically in milliseconds regardless of LUN size, with no write performance penalty on the source LUN.
To list installed VSS providers (both software and hardware):
vssadmin list providersHardware providers appear with their type listed as Hardware rather than System. For hardware providers to take effect, the volume must be on a LUN managed by the corresponding storage system, and the server must be connected to that storage (FC, iSCSI, or similar).
Hardware VSS integration is especially valuable for large SQL Server or Exchange deployments where the database volumes are tens or hundreds of terabytes — software shadow copies of such volumes are impractical due to diff area storage requirements and performance impact.
VSS for Application-Consistent Backups
The key requirement for application-consistent backup is that every VSS writer associated with the applications on the volume must successfully complete its freeze phase. If any writer fails during freeze, VSS aborts the snapshot attempt and backup software typically logs an error and either retries or marks the job as failed.
To verify that a VSS snapshot will be application-consistent before relying on a backup, perform a test shadow copy and check writer states:
# Test VSS snapshot creation for volume C:
vssadmin create shadow /for=C:
vssadmin list writers
# Check for any non-stable or failed writers immediately after snapshot
vssadmin list writers | Select-String -Pattern "(Failed|Error|Retrying)" For SQL Server specifically, confirm the SqlServerWriter completes successfully. An application-consistent SQL backup via VSS ensures databases are captured in a clean shutdown state (or with deferred recovery possible), meaning you can attach the backed-up database files directly to a SQL instance and they will come online without requiring log recovery from a crash state. This is the difference between an application-consistent backup and a crash-consistent backup (which may require SQL to perform crash recovery on attach, potentially losing committed transactions).
