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 was told the process cannot access the file.” “We were asked to back up the data folder without stopping the core system.” “Why can backup software copy a database file that is in use without any trouble?” — Whether you develop business applications or operate file servers, these are questions you run into sooner or later.

At the centre of the answer is the Volume Shadow Copy Service (VSS). Built into Windows for more than twenty years, it is the foundation that Windows Server Backup, System Restore, and very nearly every commercial backup product sit on.¹

This article treats “the mechanism that lets a file be copied while it is in use” and “how much that copy actually protects you” as two separate questions. It is aimed at business-application developers who are asked for a “copy files that are in use” feature, and at IT staff who operate backups for file servers and business PCs.

It starts with the bottom line and a reading guide by goal, then covers VSS’s cast of characters, how the data is stored, what to check in day-to-day operations, the decisions a developer faces, and the pitfalls, in that order. The technical explanations are based on primary sources as of August 2026.

The “Depths of Windows I/O” series looked inside the Cache Manager and NTFS. This article is its sequel, covering the “snapshot” layer that hooks in just above the volume.

1. The Bottom Line First

VSS is the mechanism that briefly quiesces an application’s writes in cooperation with its writer, so that a backup can be taken from the copy made at that instant. Creating a shadow copy does not make a backup onto separate media unnecessary.

What the Mechanism Does

VSS is a set of COM interfaces and a coordinating service that make it possible to back up a volume while applications keep writing to it. It has been built in since Windows XP.²

There are three roles plus a coordinator. The VSS service mediates between the requester that asks for a shadow copy (the backup software), the writer that guarantees data consistency on the application side (SQL Server, for example), and the provider that actually creates the snapshot.¹

The point of consistency is created by “freeze the writers (up to 60 seconds) → create the snapshot (within 10 seconds) → thaw.” If a time limit is exceeded, creation is aborted and the requester tries again.¹

Separate How It Is Stored From What Consistency Is Guaranteed

The standard Windows system provider uses copy-on-write. Rather than duplicating the whole 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.¹

Whether a writer cooperates changes the quality of the copy. A snapshot taken without cooperation is equivalent to “the disk at the instant the power was cut” (crash consistent); one taken with cooperation has had logs rolled and caches flushed first, leaving a consistent state that the application itself guarantees it can recover from (application consistent).³¹

Operations and Development Check Different Things

For operations, the tool is vssadmin. 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 is exhausted, the oldest shadow copies are deleted silently.⁴⁵¹

Building a VSS requester into your own application is a substantial piece of work. It is 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 required, scripting DiskShadow is the practical answer (Windows Server only).⁶⁷

A shadow copy is not itself a backup. Because a copy-on-write differential depends on the intact blocks of the original volume, it is powerless against a failure that takes the original volume with it, such as a disk failure or theft. It cannot be relied on against ransomware either, because of shadow copy deletion (Section 7.3) and diff area exhaustion through mass rewrites (Section 7.4). It becomes meaningful only in combination with a backup on separate media.¹

Reading by Goal or Symptom

