Volume Shadow Copy (VSS): The Mechanism and the Practice — Why Backup Software Can Copy Files That Are Still in Use

“I tried to copy a file another application had open, and got told the process cannot access the file because it is being used by another process.” “We were asked to back up the data folder without stopping the core system.” “Why can backup software calmly copy a database file that’s in use?” — Whether you develop business applications or run file servers, these are questions you run into sooner or later.

At the centre of the answer is the Volume Shadow Copy Service (VSS). It has been built into Windows for more than twenty years, and Windows Server Backup, System Restore, and virtually every commercial backup product all sit on this same foundation.¹

This article is aimed at business-application developers who are asked to add “copy a file that’s in use” functionality, and at IT staff who operate backups of file servers and business PCs. Drawing on primary sources as of August 2026, it sets out VSS’s cast of characters and how it works, the day-to-day practice of operating it with vssadmin, and where the line should sit on how far a developer should get involved with VSS. The “Depths of Windows I/O” series looked inside the Cache Manager and NTFS; this article is its sequel, covering the “snapshot” layer that sits directly above the volume.

1. The Bottom Line First

• VSS is a set of COM interfaces and a coordinating service that make it possible to back up a volume while an application keeps writing to it. It has been built into Windows since Windows XP.²
• There are three roles plus a coordinator. The VSS service mediates between the requester that asks for a shadow copy (backup software), the writer that guarantees data consistency on the application side (SQL Server, for example), and the provider that actually creates the snapshot.¹
• Windows’ standard system provider uses copy-on-write. Rather than duplicating the entire volume, it moves only the blocks that get overwritten after the snapshot — and only their pre-write content — into a diff area. The diff area has to sit on an NTFS volume.¹
• A point of consistency is created through “freeze the writers (up to 60 seconds) → create the snapshot (within 10 seconds) → thaw.” If either time limit is exceeded, creation is aborted and the requester tries again.¹
• Whether a writer cooperates changes the quality of the copy. A snapshot taken without a writer’s cooperation is equivalent to “the disk at the instant the power was cut” (crash consistent); one taken with cooperation has already had logs rolled and caches flushed, leaving a consistent state that the application itself guarantees is recoverable (application consistent).³¹
• vssadmin is the tool for checking operational state. Use list shadows / list writers / list shadowstorage to see the current state, and resize shadowstorage to adjust the diff area’s limit. When the diff area runs out, the oldest shadow copies are silently deleted.⁴⁵¹
• Building a VSS requester into your own application is a substantial undertaking. It’s a COM-based native API with no official .NET wrapper. In most cases, retries, adjusting the share mode, or a short stoppage are enough; if VSS really is needed, scripting DiskShadow is the practical answer (Windows Server only).⁶⁷
• A shadow copy is not itself a backup. Because the copy-on-write differential depends on the intact blocks of the original volume, it offers no protection against a failure that takes out the original volume entirely, such as a disk failure or theft. It can’t be relied on against ransomware either, because shadow copies themselves can be deleted (Section 7.3) or the diff area can be exhausted by mass rewrites (Section 7.4). It only becomes meaningful when combined with backups kept on separate media.¹

2. Setting Up the Problem — Why Can’t a File in Use Just Be Copied Normally?

The starting point is Windows’ file sharing mode. When you open a file in Windows (CreateFile), you declare, as the share mode (dwShareMode), what you will allow other processes to do while you have it open. While a process is holding the file open in a way that does not permit read sharing, any process that later tries to open it for reading fails with a sharing violation (ERROR_SHARING_VIOLATION, error 32).⁸ In .NET this is the familiar IOException (“The process cannot access the file because it is being used by another process”).

The important point is that this is not a bug, but the correct mechanism for protecting data. If a file being written to is read partway through, the reader ends up with a half-finished, in-progress state. As covered in detail in “Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims”, the design of mutual exclusion is the foundation of integration between applications.

But this correct mechanism runs fundamentally at odds with backup.

