How Volume Shadow Copy Service Powers Windows Backups and Snapshots
The coordination mechanism that lets Windows back up files that are actively open and being written to, without the inconsistency that copying a live, in-use file would otherwise risk.
Backing up a file while it’s actively open and being written to is a genuinely hard problem — copying it directly risks capturing an inconsistent, half-written state, especially for something like a database file that might be mid-transaction at the exact moment a backup tries to read it. Volume Shadow Copy Service (VSS) is the Windows subsystem specifically built to solve this, and it’s the invisible foundation under a surprising amount of Windows functionality beyond just backup software.
The core problem VSS solves
A naive backup approach — simply opening and copying a file’s current bytes — is unreliable for any file being actively modified during the copy. A database engine mid-write, a large document being saved, a virtual machine’s disk file being actively used: copying these directly risks capturing a state that’s inconsistent in a way that makes the backup copy unusable or corrupt, precisely because the file’s content changed partway through the read.
How VSS actually creates a consistent point-in-time view
VSS coordinates between three kinds of participants: a requester (the backup software asking for a shadow copy), providers (typically the Windows-built-in software provider, though hardware storage arrays can implement their own), and writers (application-specific components that know how to bring their own application’s data into a consistent, backup-safe state momentarily). When a shadow copy is requested, VSS briefly pauses new writes to the target volume, signals each registered writer to flush its application to a consistent state, takes the actual point-in-time snapshot, and then immediately resumes normal write activity — the actual pause is typically on the order of a few seconds, not a lengthy interruption.
Writers: how individual applications participate correctly
A VSS writer is an application-specific component that knows how to bring that specific application into a safe, consistent state for the brief snapshot window — SQL Server’s VSS writer, for instance, understands how to momentarily quiesce database write activity and ensure transaction logs are in a consistent state before the snapshot is taken, rather than VSS simply guessing at what “consistent” means for that specific application’s data format. This is why application-aware backup (a SQL Server-aware backup tool coordinating with SQL Server’s writer) produces a genuinely more reliable, immediately restorable backup than simply snapshotting the underlying disk blocks with no application coordination at all.
Copy-on-write: how the snapshot avoids duplicating the entire volume
VSS shadow copies use a copy-on-write mechanism rather than duplicating the entire volume’s data at snapshot time — when a block of data on the live volume is about to be modified after a shadow copy exists, VSS first copies the original, pre-modification version of that block into the shadow copy’s storage area, then allows the modification to proceed on the live volume. This means a shadow copy only actually consumes disk space proportional to how much data has changed since the snapshot was taken, not the full size of the volume being snapshotted — the same fundamental space-efficiency principle behind APFS or ZFS snapshots, applied to NTFS.
Where this shows up beyond dedicated backup software
Several familiar Windows features are directly built on VSS under the hood: File History and previous versions of files (right-clicking a file and choosing “Restore previous versions” is querying VSS shadow copies directly), System Restore’s system-state snapshots, and any third-party backup software’s ability to reliably back up open files and databases. Understanding that these are all the same underlying mechanism explains some otherwise-confusing behavior — disabling System Restore or aggressively limiting shadow storage space affects File History’s available previous versions too, since they’re drawing on the same underlying shadow copies rather than being independent features with separate storage.
Managing shadow storage space directly
vssadmin list shadowstorage
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GBShadow copies consume disk space proportional to changed data since each snapshot, and this space is capped by a configurable limit — running low on shadow storage causes Windows to automatically delete the oldest shadow copies to make room for new ones, which is why a volume with heavy write activity and a small shadow storage allocation might retain far fewer historical restore points than expected, entirely as a consequence of that space cap rather than any explicit retention policy being violated.
Why this design has remained foundational
VSS’s writer-coordination model — letting each application define what “consistent” means for its own data rather than VSS guessing generically — is precisely why application-aware backup tooling built on VSS reliably produces immediately restorable backups of complex, actively-used systems like database servers and virtualization hosts, decades after VSS was first introduced, without requiring those applications to be taken fully offline for the length of a full backup operation.