Minimum size requirements for VSS shadow copy on bitlocker volumes

Tim Kane 0

What is the default minimum disk space requirements to support VSS shadow copy on FAT32 volumes under Windows 11? What are the requirements when bitlocker is enabled/disabled?

I'm finding that for a Bitlocker protected FAT32 volume of size 1.5GB (or smaller) with near zero utilisation, the volume shadow copy service reports VSS_E_INSUFFICIENT_STORAGE

Note that I have not yet experimented with larger volume sizes.

If I disable bitlocker on that same volume, the volume shadow copy service runs just fine.

Is there some minimum size disk / available disk required to support shadow copy services on FAT32 volumes when Bitlocker is enabled? Please advise what that minimum should be.

I have no such issues with NTFS volumes (even as small as 512MB) wether bitlocker encrypted or not.

One observation is that ShadowStorage does not appear to be explicitly allocated, though I don't believe I should need to make any accomodation there unless absoluteley necessary


C:\Windows\System32>vssadmin list ShadowStorage

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool

(C) Copyright 2001-2013 Microsoft Corp.

No items found that satisfy the query.

Tim Kane 0 Reputation points

2024-11-24T02:40:58.3666667+00:00

Additional detail: I'm running Windows 11

There is no defined registry key matching [MinDiffAreaFileSize]()
Tim Kane 0 Reputation points

2024-11-24T02:42:12.0833333+00:00

Note that I do not observe any registry key matching MinDiffAreaFileSize

Windows 11 24H2
Tim Kane 0 Reputation points

2024-11-24T02:48:11.6633333+00:00

I should also note that IsVolumeSupported() returns true for such a volume, while it is the async response from DoSnapshotSet() that results in VSS_E_INSUFFICIENT_STORAGE
Tim Kane 0 Reputation points

2024-11-24T12:23:33.4633333+00:00
Okay, discovered a few things.. Larger FAT32 partitions make no difference..

vsstrace reveals:

THROW[CVssDiffAreaAllocator::PlanNewDiffAreas] Volume \\?\Volume{f772e52a-b588-48ea-8d4e-99884caf7a9a}\ [attributes = 0x00000001] must be able to support a diff area THROW[CVssSnapshotSetObject::EndPrepareAllSnapshots] insufficient diff area storage detected while calling EndPrepareAllSnapshots. Provider ID = {b5946137-7b9f-4925-af80-51abd60b20d5}

And this link gives some clues, but doesn't fully explain this situation.

In particular:

If the previous two criteria don't provide a location, the shadow copy service chooses a location based on available free space.

Further

Can VSS create shadow copies of non-NTFS volumes?

Yes. However, persistent shadow copies can be made only for NTFS volumes. In addition, at least one volume mounted on the system must be an NTFS volume.

That isn't happening.. I have multiple other drives mounted (that do not participate in the VSS backup set) that could be chosen as storage.

Does one of those drives need to participate in the VSS backup set for it to be used as storage for the FAT32 volume?

Or do I need to explicitly configure snapshot storage (or ask my users to) despite the above rules?
Tim Kane 0 Reputation points

2024-11-24T21:08:11.36+00:00

Great... vssadmin add storage seems to be limited to Windows Server..

How exactly is this intended to work?

Even something as simple as vshadow -q from an admin privileged developer console fails with VSS_E_UNEXPECTED returned from m_pVssObject->InitializeForBackup()

That's especially confusing, since my own code does not suffer that same fate
Tim Kane 0 Reputation points

2024-11-25T11:59:06.3+00:00

It gets even better..

Calling IVssBackupComponents::Query to enumerate available VSS_OBJECT_PROVIDER's causes a subsequent call to AddToSnapshotSet() to fail inexplicably with VSS_E_UNEXPECTED, while omitting the IVssBackupComponents::Query allows a succesful AddToSnapshotSet() to complete..

The original issue (VSS_E_INSUFFICIENT_STORAGE) remains unresolved

VSS functionality seems largely full of pitfalls so far :-/

1 answer

Ian Xue 38,301 Reputation points Microsoft Vendor

2024-11-26T03:09:15.3266667+00:00

Hi Tim Kate,

Thanks for your post. Generally speaking, there are some limitations for the VSS size. First of all, VSS supports a volume size of up to 64 TB. Secondly, it is recommended to allocate at least 30% of the volume to shadow copies. To learn more, refer to the Volume Shadow Copy Service article at docs.microsoft.com

Note. If the previous two criteria don't provide a location, the shadow copy service chooses a location based on available free space. If more than one volume is being shadow copied, the shadow copy service creates a list of possible snapshot locations based on the size of free space, in descending order. The number of locations provided is equal to the number of volumes being shadow copied.Best Regards,

Ian Xue

If the Answer is helpful, please click "Accept Answer" and upvote it.
Please sign in to rate this answer.
Tim Kane 0 Reputation points

2024-11-26T10:21:04.0833333+00:00

Thanks @Ian Xue

In this scenario, I have the following drive layout:

The circled drive (X:) is the only drive in the shadow set.

There is ample disk available on other volumes, as well as on this volume. In fact, the data store on this volume is zero bytes

IsVolumeSupported() returns true for this volume

If I disable bitlocker on this volume, the volume shadow copy services presents no issues, the issue only occurs when the volume is bitlocker encrypted

I have no such issue with other drives.

I can provide a vsstrace log if that helps, or perhaps there is a preferable place for me to submit a bug report with those details?

I'm particularly mindful of the vsstrace message: must be able to support a diff area which does not explain why it cannot, particularly given the volume is essentially empty (I've tried larger sizes for this volume, with minimal actual usage).

FWIW, I'm using a VM under Parallels with Windows for ARM. I'm going to test this on a physical x64 machine to see if I can replicate the issue there.. perhaps the issue is environmental.

Tim Kane 0 Reputation points

2024-11-28T12:07:46.1633333+00:00

I can confirm this I do not encounter this issue on a physical x64 machine running Windows 10

While I appreciate there are a number of variables, it seems there is at least an issue with VSS against bitlocker encrypted FAT32 volumes, on the ARM64 edition of Windows 11 24H2, when running as a VM under Parallels.

Due to a lack of available hardware, I cannot test all combinations.. I really only have 2 data points here

Operating System VM Bare metal

Windows 11 (24H2) ARM64 FAIL unknown

Windows 11 (24H2) X64 unknown unknown

Windows 10 ARM64 unknown unknown

Windows 10 X64 unknown PASS
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Minimum size requirements for VSS shadow copy on bitlocker volumes

1 answer

Your answer

Operating System	VM	Bare metal
Windows 11 (24H2) ARM64	FAIL	unknown
Windows 11 (24H2) X64	unknown	unknown
Windows 10 ARM64	unknown	unknown
Windows 10 X64	unknown	PASS