• The sharing-violation wall: a file that a database or business application keeps open may not even be openable as a copy source in the first place.
• The consistency wall: even if you can open it (because read sharing is permitted), copying takes time. Because the application keeps writing while the copy is in progress, the first and second halves of the file can end up reflecting different points in time, or multiple files (the data file and its log, say) can end up out of step with each other. And as we saw in the “Cache Manager” instalment, a write lands in the in-memory cache first, so looking only at the file on disk doesn’t guarantee you’re seeing the latest content.
• The operational wall: “then just stop the application and copy it” is a reasonable answer in principle, but it isn’t acceptable for a business system or file server that runs around the clock.

In other words, what’s actually wanted is “a copy of a single, consistent instant, without stopping the application.” That’s too much for individual applications to solve on their own, so VSS was built as an OS-level mechanism to provide it. VSS is offered as a COM-interface framework that makes it possible to back up a volume even while an application keeps writing to it.²

3. VSS’s Cast of Characters — Requester, Writer, Provider

VSS’s structure breaks down into three roles and the service that mediates between them.¹

The elegance of this division of labour is that products which know nothing about each other can still cooperate. The backup software (the requester) knows nothing about SQL Server’s internal structure, but SQL Server’s writer declares, as metadata, which files (components) need to be backed up, and puts its own data in order immediately around the point of consistency — so the requester can take a consistent backup simply by following that lead.¹⁹ Nearly every third-party backup product that runs on Windows is a VSS requester.¹

In IT operations, the moment you actually need to think about these three roles is troubleshooting. Whether a backup failure is a problem with the requester (the software side), a specific writer (the application side), or the provider / diff area (the infrastructure side) changes entirely where you should be looking (Sections 5 and 7).

4. How Snapshots Work — Copy-on-Write and the “Point of Consistency”

4.1. Copy-on-Write — Preserving “That Instant” Without Duplicating the Volume

Hearing the word “snapshot” makes you imagine duplicating the whole volume, but the method Windows’ standard system provider actually uses is copy-on-write. At the moment the snapshot is taken, almost nothing is copied. Later, when a block on the original volume is about to be overwritten, the pre-write content of that block is moved into the diff area (the shadow copy storage) before the overwrite completes, and only then is the write allowed through.¹ The move only has to happen the first time each block is overwritten; overwriting a block that has already been moved does not grow the diff area any further.

To read “the volume as it was at that instant”, the blocks that haven’t changed are read from the original volume, and the blocks that have changed are read from the diff area, and the two are combined. Because only the changed portion is ever copied, creation is instantaneous and the space it consumes is only the differential. The flip side is that the more heavily a volume is written to, the faster the diff area is consumed (foreshadowing Section 7), and the diff area sits on an NTFS volume on the same machine as the source data.¹ What underpins this mechanism is the system provider’s component file, swprv.dll, and the driver that intercepts a volume’s I/O, volsnap.sys.¹ If you’re interested in the “how” of intercepting the I/O stack, see also “Filter Drivers and Minifilters”.

There are also other methods: full copy, which splits off a mirror, and redirect-on-write, which writes changes to a separate volume; hardware providers use whichever method suits the storage array best.¹

4.2. The Flow of Creating a Point of Consistency — 60 Seconds to Freeze, 10 Seconds to Create

If copy-on-write is about how the data is preserved, VSS’s real value lies in which moment’s state gets preserved — in other words, how the point of consistency is created. Shadow copy creation proceeds as follows.¹

flowchart TB
    R["Requester asks for creation<br/>enumerates writers, collects metadata"] --> M["Each writer declares its backup targets<br/>components, as XML"]
    M --> P["Each writer prepares its data<br/>rolling logs, flushing caches, etc.<br/>reaching a recoverable, consistent state"]
    P --> F["Freeze the writers' write I/O<br/>reads still allowed, up to 60 seconds"]
    F --> FS["VSS flushes file system buffers<br/>and freezes the file system"]
    FS --> C["Provider creates the shadow copy<br/>within 10 seconds, write I/O stays frozen"]
    C --> T["File system released, writers thawed<br/>applications resume writing"]
    T --> B["Requester runs the backup from<br/>the shadow copy, taking as long as needed"]

