Reinhard, this may be one of those instances where your OS disk drive is very highly fragmented and snapshot is failing because of insufficient contiguous free space.

Try doing a full disk defrag for that OS drive to see if that makes a difference.

For help in setting your backup task to not use VSS but revert to the older Acronis snapshot function, then see forum post: https://forum.acronis.com/forum/45832#comment-346558 which will work for ATIH 2016

Will try tomorrow to defrag when the system is available.

I am also unable to create a manual Windows 7 restore point in windows 7 system restore function, I get an error message there for insufficiant space too. Regardless what %age I am specifying as amaximum.

Defrag Win 7 runs weekly and says 0% fragmentation. So that can`t be the cause.
Changed setting of ATI Profile use_VSS from true to false = will post results tomorrow.

Is there a System partiton on your Windows7 disk. If there is, that is most likey where the shadow copy will be placed. How much free space is there in the System Partition.

You should be okay by changing use_VSS from true to false.

Mustang wrote:

Is there a System partiton on your Windows7 disk. If there is, that is most likey where the shadow copy will be placed. How much free space is there in the System Partition.

You should be okay by changing use_VSS from true to false.

Yup, I just started learning this earlier this week.  You need at least 40% free space on your system parition for VSS to be able to run a snapshot backup. Problem is, the system parition is not assigned a drive letter so is not as easy to identify how much free space is available. Hopefully he can check disk management and verify the system parition free space though.

First thank you for the tip on switch setting in ATIH 2016 the backup profile: to change use_vss="true" to use_vss="false"

That worked fine, backup task ran through without a problem after that.

Now to the tip to check size of the System Drive.
In my case, Win 7-  Disk management table says "System Drv" 1.17GB, thereoff 291MB free, that is 24%.

That is 3x the 100MB shown in your example capture.jpg. Todays attempt  to set a manual System Restorepoint after the completet ATIH2016 Backup worked also without error. That did not work a couple of days ago- but a couple of restarts inbetween.

Reinhard, can you post a screen shot similar to the capture.jpg posted by Rob in his post to show your partitions with used / free space showing?

This topic of free space requirements for VSS has come up frequently lately. The requirement isn't a fixed percentage of free space. The amount of free space needed depends on the size of the partition being backed up. See this article: http://windowsitpro.com/virtualization/q-how-much-free-disk-space-does-…

The article mentions Hyper-V but the guidelines are general for Microsoft operating systems.

Good info Mark.  I don't know if that's the definitive space requirement, but possibly at least a rule of thumb for at least the system volume.  Size of the snapshot and spacce to put it on may still be a factor.  More good reads to add to what you supplied...

http://wiki.r1soft.com/pages/viewpage.action?pageId=20909583

https://technet.microsoft.com/en-us/library/cc734457(v=ws.10).aspx

I specifically am curios to see screenshots of what the system protection is setting at. I still notice mine being set to 100% use and not returning to a sane level after random backup intervals  I've turned off system protection completely, yet the slider will still be at 100% sometimes, while it clearly shows it's been disabled, and this is occurring after it was already disabled to begin with!!!! At least by having system protection turned off, it's not actually using any space for snapshots, but it makes me think there is still something fishy going on that could be contributing to this. 

Hi, Rob:

I think that the numbers quoted in the WindowsITPro article are definitive because I've seen the exact same numbers in several Microsoft-authored articles on msdn and TechNet, like the one I referred to in this post: https://forum.acronis.com/forum/128480#comment-404709. At least they seem to be definitive for Server 2008, 2012, and 2016 and for Windows 7, 8 and 10. I'm not positive about earlier operating systems.

I got bit by this a couple of years ago because I had 300 MB of free space on a 500 MB partition, and VSS backups would fail on that partition. Enlarging the partition a little fixed that problem.

Mark,

Walk me through it.  I need help understanding.

So is it more likely that a lack of free space on the system reserve partition is what's really preventing VSS backups when a full disk backup is being run, and less likely the amount of available free space on the OS parition?  Mmost of the users that are having issues, have plenty of space on C: so it seems like it would be the system parition that is the trouble spot?  

I also don't understand why some people have a system reserve partition that's 100Mb, some 350Mb, some 800Mb, etc.  I thought this was always 100Mb (by default) in Windows 7 and 350Mb for Win 8, 8.1 and 10.  However, mine is only 100Mb on my Win 10 Pro x64 laptop so that seems to debunk that information, or Microsoft isn't following it's own practices.  

http://www.howtogeek.com/192772/what-is-the-system-reserved-partition-and-can-you-delete-it/

How is it that some have an 800Mb system parition or something else unless they manually go in and set the size?

I don't have system protection on at the moment, but even then, vssadmin list shadowstorage, only shows my C: drive as a shadow copy storage volume.  To me, that would seem like it wouldn't matter how much free space I had on the system volume parition as it looks to be telling me VSS needs space on the C: drive.  

Why would Windows use C: as the shadow location and not the system parition?

Or is it only showing me the mounted volumes with drive letters, but VSS does the same thing in the background for those without mounted letters and then it might choke on the unmounted system parition if it had less than 50Mb since it's a 100Mb parition?

I'm more confused now that I started reading up on it...

C:\WINDOWS\system32>vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{be58b502-3be5-4da9-8ac2-b0ba45f9bbf4}\
   Shadow Copy Storage volume: (C:)\\?\Volume{be58b502-3be5-4da9-8ac2-b0ba45f9bbf4}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: 2.58 GB (5%)

It's usually not the OS partition that is causing the problem. That's what I was saying in reply #4 above. It was a few years ago that I ran into this problem with Acronis Backup and Recovery. The offending partition was a Recovery partition. If my memory serves me well, there was about 280 MB used of the 300 MB partition. That was not enough free space when doing a full disk backup using VSS. Telling the program to use snapman instead of VSS solved the problem. I ultimately solved the issue by replacing the existing WinRE.wim with a smaller version of WinRE.wim. I didn't worry about the change as it was the original 300 MB Recovery partition at the front of the disk. The system had undergone a Windows upgrade so Microsoft had created a new 450 MB Recovery partition at the end of the disk that was being used.

It was my understanding at the time that VSS was placing a shadow copy in each partition on the disk. I did some research and saw some posts claiming the location of the shadow copy could be moved to a different location by commands on the command line. However, it never worked in my case. It probably only works with partitions that have a drive letter assigned.

Paul:

You can only move the shadow copy to a different partition or disk if you have one of the server operating systems. The vssadmin commands that re-locate the shadow storage area do not work on the consumer operating systems (Windows 7, 8, 10). On these, by default, shadow copies are stored on each individual partition.

Your experience with VSS failing to snapshot a backup is just like mine; there wasn't enough free space on the Recovery Tools partition (in my case).

Rob:

Correct; the failure is most likely when attempting to back up either the System Reserved partition or the Recovery partition. Still, if VSS is used to create a snapshot for a backup, there needs to be the required amount of free space on each partition that is being backed up. Just because you have only enabled System Protection (Restore points and maybe Previous Versions (Windows Vista or 7)) on the large C: partition does not mean that VSS will have enough space to create snapshots on the other smaller partitions.

The System Reserved partition size and the size of any other Recovery partitions is a moving target. Microsoft has changed their recommended practices over the years and OEMs are free to add their own Recovery partitions of differing sizes (Dell, Lenovo, etc) to the disk. So that's why you see so many different sizes for the partitions. The latest Microsoft recommended disk layout for Windows 10 is here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufac… This article does a pretty good job of explaining the reasoning behind the layout recommendations.

That's pretty close to the layout that I am currently using. See the attached script that I used to create the layout on my desktop PC. I deliberately made the Recovery Tools partition large (2 GB) so that I could have copies of WindowsRE, MustangPE, and Win10PESE resident on the SSD. But that's just me.

Thanks Mark. This seems to indicate it will work on Windows 8. It's a 2012 article.

https://technet.microsoft.com/en-us/library/cc788051

It seems clear both the original and new destination partitions need drive letters, so it isn't of much help if the System or Recovery partition is the problem.

I didn't test it in Windows 10 as there is no need. It wouldn't prove anything anyway because I'm using the Enterprise version of Windows 10.

Paul:

Interesting. I don't have a copy of Windows 8 to test this on. However, the "vssadmin add shadowstorage" command does not exist on Windows 10. Trying to run it returns an error. It does exist on Server 2016, and it works there.

Thanks again Mark. I quick check on my Windows 10 Enterprise system yeilds the same result as you show for your Windows 10 system. The feature has been removed.

OK Steve Screenshot attached of Datenträgerverwaltung

Reinhard, thank you for posting the screen shot.  I suspect that the main VSS issue is being caused by your SYSTEM_DRV partition only have 24% (291MB) free space when this is being included in your backup task.

You should be able to test this by creating a new backup of just that one partition on its own.

Steve- will do when I have acces to that system again.
BUT:
Had checked different but same Lenovo type system 7 today- with ATIH 2015, Backup worked, all partitions included Sytem_Drive too.

Total size of SYSTEM_DRV same as in the screenshot, but 46% free space on it, hence double

How can I see the file content of SYSTEM_DRV without drive letter and subsequently delete files- and if so which ones can I delete? I do not want to kill the system by playing with SYSTEM_DRV.

Reinhard:

I agree with Steve's assessment. Your SYSTEM_DRV partition is larger than 1 GB; therefore for VSS to work on this partition you need at least 1 GB of free space on the partition. You only have 291 GB of free space.

*Edit*

The reason that TI 2015 backups work and TI 2016 backups fail is that TI 2015 did not use VSS for backups; it used the Acronis Snapshot Manager which does not have the same limitations as Microsoft's VSS.  Sorry for misinformation; Acronis started using VSS in 2015. The difference you noted between the two Lenovo machines has to be caused by the difference in the amount of free space on the SYSTEM_DRV partition then.

You could use Diskpart from a command prompt to assign a temporary drive letter to the partition if you want to see which files are located on the partition. Or you could boot from a Windows recovery CD and view the files. However, if you find out that Lenovo has some of their diagnostic programs located there and you do not want to remove them, then to make VSS work you will need the partition size to be larger. This will involve using partition software to shrink the Windows partition and enlarge the SYSTEM_DRV partition.

I think the simplest solution for you is to just set USE_VSS to FALSE so that you will use the Acronis snapshot manager for your backups.

Mark-Thanks a lot- that explains ATIH 2015 and 16 behavior.

I hope to set up a fresh windows 7 (factory level)  soon on such Lenovo system to see how the space on SYSTEM_DRV is used.

On ATIH 2017 the option does not exist to switch off Windows VSS, as I understand. The only way out there would be to exclude SYSTEM_DRV from backup if Backup fails with snapshot error or do a backup with ATI Boot CD.

Reinhard:

Sorry; I had to edit my previous comment due to a mistake on my part.

The option to switch off VSS is hidden pretty well in the TI 2017 interface, but it does exist. See the attached graphic.

The option for controlling VSS is new with the ATIH 2017 New Generation build but should be coming to the standard 2017 version when the next build is released soon.

I just did a new clean Windows 7 OS install on a friend's computer to recover from a problem and the default System Partition is normally just 100MB - though that was on a 160GB HDD main drive.

See KB document: 59440: Acronis True Image 2017: 'Snapshot for backup' option overview for further information on the new VSS options.

I'm still curious how someone ends up with a larger system reserved parition, and what ends up taking up the space on it!  Like Steve, I guess I'm used to seeing clean installs with "normal" \ healty 100MB or 350MB sizes for desktop OSes - actually all of mine are 100MB only, yet there is lots of documentation that says Win 7, 8, 8.1 and 10 should be350MB, but all the fresh installs of Win 10 I've done have all ended up with 100MB partitons.

All that I can think of is that when the OS was installed, there was a previous free space before it that got turned into the sytem reserved partition instead of Windows creating a new 100MB before the OS since  there were already multiple paritions.   I did read today that Vista/Server 2008 (non-R2 version) used to be 1.5Gb.  Perhaps some of these had VISTA at one point in time and upgraded along the way - I havent' touched VISTA in nearly a decade so have no idea if it really did use a 1.5GB system reserved paritition or not. 

OEM's have the ability to specify the size of the System partition and include what they want in it. The most common reason for setting it as 350 MB with Windows 7 is to include WinRE so it doubles as a boot partition and a recovery partition.

I guess that makes sense, but it sure is yucky that it's not standardized, especially if OEMS are not leaving enough free space to allow for snapshotting as most backups (including Windows embedded backup) need this to be able to complete a disk backup.  They could/should winre.wim files in a dedicated recovery partition.  Can't change what's been done already though.

Rading more about indexing being the culprit of the growing size in the reserved partiion as well... google "fsutil usn". / Makes me wonder if Acronis and/or other backup products rely on this to check for changes on the disk since the last backup, hence, making the log grow...up to whatever the set size of the log is anyway.

Ultimately, fix I keep reading is to use a parition tool like minitool and shrink the C drive some and give it to the system reserved partition.  For a 1.5GB system reserved parition though, I'd be really curious to know what's eating up all of that. 

Rob:

It also depends on whether your system is MBR or UEFI. On MBR systems, the System Reserved partition normally contains the files needed to boot Windows (Boot Manager, Language files, and the BCD) plus a copy of WinRE. A clean install of Windows to an empty disk will generally result in this partition and a second one for Windows.

UEFI systems boot from the EFI System Partition, which can be small (typically it is 100 MB) and WinRE is generally put in the Recovery Tools partition (typically 300 - 500 MB), typically at the end of the disk.

Like Paul said, OEMs can do this any number of different ways. Lenovo used to make the System Reserved Partition large enough to hold the files needed to boot Windows plus their own diagnostic and disk recovery tools. Then they reserve even more space at the end of the disk for a partition that contains their "Restore to Factory" image and WinRE.

Your comment about OEMs not leaving enough free space is a valid one. Enterprise PCs that are backed up by Windows Server Backup definitely need enough free space on each partition so that VSS can work during backups. Perhaps OEMs figure that their Enterprise customers are going to create their own master image anyway and will take this into account and that most home users do not back up so why worry about it?

Ironically, I remember posts on this forum asking Acronis to just use Microsoft VSS instead of their own proprietary snapshot manager. Problems like the one this thread is addressing didn't exist back then, did they? Now just look at how many users are getting tripped up by the Microsoft VSS free space requirements.

Yes, all true.  I would still think users would want to check to see what they actually have in there - might be able to free up space just with some maintenance - I'd be a little concerned if mine was 1.5Gb and nearly out of space - but I'm curious.

If not though, minitool makes this super easy to just make it bigger, assuming it doesn't just keep on growing.  Can grab from the C: drive, or another partition on the disk, just by selecting the system reserved parition, right click and clicking on "extend".  It will reboot and make the changes and should be good to go.

A note for anyone needing or wanting to do this, although minitool has been rock solid for me, I would always advised a full disk backup before resizing paritions - just in case.

Found a  newer MS article from January 2017 that shows the same info Mark posted earlier about parition sizes/free space for VSS to function correctly - MS doesn't make this stuff easy to find sometimes.  This is for UEFI systems...

UEFI/GPT-based hard drive partitions: 

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions

Windows partition requirements:

• System partition

  The device must contain a system partition. On GPT drives, this is known as the EFI System Partition, or the ESP. This partition is usually stored on the primary hard drive. The device boots to this partition.

  The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format.

  This partition is managed by the operating system, and should not contain any other files, including Windows RE tools.

  Note
  For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 = 256 MB.

  Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 = 32 MB, which is less than the 100 MB minimum size for this partition.

Recovery tools partition

This partition must be at least 300 MB.

This partition must have enough space for the Windows Recovery Environment tools image (winre.wim, typically between 250-300MB, depending on base language and customizations added), plus enough free space so that the partition can be captured by backup utilities:

• If the partition is less than 500 MB, it must have at least 50 MB of free space.
• If the partition is 500 MB or larger, it must have at least 320 MB of free space.
• If the partition is larger than 1 GB, we recommend that it should have at least 1 GB free.
• This partition must use the Type ID: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC.
• The recovery tools should be in a separate partition than the Windows partition to support automatic failover and to support booting partitions encrypted with Windows BitLocker Drive Encryption.

I'm wondering what happens in the System Partition when System Restore points are enabled in Windows. I have always disabled System Restore because it is such a disk space hog. I know you can set a limit to how much space it is allowed, but then you may only have enough space for one restore point.

My question is when a new restore point is created does space used on the System partition grow because of VSS snapshots?

Paul:

Based on what I think I know about Windows:

On Windows Vista or 7 if you have Previous Versions (shadow copies) enabled on the System Partition then the space used would grow ONLY if any files were changed. When Previous Versions is enabled the new file replaces the old file but the block-level changes (the older information that was replaced) are stored in a shadow copy on the disk so that older version(s) of a file can be re-created in the User Interface of Windows Explorer. Files on the System Partition rarely change, however.

Windows 8 and 10 did away with shadow copies in the user interface except for those that Windows Server creates on its own disks, so if you store files on a Windows Server you can access their previous versions in the File Explorer UI. I'm not positive that shadow copies are not still being created in the background but they are not accessible to the user in the normal fashion. If they aren't being created then the used space shouldn't grow at all unless a Windows Update replaces a file on the System Partition with a newer file that is larger.

Long story short - if you enabled System Protection on the System partition I doubt that, practically speaking, disk usage would grow since its files are rarely changed.

I'll try an experiment to see. I can't enable System Protection on the System Partition on my PC because it's UEFI and thus the partition is FAT32 and shadow copies require NTFS. Instead I just enabled System Protection on the Recovery Tools partition. This partition contains mostly unchanging files. The PC is backed up nightly by Windows Server Backup, which uses Microsoft's VSS. I'll watch it for a week and see how much space, if any, is consumed by System Protection. I'm betting none. Currently it shows 0 bytes. But we'll see after a week...

Thanks Mark. Good information.

MVP's

I am late to the party here but what a great read this thread is!  Mark provides a great look at VSS in his writing particularly his last post here.  I concur with his last post completely.  I agree that I would think his experiment will show no change in the Recovery Tools partition on disk as nothing will change.  I believe this would be true even if Windows does a major upgrade.  In my observations each time Windows does a major upgrade it creates another Recovery Partition in which to store a new recovery point.  Later in time when it is certain that the upgrade went smoothly the old Recovery partition is removed, at least that is what I believe I have witnessed on my curent Windows 10 UEFI GPT systems.  Windows 7 MBR systems would of course be different in this respect I believe.

I believe in the case of users whom have insufficient disk space VSS errors that are caused by not enough space in System partition is so due to the carelessness of OEM's.  As has been suggested the use of Minitool Partition Wizard or other third party partitioning tools to increase the size of such partitions is the answer but is unfortunate and should not be left to the end user to perform.

The part in this that puzzles me is that the System partition being FAT32 format cannot support a shadow copy as only NTFS volumes have the capability.  So the question is why does VSS fail in this regard?  Logic would say that since the System partition lacks support for shadow copy that VSS would ignore that volume.  We know howver that backup of the System partition is an essential part of a disk image necessary to insure bootabilty of a restored image so the System volume is backed up.  I wonder if in fact the System volume however is actually backed up by VSS or, is the backup of that volume done without VSS as in a standard folder/file backup?  If this is true then why does VSS error out on the fact that the System volume does not have enough space for a shadow copy?  I am still looking for answers to these questions!  

Bob:

Thread got started by Reinhard, who has a BIOS PC with MBR partitions. His System Reserved partition is NTFS, which supports shadow copies and does use VSS. Most standard installations of Windows on MBR partitions will result in NTFS partitions. His problem, as we think we have diagnosed correctly, is that he doesn't have enough free space on his System Reserved partition. I suspect that most people who have been bit by this problem are using MBR partitions.

My comment in reply #33 was about UEFI systems, which have a FAT32 EFI System partition. Most standard installations of Windows on UEFI systems will use the motherboard's FAT32 EFI System partition for the files that boot Windows (Windows Boot Manager, Language files, BCD).

But it brings up an interesting question. How does the Windows version of TI handle UEFI system backups? Has anybody done this and is the EFI System partition included in the backup? I've never tried this since I'm not backing up from the Windows version of TI. I always back up from the WinPE version of TI, which does back up the EFI System partition, so the PE version must be using the Acronis snapshot manager, correct?

Mark,

I do understand the OP having issue here with an NTFS System Reserve partition.  My comments were to any whom have UEFI GPT installs with FAT32 System partitions although I will admit that I have yet to see any users running such systems with this issue.  So my finger pointing at the OEM's I suppose is misdirected.

In answer to your question " How does the Windows version of TI handle UEFI system backups? " I cannot say exactly thus my questions.  As for " How does the Windows version of TI handle UEFI system backups?"  Yes I have done this and yes the EFI System partition is backed up.  If you use File Explorer to browse one of these backup files and you mount the file the Mount Wizard shows the expected partition which on a standard install are Recovery, EFI System and NTFS partitions.  If however you double click the backup file and drill down into it you will see displayed 3 drives in a graphical representation.  Interestingly, the Recovery one has no letter assignment, the next drive shown is that of the OS partition and does have a drive letter and the last one displayed has a drive letter and if you drill down in it you will find an EFI folder. 

My theory is that given the above observations I believe that the Recovery and OS partitions are backed  up using VSS but the EFI partition is backed up without it and performed as a folder/file backup.  With no other explanation I assume my theory correct until proven otherwise.

I think that backup from recovery media is performed without any snapshot and is my reason for prefering to backup using such media.  The VSS snapshot method creates a snapshot in a crash-consistent state which means that some corruption may exist.  So I prefer to have OS system images that are created using recovery media as my belief is that snapshots are not used.

Bob:

As for your theory about the EFI partition backup, TI might be making just a copy of the files but it would also need to save information about the size and location of the partition so that it could be re-created during a bare-metal backup.

An alternate theory might be that it is backed up like any other partition backup but without snapshotting. The EFI System partition is only in use during the initial phase of the boot process. You wouldn't need to take a point-in-time snapshot of a static partition.

I agree with your explanation of backups from recovery media being done without snapshots. That makes sense since the information on the partitions is static when backing up from recovery media.

Thanks! I had to look up "crash-consistent" and learned something new. Here's an article that explains the term: http://www.altaro.com/hyper-v/vss-crash-consistent-vs-application-consi…

Mark,

You make a very good point in backup of the EFI System partition.  I wonder if partition size and location on disk are held in metadata which might be used in recovery?  I think it obvious that VSS snapshotting is not used for the EFI System partition seeing how it is not supported so there is some method of coping the files in the partition as well as a way to record size and location on disk as you poiint out.

I checked out the link you provided and it is very good information on the various states of backup.  Makes you appreciate running OS disk backups while such disks are off line!

I also don't know how the UEFI System partition is being backed up from within Windows.

I do know that things are different when using the WinPE recovery media. Although, I don't know exactly what happens. First, the program will not run unless the fltsvr and snapman sercives are installed and running. Snapman is the snapshot manager service. Second, you see messages about the partitions being locked at the start of the backup. The Windows partition is actually locked twice before the backup starts. I always assumed snapman was taking a snapshot, but maybe that isn't true.  

My experience with WinPE is limited so have no idea what role snapman plays with respect to WinPE.  It would make some sense that as Windows WinPE might support snapshotting but lacks the services to perform that on its own so, TI recognizes that and runs snapman in absense of the VSS service in WinPE.

Traditinally I have done my OS disk images using the Linux based media.  Since Linux is not based on an NTFS file system I presume it does not use snapshotting to capture an image.  I believe it is a moot point anyway as given the source disk is in an offline state there can be no I/O going on and that is really what is of concern to me.  I also think that at present day there are less and less VSS unaware applications so that makes snapshotting less of a gamble.  Trouble is for me that Windows is rarely quiet when booted.  That fact is worrisome to me when desiring to backup Windows.  Maybe my worries are unwarranted but I am so used to running OS images using boot media it just is no big deal for me to continue doing so!

I use both Linux and WinPE version of the recovery media now due to the fact that the Linux media lacks support for Intel RAID and PCIe storage devices that use Intel Rapid Storage drivers.

Paul, given what you say about snapman and how it locks drive volumes with the Windows volume getting locked twice I wonder if the double lock might be that snapman first locks all blocks in the volume then once that is complete it locks the volume itself.  Interesting indeed!

Following up to share the results of my experiment mentioned in reply #33 - it has been a week since enabling System Protection on the Recovery Tools partition and as expected the disk usage by System Protection is still 0 bytes, and this after seven daily backups of the partition by VSS enabled Windows Server Backup. So I think this answers the question posed in reply #32.