Destroying shadow copies before encrypting is standard ransomware tradecraft — it removes the victim’s cheapest recovery path. MITRE tracks it as T1490, Inhibit System Recovery, and essentially every EDR product treats shadow-copy destruction as a high-confidence indicator. Correctly so.
Backup software also interacts with the Volume Shadow Copy Service constantly, because that is how you read a file that is currently open. This is one of the few places where a legitimate product and an active intrusion genuinely resemble each other at the API level.
What a backup agent legitimately does
A backup agent acts as a VSS requestor. It asks VSS for a point-in-time snapshot, reads from that snapshot rather than the live volume, and releases it when the job finishes. That release is normal and correct: a snapshot held open indefinitely consumes diff-area storage until something has to give.
For Windows System State, the agent also engages specific VSS writers — Registry, COM+ REGDB, Task Scheduler, WMI, VSS Metadata Store, Performance Counters — so the captured state is internally consistent.
So if you watch shadow copies during a backup run you will see one appear and later disappear. That is the agent doing its job, not destroying anything.
The trap: Windows deletes shadow copies by itself
This is the part that causes genuine, avoidable arguments between MSPs and their clients’ security teams, and it is worth knowing before you are in one.
Windows enforces a shadow-storage limit per volume. When a new snapshot is requested and the diff area is already at its maximum, **VSS itself evicts the oldest shadow copies to make room** — regardless of which requestor asked for the new one. System Restore points are shadow copies, so they go the same way.
The observable result is that a client checks shadow copies, runs a backup, checks again, and finds restore points that used to be there are gone. The backup agent did not delete them. Windows did, because the volume was already at its configured shadow-storage limit and something asked for a new snapshot.
Before attributing a missing restore point to any backup product, check the shadow-storage configuration for that volume with vssadmin list shadowstorage. If used space is at the maximum, you have your explanation, and the fix is to raise the limit rather than to blame the agent.
The distinction that actually matters
For triage, the useful question is not whether shadow copies changed. It is whether something explicitly destroyed pre-existing ones.
A backup agent releasing the snapshot it created is routine. VSS evicting old snapshots under storage pressure is routine. Neither is T1490.
An explicit vssadmin delete shadows, a wbadmin delete catalog, or a WMI call deleting Win32_ShadowCopy objects is not routine, and no backup product needs to do any of them. If you see one of those, treat it as an incident — and if a backup vendor tells you their agent does it, ask why.
Write that distinction into your triage runbook before deployment. It converts a two-in-the-morning escalation into a lookup.
Practical steps
Ask your backup vendor, in writing, whether any component ever deletes shadow copies it did not create, and whether anything in the product invokes vssadmin delete shadows. The answer should be a flat no, and it should be checkable.
Baseline shadow-storage configuration across the estate before deploying an agent, so you can tell storage-pressure eviction from anything else afterwards.
Give your SOC the expected pattern in advance: a snapshot appears at the start of a backup window and is gone at the end. Told beforehand, that is a tuning note. Discovered during an incident, it looks like evidence.