Figure 1: The flow of shadow copy creation. Everything actually stops for only a few seconds to a few tens of seconds; the backup itself runs against the snapshot afterwards

There are three points to note.

1. The application only stops for the instant it takes to create the point of consistency. The freeze is capped at 60 seconds, and creation (the commit) by the provider is capped at 10 seconds; exceed either and creation is aborted and the requester tries again.¹ The backup proper, which can take hours, runs against the finished, read-only shadow copy while the application keeps running.
2. Reads are still possible during the freeze. Only write I/O stops.¹
3. The file system is also frozen. Because VSS flushes the file system buffers before freezing, writes that were sitting in the cache, and the file system’s metadata, are reflected in the snapshot in a consistent order.¹

4.3. Crash Consistency and Application Consistency

This is where an important distinction that determines backup quality comes in.

A shadow copy created without a writer’s cooperation is in what Microsoft’s terminology calls a crash consistent state. The official definition is “a disk state equivalent to the state that would be found after a catastrophic failure that abruptly shuts down the system,” and restoring from it is described as “equivalent to a restart following an abrupt shutdown.”³ As a file system it isn’t corrupted, but from an application’s point of view it’s “the instant the power was pulled while it was writing.” A database with a transaction-log recovery mechanism can often recover from this, but recovery processing has to run first — it’s a precondition, not a bonus.

With a writer’s cooperation, each writer rolls its transaction log and flushes its caches immediately before the point of consistency, bringing the data into a consistent state that the application itself guarantees it can recover correctly from.¹ This is application consistency, and it’s the whole reason the writer mechanism exists. What’s worth noting is that what a writer guarantees is “a consistent, recoverable state as far as the application is concerned” — it does not silently commit and complete in-flight transactions on your behalf. Uncommitted work is rolled back on restore, the same way it would be in ordinary database recovery. A writer delivers this guarantee of quality without stopping the application, using nothing more than a freeze lasting a few tens of seconds.

The reason backup software has settings such as “use VSS” or “guarantee application consistency” is precisely this distinction. For a plain set of files on a file server, crash consistency is rarely a problem; but on a server hosting a database or mail store, whether the corresponding writer is healthy is, in itself, the quality of the backup.

5. Operating VSS Day to Day — vssadmin and “Previous Versions”

The tool IT staff use in practice to check VSS’s state is vssadmin (run it from an elevated Command Prompt). The current command reference lists list shadows / list writers / delete shadows / resize shadowstorage as available on both client and server.⁴ The Windows Server–oriented reference additionally lists create shadow / list shadowstorage / list providers, among others.⁵ Note that vssadmin can only manage shadow copies created by the system provider.¹

If list writers shows a writer in an error state, the thing to suspect is not VSS itself but the application that provides that writer. Check the owning application’s service state and the Application/System event logs (Section 7).

resize shadowstorage’s /maxsize lets you specify the limit with a unit such as KB/MB/GB; leave it unset and there is no limit at all. What’s worth noting is that Microsoft’s documentation explicitly states that changing the storage limit — shrinking it in particular — can itself cause shadow copies to be lost.¹⁰ Don’t casually shrink the limit on a volume where you want to keep multiple generations.

5.1. The Relationship with “Previous Versions”

Enabling Shadow Copies of Shared Folders on a file server periodically retains point-in-time copies of files on the share, letting users restore a file they’ve deleted or overwritten from Previous Versions without needing an administrator’s help.¹ It’s the most familiar application of VSS, and one that reliably cuts help-desk workload.

There is a limit, though. System-provider shadow copies max out at 512 per volume, of which the Shadow Copies of Shared Folders feature keeps up to 64 by default (changeable via the registry value MaxShadowCopies).¹ And as covered from the next section onward, if the diff area runs short, the oldest generations are removed automatically. It’s safest to understand that “how many generations you actually keep” is decided not by the number you configured, but by how much is written and the size of the diff area.

