Move Shadow Storage from One Volume to Another

I have Shadow Copies turned off on a Hyper-V server but VSS is still used for backups and by SentinelOne. On one server, somehow the shadow storage for C: wound up on D:

Might be okay but I was getting VSS errors, so I wanted to move it back to the default C:.

First I tried adding shadow storage for C: on C:, and got

Maximum number of shadow copy storage associations already reached.

Then I tried resizing it to C:, hoping that would move it. “The specified volume shadow copy storage association was not found.”

Okay so I have to first delete the existing shadow storage on D:, then re-add it on C:.

The quickest way to delete all shadow copies is to resize the storage to the minimum 320MB. Which failed with “The shadow copy provider had an error. Please see the system and application event logs for more information.”

From past experience, I suspected that SentinelOne was blocking the deletion. As blogged here, I ran unprotect/unload on SentinelOne, and was then able to resize the shadow copes. I then confirmed that size was down to 0 bytes:

Once it was down to 0 bytes on D:, the add command worked to move it to C:

So in summary, the commands to move from D: to C: were:

cd /d C:\Program Files\SentinelOne\Sentinel Agent <your version>
sentinelctl.exe unprotect -k “passphrase”
sentinelctl.exe unload -slam -k “passphrase”
vssadmin resize ShadowStorage /for=C: /on=D: /maxsize=320MB [320MB is the minimum]
vssadmin add ShadowStorage /for=C: /on=C: /maxsize=10% [desired max size]
sentinelctl load -slam
sentinelctl.exe protect

vssadmin list shadowstorage

Update March 14, 2025

It turns out that the same machine put shadow storage for the EFI system partition on an external USB drive. This is causing VSS 12289 errors during backups, with messages like

Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\Volume{efbd74c0-2e19-726e-b913-e2e696390a52} – 000000000000037C,0x0053c008,000001F25972F340,0,000001F25972D140,4096,[0]).  hr = 0x80820001, The bootfile is too small to support persistent snapshots.

I don’t have this issue on machines where the EFI shadow storage is on the EFI partition, small as it is (100MB by default). So I want to move the EFI partition’s shadow storage to the EFI partition.

The current Used Shadow Copy Storage space is only 144KB, so resizing to 320MB won’t delete that. Server 2022 supports a vssadmin Delete ShadowStorage command, but that would not delete the association when the shadow storage was in use.  So I tried to use vssadmin delete shadows to delete the storage that was in use, and got this:

Error: Snapshots were found, but they were outside of your allowed context.  Try removing them with the
backup application which created them.

Disabling SentinelOne as described above didn’t help. When I use vssadmin list shadows for the EFI partition, I can see that they were created at 7pm, the time that Synology Active Backup for Business runs. Some web searches suggested that uninstalling the Active Backup agent should remove the shadows. It did not, and I still got the message about the snapshots being out of my context.

After much more trial and error, I thought about just ejecting the external drive G: where the EFI shadows are stored. That didn’t work because it was “in use.” A chkdsk G: /f failed because the file system type was RAW. But in Disk Management, it showed a healthy NTFS volume. (I tried diskpart at this point, and list disk didn’t even show the external drive.) In Disk Management, I tried setting the drive Offline. After that, the volume no longer displayed in Disk Management. vssadmin list shadowstorage returned information on the C: and D: drives, then this message:

Error: Unexpected failure: The request could not be performed because of an I/O device error.

At this point, I was able to finally able to run

vssadmin add ShadowStorage /for=\\?\Volume{efbd74c0-2e19-726e-b913-e2e696390a52}\ /on=\\?\Volume{efbd74c0-2e19-726e-b913-e2e696390a52}\ /maxsize=UNBOUNDED

Successfully added the shadow copy storage association

Hopefully that will allow backups to take snapshots. Unfortunately, vssadmin list shadowstorage was still returning the I/O device error message. In Disk Management, the external disk showed online but uninitialized, with Initialize grayed out, so not in a good state. I went to Device Manager, right-clicked on the computer name, and chose Scan for hardware changes. The external drive immediately disappeared from Disk Management, and vssadmin list shadowstorage no longer returns the I/O device error message. Hopefully that finally resolves this issue!