If you want to understand the mechanism, read from Section 2 onward; if you run operations, read Sections 5 and 7; if you are a developer, start from the decision table in Section 6.2.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (26 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Framing the Problem — Why a File That Is in Use Cannot Simply Be Copied

Start With Why It Cannot Even Be Opened

The starting point is the Windows file share mode. When Windows opens a file (CreateFile), it declares what other processes are allowed to do while this handle is open as the share mode (dwShareMode). While a process holds the file open in a way that does not permit read sharing, any later process that tries to open it for reading fails with a sharing violation (ERROR_SHARING_VIOLATION, error 32).⁸ In .NET this shows up as 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: it is the correct mechanism for protecting data. If a file that is being written could be read midway through, the reader would end up holding a half-written, incoherent state. As covered in detail in “The Fundamentals of Locking for File-Based Integration”, the design of exclusive access is the foundation of integration between applications.

This correct mechanism, however, is fundamentally at odds with backup. There are three separate walls here.

Wall 1: A Sharing Violation Stops You Opening the Source

Files that a database or a business application keeps open may be impossible to open as a copy source in the first place.

Wall 2: Even If You Can Open It, the Copy Is Not Consistent

Even if you can open it, because read sharing is permitted, copying takes time. The application keeps writing while the copy runs, so the first half and the second half of the file can come from different points in time, or several files (the data file and its log, for example) can end up inconsistent with each other.

On top of that, as the “Cache Manager” instalment showed, writes land in the in-memory cache first, so looking only at the file on disk does not guarantee you are seeing the latest content. “Being able to read it” and “being able to copy it in a consistent state” are different problems.

Wall 3: You Cannot Stop the Application Long Enough to Copy

“Then stop the application and copy it” is a fair point, but it is unacceptable for a business system or a file server that runs around the clock.

The requirement, in other words, is “a copy of one consistent instant, without stopping the application.” That is too much for individual applications to solve on their own, and VSS is the OS-level mechanism provided for it. VSS is supplied as a framework of COM interfaces that makes it possible to back up a volume even while applications keep writing to it.²

3. The VSS Cast of Characters — Requester, Writer, and Provider

VSS is structured as three roles plus the service that mediates between them.¹

Backup Software and Applications Split the Work

The elegance of this split is that products that know nothing about each other can still cooperate. Backup software (the requester) knows nothing about SQL Server’s internal structure. It can still take a consistent backup through the following division of labour.¹⁹

1. The SQL Server writer declares, as metadata, the set of files (the components) that must be backed up.
2. The writer puts its own data in order before and after the point of consistency is created.
3. The requester takes the backup according to that declaration and that cooperation.

Nearly every third-party backup product that runs on Windows is a VSS requester.¹

When Something Fails, the Three Roles Tell You Where to Look

The place where the three roles matter most in day-to-day IT work is troubleshooting. Whether a backup failure is a problem with the requester (the software), with a specific writer (the application), or with the provider and the diff area (the infrastructure) completely changes where you look (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

Only the Pre-Write Blocks Are Set Aside

The word “snapshot” suggests a copy of the whole volume, but what the standard Windows system provider uses is copy-on-write. At the moment the snapshot is created, almost nothing is copied.

After that, when a block on the original volume is about to be overwritten, the pre-write 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 is needed only on the first overwrite of each block; overwriting a block that has already been set aside does not grow the diff area.

Reads Combine the Original Volume and the Diff Area

To read “the volume as it was at that instant”, the unchanged blocks are read from the original volume and the changed ones from the diff area, and the two are combined. Because only what changed is ever copied, creation is instantaneous and the space consumed is only the difference.

The flip side is that the more a volume is written to, the faster the diff area is consumed. What determines the consumption is covered in detail in Section 7.4. The diff area is placed on an NTFS volume on the same machine as the original data.¹

What makes all this work are swprv.dll, the system provider’s component file, and volsnap.sys, the driver that hooks into volume I/O.¹ If the way things hook into the I/O stack interests you, see “Filter Drivers and Minifilters” as well.

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 is best on the storage device.¹

4.2. How the Point of Consistency Is Made — 60 Seconds to Freeze, 10 Seconds to Create

If copy-on-write is “how the data is stored”, then VSS’s real contribution is “which moment gets stored”, that is, how the point of consistency is made. Shadow copy creation proceeds as follows.¹

flowchart TB
    R["Requester asks for creation<br/>enumerates writers and collects metadata"] --> M["Each writer declares its backup targets<br/>(components) in XML"]
    M --> P["Each writer prepares its data<br/>rolling logs, flushing caches and so on<br/>into a recoverable consistent state"]
    P --> F["Writer write I/O is frozen<br/>(reads remain possible, up to 60 seconds)"]
    F --> FS["VSS flushes the file system buffers<br/>and freezes the file system"]
    FS --> C["Provider creates the shadow copy<br/>(within 10 seconds, write I/O frozen throughout)"]
    C --> T["File system released → writers thawed<br/>applications resume writing"]
    T --> B["Requester takes the backup from the<br/>shadow copy, at whatever pace it needs"]

Figure 1: The shadow copy creation flow. Only a few seconds to a few tens of seconds are stopped, and the backup itself runs against the snapshot

The Time Things Stop and the Time the Backup Takes Are Different

There are three points to take away.

1. The application stops only for the instant the point of consistency is made. The freeze is capped at 60 seconds and the provider’s creation (commit) at 10 seconds; if either is exceeded, creation is aborted and the requester tries again.¹ The backup itself, which may 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 frozen too. VSS flushes the file system buffers before freezing, so writes that were sitting in the cache and file system metadata are reflected in the snapshot in a consistent order.¹

4.3. Crash Consistent Versus Application Consistent

Here comes the distinction that separates good backups from poor ones.

Without a Writer: The Same State as Recovering From an Abrupt Stop

A shadow copy made without a writer’s cooperation is, in Microsoft’s terminology, 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”.³ The file system is not broken, but from the application’s point of view it is “the instant the power cable was pulled mid-write”. A database with a transaction log recovery mechanism can usually recover, but recovery processing is a precondition.

With a Writer: The Application Prepares a Recoverable Consistent State

With a writer’s cooperation, each writer rolls its transaction logs and flushes its caches just before the point of consistency, putting the data into a consistent state that the application itself guarantees it can recover correctly from.¹ That is application consistency, and it is the reason the writer mechanism exists.

Note that what a writer guarantees is “a consistent, recoverable state as far as the application is concerned”; it does not commit in-flight transactions on your behalf and drive them to completion. Uncommitted work is rolled back on restore (the same behaviour as ordinary database recovery). The writer delivers this quality guarantee without stopping the application, using only a freeze of a few tens of seconds.

Backup products carry settings such as “use VSS” or “guarantee application consistency” precisely because of this distinction. For plain files on a file server, crash consistency is rarely a problem, but on a server that hosts a database or a mail store, the health of the corresponding writer is the quality of the backup.

5. Operational Commands in Practice — vssadmin and Previous Versions

The tool for checking VSS state in day-to-day IT work is vssadmin. Run it from an elevated command prompt. List the current state first, and change the diff area’s limit only after confirming both the need and the risk of losing copies.

What Can Be Checked, and Which Commands Are Available

The current command reference presents list shadows / list writers / delete shadows / resize shadowstorage as available on both client and server.⁴ The Windows Server reference additionally documents create shadow / list shadowstorage / list providers and others.⁵ Note that vssadmin can manage only the shadow copies created by the system provider.¹

Tell the State-Checking Commands Apart From the Limit-Changing One

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

Treat the Limit Change Separately From the Checks

The /maxsize of resize shadowstorage takes a limit with a unit such as KB, MB or GB; if it is not specified, there is no limit. What matters is the documented warning that changing the storage limit, and shrinking it in particular, can itself cause shadow copies to be lost.¹⁰ Do not casually shrink the limit on a volume whose generations you want to keep.

5.1. The Relationship With Previous Versions

Enabling Shadow Copies of Shared Folders on a file server keeps point-in-time copies of the files on the share on a schedule, and users can restore a file they deleted or overwrote from Previous Versions without an administrator’s help.¹ It is the most accessible application of VSS and a reliable way to cut help desk workload.

There are limits, though. A system provider shadow copy is capped at 512 per volume, and of those, Shadow Copies of Shared Folders keeps 64 by default (changeable through the MaxShadowCopies registry value).¹

And, as the following sections explain, the oldest generations are deleted automatically if the diff area runs short. It is safer to understand that “how many generations survive” is determined not by the number you configured but by the write volume and the size of the diff area.

6. How Developers Should Engage — Does Your Application Need VSS?

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

Use the decision table in Section 6.2 first to work out whether VSS is needed at all, and only then choose an implementation. Section 6.1 is about the “requester”, the side that asks for a copy; Section 6.3 is about the “writer”, the side that lets someone else back up your own application’s data.

6.1. Writing Your Own Requester Is a Big Job

The VSS API is provided as COM and C++ interfaces for both requesters and writers (IVssBackupComponents is the centre of the requester side).⁶ No official .NET wrapper is provided, and you have to implement writer metadata collection, snapshot set management and cleanup after errors correctly, so this is not something you casually add as one feature of a business application. In our own Custom Software Development estimates, “writing a VSS requester” is treated as a separate development item.

Look at Existing Software First, or DiskShadow on Windows Server

There are two practical answers. First, leave it to existing VSS-aware backup software. Second, on Windows Server, drive DiskShadow from a script.

DiskShadow is a VSS requester that ships with the OS. Besides an interactive mode it has a script mode (diskshadow /s script.txt), so shadow copy creation, exposure as a drive letter (expose), running a batch that performs the copy (exec), and cleanup can all be written in a single script.⁷¹ You can assemble the flow of “create a shadow copy → pull the files out of it with your own copy routine → 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, that alone tips the decision toward an existing backup product.

6.2. Is VSS Even Needed? — A Decision Table

In our experience, most enquiries about “copying files that are in use” can be solved without VSS. Work out the level of the requirement before choosing a tool.

6.3. Should Your Application Register a Writer?

It is worth addressing the question in the other direction too: should a business application you wrote provide a VSS writer? If you write one, your application’s data can be backed up application-consistently no matter which backup product the customer uses.

An Express Writer Does Not Quiesce Writes

There is also a lighter-weight mechanism than a full writer, the express writer (IVssExpressWriter), but all it does is register a declaration of metadata about which files to include and which to exclude.⁶

Because it does not receive notifications such as freeze and thaw, it cannot quiesce the application’s writes in step with snapshot creation. An express writer is appropriate only alongside a save design that does not break when it is captured mid-write, that is, one for which crash consistency is enough. If cooperation at the point of consistency is required, a full writer implementation is needed.

Decide Whether You Need Your Own Writer From How You Store Data

The rule of thumb is simple.

• You do not need one if your data lives in a database such as SQL Server. The database’s own writer guarantees consistency.¹
• For plain file storage, solve it in the design of the save routine first. If you write to a temporary file and swap it in by renaming, so that the save is atomic, even a crash-consistent snapshot will never leave a broken save file behind.
• Registering a writer is worth considering only for applications that hold a custom data store spread across several files and need those files to be consistent with each other at the point of consistency. Before that, it may be worth reconsidering whether you should be holding that much data in your own format at all.

7. Pitfalls — Four That Really Matter in Operations

Check not only “did we make a point of consistency” but also “will it survive” and “is it of a quality you can restore from”. The following four points need to be considered separately in operations.

7.1. VSS Is Not a Backup in Itself

This is the most important pitfall. A system provider shadow copy is a differential on the disk of the same machine as the original data. It is not a separate complete replica: reads combine the not-yet-overwritten blocks of the original volume with the diff area.

For that reason it cannot cover events that take the original volume with them, such as a disk failure or a stolen or lost machine. Placing only the diff area on a separate volume does not change that dependency. And if the diff area itself is lost, the combination can no longer be made either.

Nor can shadow copies be relied on against ransomware that encrypts the whole volume. The writes performed during encryption do set aside the pre-write content, but in a real attack they are lost to shadow copy deletion or to diff area exhaustion from mass rewrites. Sections 7.3 and 7.4 cover this.

Microsoft’s documentation also draws a clear line between a shadow copy and a backup: “the backup is what was copied from the shadow copy onto media such as tape, and the shadow copy may be deleted once the 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 on separate media at a separate site.

7.2. Writer Errors Are Problems on the Application Side

When backup software fails with a “VSS error”, check the following in order.

1. Identify which writer is failing with vssadmin list writers.
2. Check the service state of the application or Windows component that provides that writer.
3. Check the Application and System event logs and investigate the cause on the owning application’s side.

A writer is, in substance, a component on the application (or Windows component) side.¹ Being led by the appearance of “an error in the backup software” and continuing to investigate only the backup product is the long way round. The general approach to isolating a fault follows the “narrow down the suspects from observable facts” pattern covered in “Maintaining a System With No Source and No Documentation”.

7.3. Ransomware Comes Specifically to Delete Shadow Copies

This is something defenders need to know. If Previous Versions can roll a file back, surely files encrypted by ransomware can be rolled back as well — that is the natural hope, but it is widely known that much ransomware deletes shadow copies before or after encrypting, specifically to close off this recovery path. Shadow copy deletion can be performed with legitimate commands as long as the caller has administrator rights, so it is not a last line of defence against an attacker who is already inside. The response therefore rests on three things.

• Treat shadow copies not as “part of the recovery plan” but as “nice to have if they survive”.
• Keep a separate offline, off-site backup that an attacker cannot reach.
• Do not give administrator rights to the accounts used for day-to-day work.

For defending the whole PC lifecycle, including backups, encryption and disposal, see also “BitLocker Practical Guide” and “PC Disposal Checklist”.

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

Consumption Is Decided by Range, Not by the Number of Writes

As Section 4 showed, copy-on-write consumes the diff area when each block is overwritten for the first time after the snapshot was taken. Overwriting a block that has already been set aside, however many times, adds nothing, so consumption is determined not by “the number of writes” but by “how wide a range of blocks has been overwritten since the snapshots you are keeping”.

Confirm Lost Generations in the System Log Too

When the diff area reaches its limit, that volume’s shadow copies are deleted oldest first.¹ Nothing is reported to interactive users, so it tends to come to light only when “we should be able to roll back to last week’s version” turns out to be false. It is not completely silent, though: events from the volsnap source are recorded in the System log (event 25 when a copy was deleted because the diff area could not be secured, and events 35 and 36 when growth failed or the operation was aborted on reaching the limit, among others). Alongside periodic checks, including these volsnap events in your monitoring and alerting lets you notice a loss immediately.

Compare the Retention You Need Against Diff Area Usage

Operations that “sweep across a wide part of the volume”, such as bulk file updates, batch conversions or defragmentation, eat through the diff area all at once precisely because of this “decided by the range overwritten” behaviour.

Check periodically, with vssadmin list shadowstorage, whether the generations retained satisfy the business requirement (“at most how many days later do we notice an accidental deletion?”), and raise the limit if necessary.⁵¹⁰

8. Summary

VSS is easiest to hold in your head if you split it into three questions: “what gets put in order”, “how it is stored”, and “how it is operated”.

What Gets Put in Order: A Consistent Point of Consistency, Even While in Use

A file that is in use cannot simply be copied because of sharing violations and consistency, and that is the correct mechanism for protecting data. VSS is the OS-level answer to “we want a consistent copy without stopping”.

VSS is a framework in which the VSS service mediates between three roles — requester (asking), writer (guaranteeing consistency) and provider (creating) — so that backup software and business applications that know nothing about each other can cooperate.

How It Is Stored: Make a Point of Consistency Quickly, Then Back It Up Separately

The system provider uses copy-on-write, and the point of consistency is made by “freeze the writers (up to 60 seconds) → create (within 10 seconds) → thaw”. Without writer cooperation you get crash consistency; with it, application consistency.

A shadow copy is not a backup. It is no more than a differential that depends on the intact blocks of the original volume, it is powerless against the loss of the original volume in a disk failure, and it cannot be relied on against ransomware because of shadow copy deletion and diff area exhaustion. Combine it with an offline, off-site backup.

How It Is Operated: Check the State, and Engage Only as Far as You Need To

For operations, check with vssadmin (list shadows / list writers / list shadowstorage). Suspect the application side for writer errors, and look at diff area usage regularly.

Developers should first use the decision table to confirm whether retries, share modes, a stoppage window or an integration design solve the problem, and turn to VSS only when it really is necessary. A DiskShadow script (Server only) or existing software is a more practical answer than your own implementation.

Related Articles

• The Fundamentals of Locking for File-Based Integration — Best Practices for File Locks and Atomic Claims
• Depths of Windows I/O (Part 4) — The Cache Manager: When Does Your WriteFile Reach the Disk?
• Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System From the MFT
• When You Inherit a System With No Source Code and No Specifications — A Practical Playbook for Operating and Maintaining It Without Stopping It
• BitLocker Practical Guide — Drive Encryption Starting From 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 that include “copying and backing up files that are in use”, root-cause investigation of sharing violations around file integration and of backup failures (VSS writer errors), and putting the operation of file server backups and generation management in order. Starting from the question of whether VSS is even the right fit for the requirement is perfectly fine.

• Windows Application Development
• Bug Investigation and Root-Cause Analysis
• Technical Consulting and 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 we have shadow copies, do we still need backups?

You still need them. The shadow copies created by the standard Windows system provider are copy-on-write differentials: they are not a separate, complete replica of that point in time, and they depend on the blocks of the original volume that have not been overwritten. Even if you configure the diff area on a separate volume, it remains true that nothing can be restored once the original volume is gone, so shadow copies are powerless against events that take the original volume with them, such as a disk failure or a stolen or lost PC. Ransomware is no different: the writes performed during encryption do move the pre-write blocks into the diff area, but in real attacks the shadow copies are deleted or the diff area is exhausted by mass rewrites, so they cannot be relied on. Microsoft's documentation also draws the distinction, stating that the backup is the data copied from the shadow copy onto media such as tape, and that the shadow copy itself may be deleted once the copy has been made. A shadow copy is a point of consistency to take a backup from, and a quick way to recover from a minor mistake. It is not a substitute for a backup 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 look for a way to avoid it. A VSS requester has to be written against a COM-based native API (IVssBackupComponents and friends), and no official .NET wrapper is provided, so building one into your own application is a substantial piece of work. If the requirement is only that you eventually be able to read a file another process is writing to, retries are enough; if read sharing is permitted, opening the file with a matching share mode is enough. If the application can be stopped briefly, copying during a natural break in the working day is the most reliable option of all. VSS earns its place only for the requirement to replicate an entire set of data, in a consistent state, from an application that cannot be stopped, and even then look first at VSS-aware backup software or a scripted DiskShadow rather than your own implementation.

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

Investigate it as a problem on the side of the application that owns that writer. vssadmin list writers lists the registered writers together with their state, so start by identifying which writer is failing. Because writers are provided by applications such as SQL Server or by Windows components such as the registry, the cause almost always lies in the service state of the owning application, or in errors recorded in the Application and System event logs, rather than in VSS itself. Restart the service in question, isolate the conditions that reproduce the problem, and if that does not resolve it, check the support information for that application. The same procedure is the correct first triage step when backup software fails with a VSS error.

A shadow copy disappeared without anyone noticing. Why?

The classic cause is the diff area (the shadow copy storage) running short of space. With copy-on-write, the pre-write content of each block is moved into the diff area the first time that block is overwritten after the snapshot was taken, so the wider the range that gets overwritten, the more of the diff area is consumed. Once the assigned limit is reached, Windows deletes the oldest shadow copies first to reclaim space. Nothing is reported to interactive users and the copies vanish silently, so this tends to surface as someone expecting to roll back to last week's version through Previous Versions and finding it is not there (the System log does record events such as event ID 25 from the volsnap source, so making them a monitoring target lets you notice). Check usage and the limit with vssadmin list shadowstorage and, if necessary, raise the limit with vssadmin resize shadowstorage. Be aware, though, that changing the limit, and shrinking it in particular, 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 an earlier version of a file from inside a shadow copy that VSS created. On a file server, enabling Shadow Copies of Shared Folders creates shadow copies on a schedule, and users can right-click a file on the shared folder and restore an earlier version themselves. The benefit is that a deletion or an overwrite can be fixed without an administrator's help. Because what lies underneath is still a shadow copy, however, there is an upper limit on how many generations can be kept, and the oldest ones disappear if the diff area runs short. As the body of the article explains, the presence of Previous Versions does not make backups unnecessary.

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.