6. A Developer’s Perspective — Does Your Own Application Need VSS?

From here on, this is the developer’s perspective. When you’re asked to “add a backup feature that can copy files even while they’re in use”, how should you approach VSS?

6.1. Writing Your Own Requester Is a Substantial Undertaking

The VSS API, for both requesters and writers, is provided as COM and C++ interfaces (the core of a requester is IVssBackupComponents).⁶ There’s no official .NET wrapper, and you have to correctly implement everything from collecting writer metadata, through managing the snapshot set, to cleaning up after an error — so it isn’t something you can casually bolt on as one feature of a business application. In our own contract-development estimates, “building a VSS requester” is treated as its own separate line item.

There are two realistic answers. First, leave it to an existing VSS-aware backup product. Second, on Windows Server, drive DiskShadow from a script. DiskShadow is the VSS requester that ships with the OS; besides its interactive mode it has a scripting mode (diskshadow /s script.txt), and a single script can cover creating the shadow copy, exposing it as a drive letter (expose), running a batch process that does the copying (exec), and cleaning up afterwards.⁷¹ You can build the flow “create a shadow copy → pull files out of it with your own copy logic → delete it” without writing a single line of COM. However, DiskShadow is Windows Server–only and is not included in client editions of the OS.¹ If client PCs are also in scope for the requirement, that fact alone tips the balance toward adopting an existing backup product.

6.2. Do You Even Need VSS? — A Decision Table

In our experience, the great majority of “copy a file that’s in use” requests can be solved without VSS. Work out exactly what level of requirement you’re dealing with before you pick a tool.

6.3. Should Your Own Application Register a Writer?

It’s worth clarifying the reverse question too: should your own business application provide a VSS writer? If you write one, your application’s data gets backed up with application consistency no matter which backup product your customer uses. There is also a lighter-weight mechanism than a normal writer, the express writer (IVssExpressWriter), but all it does is register metadata declaring which files to include or exclude.⁶ It doesn’t receive freeze/thaw notifications, so it cannot pause your application’s writes to line up with snapshot creation. An express writer is only appropriate when it’s paired with a storage design that isn’t corrupted even if it’s captured mid-write (i.e. crash consistency is enough); if you actually need coordination at the point of consistency, you need a full writer implementation.

That said, the rule of thumb for deciding is simple.

• If your data lives in a database such as SQL Server, you don’t need one. The database’s own writer guarantees consistency.¹
• For simple file-based storage, solve it first through the design of the save routine. If you write out completely to a temporary file and then swap it in with an atomic rename, a crash-consistent snapshot will never leave behind a corrupted saved file.
• Registering a writer is worth considering only for applications that maintain a proprietary data store spanning multiple files and need mutual consistency across them at the point of consistency. It may well be worth first reconsidering whether holding that much data in a home-grown format is the right call at all.

7. Pitfalls — Four Things That Really Bite in Operation

7.1. VSS Is Not Itself a Backup

This is the single most important pitfall. A system-provider shadow copy is a differential sitting on the disk of the very same machine as the original data. If the diff area is lost, there’s nothing left to reconstruct from, so it offers no protection at all against a disk failure, a stolen or lost machine, or the encryption of an entire volume. Microsoft’s own documentation draws a clear line between shadow copies and backups: “the content copied from a shadow copy onto media such as tape is the backup, and the shadow copy itself may be deleted once that copy has been made.”¹ A shadow copy is a point of consistency and a quick way to recover from a mistake — it is not a substitute for a backup kept on separate media at a separate site.

7.2. A Writer Error Is a Problem on the Application Side

When backup software fails with a “VSS error”, start by identifying which writer has failed, using vssadmin list writers. Because a writer is, in substance, a component belonging to the application (or a Windows component)¹, the main battleground for investigating the cause is that application’s service state and its event logs. Getting dragged along by the surface appearance of “an error from the backup software” and continuing to investigate only the backup software leads you the long way round. The general pattern for narrowing this down is the same one covered in “When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running”: narrow the list of suspects from the facts you can actually observe.

