About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Many Windows file servers have a feature that quietly saves a great deal of help-desk time. A user overwrites a spreadsheet, right-clicks the folder, opens the Previous Versions tab, and brings back this morning's copy. No ticket, no waiting.
That convenience makes it tempting to treat shadow copies as the backup. This article explains, from Microsoft's documentation, what shadow copies actually are, what they do well, and why, in our view, they belong alongside a backup rather than in place of one.
What a shadow copy is
Microsoft's article on the Volume Shadow Copy Service (VSS) describes the service as the coordinator between backup applications, the applications being backed up, and the storage. It names three roles:
- Requesters, typically backup applications, which ask for shadow copies to be created.
- Writers, which Microsoft describes as The component that guarantees you have a consistent data set to back up. Applications such as SQL Server and Exchange Server provide their own.
- Providers, which create and maintain the shadow copies, in software or in storage hardware.
The provider built into Windows uses a method Microsoft calls copy-on-write. Rather than copying the whole volume, it makes a differential copy by copying all changes (completed write I/O requests) that are made to the volume after a given point in time. When a block on the volume is about to change, the original block is first saved to a shadow copy storage area, also called the diff area.
The key detail is in Microsoft's description of how the old view is rebuilt: The copied blocks in the diff area can be combined with the changed data on the original volume to restore the volume to its state before any of the changes were made.
In our reading, this means a software shadow copy is not a separate copy of the data. It is a record of what changed, which only makes sense together with the original volume. Lose the volume, and the shadow copy has nothing to be combined with.
What Previous Versions is for
The VSS article describes Shadow Copies of Shared Folders, the feature behind the Previous Versions tab on file shares: With Shadow Copies of Shared Folders, users can quickly recover deleted or changed files that are stored on the network. Because users can do this themselves, Microsoft notes, it can increase productivity and reduce administrative costs.
In our view, this is exactly the right job for it: fast, self-service recovery of recent mistakes. A file overwritten an hour ago, a folder deleted yesterday, a document saved with the wrong changes. These are useful cases for shadow copies, because they are on the server already and need no restore job.
Microsoft's own answer: when is a shadow copy a backup?
The VSS article's frequently asked questions include this one directly: what is the difference between a shadow copy and a backup? Microsoft's answer has two parts. First, A shadow copy serves as the backup when performing a hard disk drive backup. Second: When data is copied from the shadow copy to tape or other removable media, the content that's stored on the media constitutes the backup. It adds that the shadow copy itself can then be deleted.
In our reading, Microsoft treats a shadow copy as a consistent point-in-time source that a backup is made from. For the local shared-folder scenario discussed here, an independent retained copy is still needed; Microsoft also documents other VSS backup arrangements. That is how backup tools use VSS: they ask for a shadow copy so that they can read a stable, consistent view of files while the server keeps working, then copy that view to separate storage.
Where shadow copies stop
They live on the same server
The VSS article notes that The shadow copy storage area can be on the same volume or a different volume. Either way, in our reading, for the built-in provider it is storage attached to the same server. A failed disk array, a lost virtual machine, a fire or a theft takes the shadow copies with the data.
They are deleted to make room
Shadow copies use space, and Windows manages that space automatically. The article's answer to what happens when that space runs out is short: Shadow copies for the volume are deleted, beginning with the oldest shadow copy.
In our reading, that makes the history unpredictable. A busy period with many file changes, such as a large data import or a reorganisation, can push older copies out sooner than expected. The age of the oldest available version depends on how much has changed, not on any retention promise.
There is a limit on how many
The article also states the maximum: The maximum number of software shadow copies for each volume is 512. For the Shadow Copies of Shared Folders feature, it says that by default only 64 are maintained. In our view, at a schedule of a few copies each working day, that default reaches back weeks rather than months.
Anyone with enough rights can delete them
Microsoft's vssadmin reference lists a command that deletes volume shadow copies, among its standard functions. That is a legitimate administrative tool. In our reading, it also means shadow copies offer no protection against anyone, or anything, running with administrative rights on the server.
What about storage-array snapshots?
Many organisations also have snapshots taken by their storage system rather than by Windows. The VSS article covers these as hardware providers, and describes uses such as restoring a whole storage volume quickly by resynchronising it from a shadow copy. It notes that Most arrays allow production I/O operations to resume shortly after the resync operation begins.
In our view, array snapshots are a powerful recovery tool, often faster than any restore from backup for a large volume. They raise the same question as Windows shadow copies, though: where do they live? A snapshot kept on the same array protects against mistakes and corruption on the volume, but not against losing the array, and not against someone who has gained administrative access to it. Whether a particular array's snapshots can be protected from deletion is a question for that vendor's documentation, and the answer belongs in the recovery plan.
Where the diff area goes by default
One more detail is worth knowing when reviewing a server. The VSS article explains that The diff area can be located on any local volume. However, it must be located on an NTFS volume that has enough space to store it. Microsoft lists the selection order: reuse an existing shadow copy’s location first, then use a preconfigured manual association, and only if neither supplies a location choose according to available free space.
In our reading, this means the storage area may end up on a different local volume from the one being protected, which can look like separation. It is still local storage on the same server, with the same exposure to a server-level loss.
Administrative deletion is a shared risk
Microsoft’s vssadmin reference documents deletion as a normal administrative capability. This establishes the recovery-planning limit without relying on a particular malware description: local shadow copies are not an independently protected copy against an actor who can administer that server.
Keep separate retained backups whose deletion controls do not depend solely on the file server’s own privileged accounts. Evaluate the actual backup platform’s retention and access controls rather than assuming that a different drive letter or network share provides that separation. After a suspected compromise, the incident-response owner must choose a trusted recovery point and a clean target before restored data is returned to use. This article does not validate any specific ransomware remediation procedure.
Don't switch the service off either
Some administrators, faced with space use or errors, consider disabling the service. The VSS article advises against it: It's possible to disable VSS by using the Microsoft Management Console. However, you shouldn't do this. It explains that disabling it affects software that depends on it, such as System Restore and Windows Server Backup.
In our reading, that dependency is the other half of the story. VSS is not only the Previous Versions feature; it is how backup tools get a consistent view of open files. Turning it off to save space can quietly break the backups that are meant to stand behind it.
On Windows desktops: File History
For individual Windows PCs, Microsoft's support article Backup and restore with File History describes a feature that saves copies of personal files, making regular backups to an external drive or network location. In our reading, the difference from shadow copies is the destination: File History copies to separate storage, which is what makes it a backup in Microsoft's own terms above. Whether that separate storage is itself protected, for example from ransomware that can reach a mapped network location, is a separate question worth asking.
How shadow copies fit into a recovery plan
In our view, shadow copies are best treated as the first, fastest layer of a recovery plan, with clear expectations:
| Situation | Shadow copies | Separate backup |
|---|---|---|
| File overwritten this morning | Ideal: user can restore it | Works, slower |
| Folder deleted last week | Depends on retained copies | Depends on retained, usable backups |
| File needed from three months ago | Usually gone | Works, if retained |
| Disk, server or virtual machine lost | Local copies may be lost or unusable | Requires an independently recoverable copy |
| Actor with server administrative rights | Deletion is possible | Requires protected retention and a trusted restore point |
What we recommend
- Keep shadow copies on file servers for fast, self-service recovery of recent changes.
- Never count them as the backup. Back up to separate storage that the file server's administrators and processes cannot simply delete.
- Tell users what Previous Versions covers, and roughly how far back it usually reaches, so they ask for help early.
- Size the storage area for the change rate, and check periodically how old the oldest copy actually is.
- Leave the service running, since backups depend on it.
- Watch for unexpected shadow copy deletion as a possible sign of an attack.
- Test restoring from the separate backup, not just from Previous Versions.
Confirm what a Previous Versions entry represents
The interface is a way to reach retained versions, not a guarantee about how they were created or where all necessary data resides. Record the server, volume, provider and schedule behind the shared-folder feature. Check the oldest usable copy after busy periods, because churn can shorten the practical history even when the configured schedule has not changed.
A recovery rehearsal should open a retained copy, recover a file to a separate location and compare its content and intended access. Avoid replacing a whole live folder merely to demonstrate that the menu works. The independent-backup rehearsal should then assume that the original volume and its local shadow storage are unavailable. That second test answers a different question: whether the organisation can recover after losing the storage on which Previous Versions depends. Neither result should be inferred from the presence of dated entries alone.
Check retention after the workload changes
A shadow-copy schedule describes when copies are attempted, not how long each copy will remain usable. A bulk rewrite, migration or application change can increase the amount of old block data that must be retained. Review the practical recovery window after those events and distinguish a copy that was never created from one removed under storage pressure.
If users expect several weeks of self-service recovery, document that expectation and compare it with observed retained copies over representative busy periods. Keep the independent backup policy separate: local shadow-copy retention should not determine how long the organisation retains its disaster-recovery copy. This makes a loss of local history a visible service limitation rather than an unexpected discovery during an urgent file request.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026.
- Descriptions of what shadow copies cover in each situation are our reading, labelled as such.
- Hardware shadow copy providers on storage arrays behave differently from the built-in provider and are not covered here.
- No shadow copies were created, deleted or restored for this article, and no commands or attack techniques are given.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Volume Shadow Copy Service (VSS)
- Microsoft Learn: vssadmin
- Microsoft Support: Backup and restore with File History
This article was originally published on .