7.3. Ransomware Comes for Your Shadow Copies

This is a fact worth knowing purely as a defensive consideration. It’s tempting to hope that if you can roll back with Previous Versions, you could recover even after being hit by ransomware — but it’s widely known that a great deal of ransomware deletes shadow copies before or after encrypting, specifically to shut off this recovery path. Deleting shadow copies can be done with an entirely legitimate command as long as you have administrator rights, so it can’t serve as a last line of defence against an attacker who has already got in. The pillars of a countermeasure, then, are: (1) treat shadow copies as “handy if they’re there” rather than as “part of the recovery plan”; (2) keep a separate, offline backup at a separate site that an attacker cannot reach; and (3) never grant administrator rights to accounts used for day-to-day operations. For defence across the whole PC lifecycle, including backup, encryption, and disposal, see also “The Practical BitLocker Guide — Starting Drive Encryption With Recovery Key Management” and “What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups”.

7.4. When the Diff Area Runs Out, the Oldest Generations Vanish Silently

As covered in Section 4, copy-on-write consumes the diff area only when each block is overwritten for the first time after the snapshot was taken. Overwriting an already-moved block any number of further times doesn’t add to the consumption, so how much is consumed is decided not by “how many writes happened” but by “how wide a range of blocks was overwritten since the retained snapshot was taken.” And once the diff area hits its limit, that volume’s shadow copies are deleted, oldest first.¹ Nothing is notified to the interactive user, so this often only comes to light when “I should be able to roll back to last week’s version” turns out not to be true any more. It isn’t completely silent, though: the System log does record events from the volsnap source (event ID 25 when a copy is deleted because space couldn’t be freed for the diff area, 35/36 when an extension fails or is aborted after hitting the limit, and so on). Beyond periodic checks, including these volsnap events in your monitoring and alerting lets you catch a loss quickly. The reason bulk operations that “sweep across the whole volume” — mass file updates, batch conversions, defragmentation — can devour the diff area in one go comes down to exactly this property: consumption is decided by the range of blocks overwritten. Regularly check whether the number of generations you’re retaining still meets your business requirement (“at most how many days can pass before someone notices an accidental deletion?”) against the usage shown by vssadmin list shadowstorage, and widen the limit if you need to.⁵¹⁰

8. Summary

• The reason a file in use can’t normally be copied is a matter of sharing violations and consistency, and that is the correct mechanism for protecting data. VSS is the OS-level answer to “I want a consistent copy without stopping the application.”
• VSS is a framework in which the VSS service mediates between three roles — requester (asks), writer (guarantees consistency), and provider (creates) — letting backup software and business applications that know nothing about each other cooperate.
• The system provider uses copy-on-write, and a point of consistency is created via “freeze the writers (up to 60 seconds) → create (within 10 seconds) → thaw.” Without a writer’s cooperation you get crash consistency; with it, application consistency.
• Check operational state with vssadmin (list shadows / list writers / list shadowstorage). Suspect the application side for a writer error, and check diff-area usage regularly.
• Developers should first use the decision table to check whether retries, share modes, a stoppage window, or an integration design can solve the problem, and turn to VSS only when it’s genuinely needed. A DiskShadow script (Server only) or an existing product is the realistic answer, ahead of building your own implementation.
• A shadow copy is not a backup. It is nothing more than a differential that depends on the intact blocks of the original volume; it is powerless against the loss of that original volume, as in a disk failure, and it can’t be relied on against ransomware either, given that shadow copies can be deleted or the diff area exhausted. Pair it with an offline backup kept at a separate site.

Related Articles

• Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running
• BitLocker Practical Guide — Drive Encryption Starting With Recovery Key Management
• What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups

Related Consulting Areas

KomuraSoft LLC handles the design and development of business applications with features such as “copy files that are in use” and backup, root-cause investigation of sharing violations around file integration and of backup failures (VSS writer errors), and putting the operational structure of file-server backups and generation management in order. We’re happy to start from the question of whether VSS is even the right requirement in the first place.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

If I have shadow copies, do I still need backups?

No, it doesn't. The shadow copies created by Windows' standard system provider are copy-on-write differentials — they are not a separate, complete copy of the volume at that point in time, but depend on the blocks of the original volume that have not been overwritten. Even if you place the diff area on a separate volume, the fact remains that if the original volume is lost, restoration is impossible, and this offers no protection against events that take out the original volume entirely, such as a disk failure or a stolen or lost PC. The same applies to ransomware: the write operation performed during encryption does move the pre-write blocks into the diff area, but in real attacks the shadow copies themselves are deleted, or the diff area is exhausted by mass rewrites, so you cannot rely on this. Microsoft's own documentation draws a clear line between the two: a backup is the data copied from a shadow copy onto media such as tape, and once that copy has been made the shadow copy itself may be deleted. A shadow copy is a "point-in-time snapshot for taking a backup from" and a "quick way to recover from a minor mistake" — it is not a substitute for a backup kept on separate media at a separate site.

I want my own business application to copy files that are in use — should I use VSS?

The realistic first move is to find a way to avoid needing it. VSS requesters have to be written against a COM-based native API (such as IVssBackupComponents), and there is no official .NET wrapper, so building one into your own application is a substantial undertaking. If the requirement is simply "be able to read a file that another process is writing to, eventually", retries are enough; if "the other application permits read sharing", opening the file with a matching share mode is enough. If the application can be stopped for a short time, copying during a natural break in business is the simplest and most reliable option. VSS only earns its place when the requirement is "replicate an entire set of data from an application that cannot be stopped, in a consistent state" — and even then, look first at an existing VSS-aware backup product or a DiskShadow script before building your own implementation.

vssadmin list writers shows a writer in an error state. What should I do?

The basic approach is to investigate it as a problem on the side of the application that owns that writer. vssadmin list writers displays the registered writers together with their state, so start by identifying which writer has failed. Because writers are provided by applications such as SQL Server or by Windows components (the registry, for example), the cause is almost always found in the service state of the owning application, or in errors recorded in the Application/System event logs, rather than in VSS itself. Restart the relevant service and narrow down the conditions under which it reproduces; if that doesn't resolve it, check the support information for that application. This is also the correct first triage step when backup software fails with a VSS error.

A shadow copy disappeared without my noticing. Why?

The most common cause is the diff area (the shadow copy storage) running out of space. With copy-on-write, the content of each block is moved into the diff area the first time it is overwritten after the snapshot was taken, so the wider the range of blocks that get overwritten, the more of the diff area is consumed. Once the assigned limit is reached, Windows deletes the oldest shadow copies first to free up space. This happens silently, with no notification to the interactive user, so it's typically discovered when someone expects to restore last week's version from Previous Versions and finds it isn't there (the System log does record events such as event ID 25 from the volsnap source, so keeping an eye on that lets you catch it). Check the usage and the limit with vssadmin list shadowstorage, and raise the limit with vssadmin resize shadowstorage if needed. Bear in mind, though, that changing the limit — especially shrinking it — can itself cause shadow copies to be lost.

How does File Explorer's "Previous Versions" relate to VSS?

"Previous Versions" is one of the entry points for retrieving past versions of a file from a shadow copy created by VSS. On a file server, enabling "Shadow Copies of Shared Folders" causes shadow copies to be taken on a schedule, and users can right-click a file on a shared folder and restore it themselves from Previous Versions. The benefit is that users can undo an accidental deletion or overwrite without needing an administrator's help. But because it's built on shadow copies underneath, there's an upper limit on how many generations can be kept, and if the diff area runs short, the oldest generations disappear first. As covered in the body of the article, "we have Previous Versions" does not mean "we don't need backups."

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.