TI 2021 Backup Changing System Restore Max Space to 100%

Walt, the first suggestion here is to download and run the Acronis VSS Doctor tool to see if this reports any issues in that area, and to allow it to fix any matters that it offers to do so for.

VSS shares the use of free space on drives that is also used by System Protection / restore points, so it is possible that this has to be increased in order to create snapshot data for the backup tasks being performed.

See link in my signature for the VSS Doctor tool.

Thanks, Steve.  Will give that a look. This is no more than a nuisance, but I would like to get it fixed.  System restore is easier than restoring everything from backup, so I don't want to turn it off for my system drive.

So VSS Doctor found that my target drive for the backups (external USB drive) has no allocated space for VSS.  This is all it found.  The C drive, which is the only drive on which I have enabled system restore, is fine.  It complained about one of the small partitions on the system drive (recovery or EFI) which I ignored.  I'm not familiar enough with how VSS is used to know if this issue with the target drive is something that needs fixing.  It wanted to allocate 94GB.  I have that much available, but I did not say "fix".

Walt, can you attach the VSS Doctor output report as a text file attachment please.

Sure.  Here you go.

Walt, I was puzzled initially as to why there would be any VSS storage allocated to a backup drive (unless was being used as a backup source to somewhere else) but then re-read your earlier post about the drive you have allocated System Restore space for.

Please double check in System Protection when you have the G: drive connected whether it has any system restore space allocated?

On my own system, the only drives with VSS storage allocated are those that are used as the backup source for my backup tasks for Disk backups.

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{7010e475-358d-40aa-bec7-b265e243134c}\
   Shadow Copy Storage volume: (C:)\\?\Volume{7010e475-358d-40aa-bec7-b265e243134c}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: UNBOUNDED (100%)

Shadow Copy Storage association
   For volume: (D:)\\?\Volume{deea6c64-6f61-4c25-a982-25f9cf2c57e5}\
   Shadow Copy Storage volume: (D:)\\?\Volume{deea6c64-6f61-4c25-a982-25f9cf2c57e5}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: UNBOUNDED (1868251646%)

C:\WINDOWS\system32>

Note: I do not have System Protection enabled for any of my drives, so no restore point storage allocated.

Steve,

Here is a report with both of the USB drives connected, G: and H:.  These drives are not GPT format because MBR2GPT said they were not "convertible".  I've never had any issues using them.  My inclination right now is to just live with this and reset the system protection space when I run TI.  (I have no idea what the Event Log entry is about.  I looked it up and still have no idea.)

Walt

Walt, I would second your inclination if you are not seeing any specific or significant issues from the matters flagged in the VSS Doctor report.

Walt,

First, Windows System Restore disk space and VSS Shadow Copy space are both controlled by the Windows OS and users do not have any meaningful control over that management.  You will see a myriad of articles on the vssadmin tool and its use for management however, those articles apply to only Windows Server operating systems and even though some of the commands do work in consumer Windows OS's these attempts are short lived due to OS management of installed disk space.

As for your event log entry, the entry suggests that Disk 5 in your system has the same disk identifier or Disk ID as another installed disk in your PC.  Since Windows begins disk numbering at 0 the log is targeting Disk 4 in your system which is your letter G: drive.  What you need to do here is use the diskpart utility from an admin command prompt or an admin PowerShell prompt to discover the Disk ID's of your installed disks and then make sure that there are not two disks that share the same Disk ID.  Having two disk that share Disk ID create a situation known as disk signature crash and will BSOD your system and can corrupt your boot files.

I am pasting below the commands necessary for you to run to perform this task:

Note: taken from my own system. Diskpart commands are underlined.  Disk ID is bolded.

Microsoft Windows [Version 10.0.19042.985]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>diskpart

Microsoft DiskPart version 10.0.19041.964

Copyright (C) Microsoft Corporation.
On computer: DESKTOP

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          931 GB  1024 KB        *
  Disk 1    Online          931 GB  1024 KB        *
  Disk 2    Online         1863 GB      0 B        *
  Disk 3    Online          465 GB  1024 KB        *
  Disk 4    Online          465 GB  1024 KB        *
  Disk 5    Online          465 GB  1024 KB        *
  Disk 6    Online          465 GB  1024 KB        *
  Disk 7    Online         3726 GB  1024 KB        *
  Disk 10   Online          476 GB  1024 KB        *
  Disk 11   Online          232 GB  1024 KB        *
  Disk 17   Online           18 TB      0 B        *

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> detail disk

Samsung SSD 860 EVO 500GB
Disk ID: {67B7BE52-2FF3-435E-862E-E671E9FC8057}
Type   : RAID
Status : Online
Path   : 0
Target : 0
LUN ID : 0
Location Path : PCIROOT(0)#PCI(1700)#RAID(P00T00L00)
Current Read-only State : No
Read-only  : No
Boot Disk  : No
Pagefile Disk  : No
Hibernation File Disk  : No
Crashdump Disk  : No
Clustered Disk  : No

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   User Files   NTFS   Partition    931 GB  Healthy

DISKPART> exit

You will need to run the commands shown for each installed disk independently and then compare all Disk ID's. 

There are reports online of Windows failing to properly commit all disk writes to disk prior to a sleep or shutdown event which leaves the system in an unstable state thus the disk will receive an identifier of all zeros which of course is incorrect.  This seems to be an issue on systems where card readers are installed.  By your system specs it appears that you are using a desktop machine, probably home built or by a boutique shop.  If you use a card reader and have it attached to the PC it should show up in the diskpart list disk command.  You can check the Disk ID of a card reader using the above commands.  If no card is present in the reader than the ID will likely be all zeros which of course is correct but if the condition outlined here presents itself this can cause the event shown at a minimum and/or a BSOD at worst.

Three suggestions here, one is make certain that when you disconnect your USB external disks (this includes flash drives) that you use the Eject disk feature in Windows to remove the disk from the OS prior to disconnection.  Second,  use Device Manager to uninstall your card reader then, restart your PC and let Windows rediscover the reader.  This action may correct the situation as well.

Third, if you find this to be the case and your card reader is an internal one then I recommend that you disable Fast Startup in Windows Power Options.  Actually, I recommend that in any case.  Doing so may help solve the issue.  If your card reader is an external model (presuming you have a reader of course) then do not leave it attached to your PC when not in use.

Enchantech,

Thanks for the comments.  I have no card reader other than a very seldom used USB one that is not on my system unless I use my old Nikon camera, which is almost never.  The computer was built by me.  I will check the device IDs, but this almost HAS to be the two USB drives G and H because I've never seen that event before.  I almost never have both of those drives connected at the same time because of the way I do backups.  I connected them together only to run VSS Doctor as suggested by Steve.  However, I will take a look via diskpart at the device IDs.  Disks 4 and 5 are the two USB drives.

Walt

Enchantech,

Just to follow up, I connected both of the USB drives.  I ran diskpart and checked the IDs of disks 0-5.  0 is my system SSD, 1 and 2 are a windows RAID set, 3 is a virtual drive, 4 and 5 are USB connected hard drives used for backup. Drives 0-3 show device IDs that are GUID format.  Drives 4 and 5 show 8 digit hex numbers.  NONE OF THESE IDs ARE THE SAME. 

The USB drives are NOT GPT drives.  All the rest are.  I cannot run MBR2GPT on them because windows tells me I cannot.  I have not investigated that as the drives seem to work just fine for backup and restore.  I cannot explain the event log entry unless I'm (obviously) missing something.

Walt

Enchantech wrote:

... What you need to do here is use the diskpart utility from an admin command prompt or an admin PowerShell prompt to discover the Disk ID's of your installed disks and then make sure that there are not two disks that share the same Disk ID.  Having two disk that share Disk ID create a situation known as disk signature crash and will BSOD your system and can corrupt your boot files.

FYI, The MVP Assistant, System Configuration will show this information (and more).

Enchantech,

Did you read my post?  That's what I did.  There are NO two devices with the same Disk ID. I've also found articles on the web where this error comes up for no apparent reason.

Incidentally, while I had all my drives mounted to run diskpart, the warning did not appear in the event log.

Walt

Walt,

Okay, that is good news that you do not have two disks with the same Disk ID.  I suspected as much however it pays to make sure to avoid a signature collision.

I suspect that the error is something that occurs infrequently on your system.  Do you always use Windows Eject feature when removing your USB disks (including flash drives)?  Device ID's have a way of hanging around if you will if not ejected.  I know that there are lots of post on the net about this seemingly no apparent reason error, I am of the opinion that not ejecting USB disks is the root cause of the error.  I know that on occasion a none ejected disk will not remove itself completely and Windows as a result will show a phantom mounted drive letter present when it does not exist.  A virtual disk can create the same phantom mount as can a mapped drive.

Walt, I am not sure what issue you are concerned with here, but it looks like something Enchantech and I were dealing with last December in trying to understand the process.

What I saw was that after the backups ran, the Maximum Shadow Copy Storage Space would be left at 100%. What I found was that it only occurred for my system drive.

Today, I turned off Protection on my system drive to see if the symptom changed, but it did not. During my nightly backup tonight it created a new Full backup of Files and Folders on both my C: and D: drives.

The attached file shows the results of vssadmin list shadowstorage monitoring during the later stages of the backup. The G: drive was not part of the backup and so it showed no changes. But both C: and D: were showing the maximum set to unbounded (100%) and the used space was changing a bit, even while the backup was wrapping up. The last few checks were after the file had been written and ATI was doing cleanup on an older version.

Note that at the end of the backup the used space is back to 0 for all drives. The D: drive has its maximum also reduced to 1% as configured but the C: drive is still unbounded.

I could never figure out why that happened or how to change the result. But all-in-all, it seems rather harmless so I really don't care. Walt, is there a reason you are concerned about it?

Additionally, in Device Manager if you view hidden devices you may see a bunch of grayed out Generic volume shadow copies under the Storage volume shadow copies branch. Again, harmless. They can be deleted.

Enchantec,

Yes, I do normally "eject" my USB drives, HOWEVER, I often have the issue where windows says the drive is in use (when it is not; an age old windows issue) and it refuses to eject.  In those cases, I just have to turn the drive off.  Both of my USB drives are "Quick Removal" which theoretically does not need to be ejected.

BrunoC,

You're correct.  It's just a nuisance, nothing more.  I'm not willing to turn off system restore.  However, knowing that this happens after TI backups is helpful.  I just have to remember to reset the amount of my system partition that can be used for restore points after backups.

It seems this has been around for at least 6 years, based on the posts here.  I'm not going to hold my breath for Acronis to fix it.  They appear too busy for us "backup only" users anyhow, so TI 2021 is probably my last upgrade.  I'll be moving on to some other backup software in the future.

Thanks for all the feedback to all.

Walt

Walt, rather than remembering, why don't you just put a vssadmin command in a batch file and run it as a post command on your backup task. Or, just set up a scheduled task to run it periodically.

Walt Northrup said:

Enchantec,

Yes, I do normally "eject" my USB drives, HOWEVER, I often have the issue where windows says the drive is in use (when it is not; an age old windows issue) and it refuses to eject.  In those cases, I just have to turn the drive off.  Both of my USB drives are "Quick Removal" which theoretically does not need to be ejected.

Theoretical Quick Removal is just that, theoretical meaning it may or may not work.  When it does not work we see the issue at hand here.  "Turning off" the troubled drive in this case is akin to simply pulling the USB cable from the device.  The one sure way to deal with it is to shutdown the PC then, unplug the USB cable and restart the PC.  Once device initialization takes place all will be normal again and the issue is cleared.

Walt Northrup said:

BrunoC,

You're correct.  It's just a nuisance, nothing more.  I'm not willing to turn off system restore.  However, knowing that this happens after TI backups is helpful.  I just have to remember to reset the amount of my system partition that can be used for restore points after backups.

It seems this has been around for at least 6 years, based on the posts here.  I'm not going to hold my breath for Acronis to fix it.  They appear too busy for us "backup only" users anyhow, so TI 2021 is probably my last upgrade.  I'll be moving on to some other backup software in the future.

The reset of free space of your system partition is not necessary.  System Restore will use only 3 to 5 percent of free disk space for restore points and when that limit is reached the oldest restore points will be deleted to make room for new ones.   This is all managed by Windows without user intervention.

Acronis does not need to fix anything here.  The only thing in common between System Restore and VSS is the fact that both use free disk space to do their work.  A backup file is going to require much more free space use for snapshot creation than System Restore does.  So with Acronis leveraging 100% of free space to create a backup it is actually making that backup more efficient than not doing so.  Acronis is well behaved here as once the backup is completed snapshot space is freed up meaning free disk space is returned to pre-backup capacity.

I decided to have a looksee into the VSS Requestor logs (in my case, this is using ATI 2019 although I suspect nothing is changed.

A log file is created for each backup. Here is a disk backup of my C: drive where I suspect it's increasing the size to 100%:

5/22/2021 12:00:04:797 PM [VssRequestor][T] C1: BackupComponents::IsVolumeSupported({B5946137-7B9F-4925-AF80-51ABD60B20D5}, \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\) status 0x0 result 1
5/22/2021 12:00:04:807 PM [VssRequestor][T] C1: Implementation::UpdateSizeForStorages: enabled, count of clients: 1
5/22/2021 12:00:04:807 PM [VssRequestor][T] ShadowStorageManagement::AddStorage: max space: -1, volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\ on storage \\?\Volume{319d4afe-babf-4fcf-ad3e-90407de32c12}\ result 0x80004001
5/22/2021 12:00:04:815 PM [VssRequestor][T] ShadowStorageManagement::ResizeStorage: max space: -1, volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\ on storage \\?\Volume{319d4afe-babf-4fcf-ad3e-90407de32c12}\ result 0x0
5/22/2021 12:00:04:815 PM [VssRequestor][T] C1: Shadow storage check result 0x0 (\\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\)

Later when the backup is complete, it restores the size:

5/22/2021 12:10:17:967 PM [VssRequestor][T] C1: Implementation::RevertStoragesToOriginal: enabled, count of changed storages: 1, count of clients: 0
5/22/2021 12:10:17:967 PM [VssRequestor][T] C1: Implementation::RevertStoragesToOriginal: volume: \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\
5/22/2021 12:10:17:967 PM [VssRequestor][T] ShadowStorageManagement::ResizeStorage: max space: 4986170941, volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\ on storage \\?\Volume{319d4afe-babf-4fcf-ad3e-90407de32c12}\ result 0x0

Now, when I look at the log for a Files/Folders backup involving both my C: and D: drives I see this before the backup starts... first the C: drive:

5/22/2021 07:00:07:464 PM [VssRequestor][T] C1: BackupComponents::IsVolumeSupported({B5946137-7B9F-4925-AF80-51ABD60B20D5}, \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\) status 0x0 result 1
5/22/2021 07:00:07:480 PM [VssRequestor][T] C1: Implementation::UpdateSizeForStorages: enabled, count of clients: 1
5/22/2021 07:00:07:480 PM [VssRequestor][T] ShadowStorageManagement::AddStorage: max space: -1, volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\ on storage \\?\Volume{319d4afe-babf-4fcf-ad3e-90407de32c12}\ result 0x80004001
5/22/2021 07:00:07:480 PM [VssRequestor][T] ShadowStorageManagement::ResizeStorage: max space: -1, volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\ on storage \\?\Volume{319d4afe-babf-4fcf-ad3e-90407de32c12}\ result 0x0
5/22/2021 07:00:07:480 PM [VssRequestor][T] C1: Shadow storage check result 0x0 (\\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\)

Then the D: drive:

5/22/2021 07:00:12:164 PM [VssRequestor][T] C4: BackupComponents::IsVolumeSupported({B5946137-7B9F-4925-AF80-51ABD60B20D5}, \\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\) status 0x0 result 1
5/22/2021 07:00:12:164 PM [VssRequestor][T] C4: Implementation::UpdateSizeForStorages: enabled, count of clients: 2
5/22/2021 07:00:12:164 PM [VssRequestor][T] ShadowStorageManagement::AddStorage: max space: -1, volume \\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\ on storage \\?\Volume{480d36f4-4576-49f5-8405-d672161d01ee}\ result 0x80004001
5/22/2021 07:00:12:174 PM [VssRequestor][T] ShadowStorageManagement::ResizeStorage: max space: -1, volume \\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\ on storage \\?\Volume{480d36f4-4576-49f5-8405-d672161d01ee}\ result 0x0
5/22/2021 07:00:12:174 PM [VssRequestor][T] C4: Shadow storage check result 0x0 (\\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\)

But after the backup is done, this is what I see:

5/22/2021 07:38:01:466 PM [VssRequestor][T] C4: Implementation::RevertStoragesToOriginal: enabled, count of changed storages: 2, count of clients: 0
5/22/2021 07:38:01:466 PM [VssRequestor][T] C4: Implementation::RevertStoragesToOriginal: volume: \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\
5/22/2021 07:38:01:466 PM [VssRequestor][T] C4: Implementation::RevertStoragesToOriginal: cannot find volume \\?\VOLUME{319D4AFE-BABF-4FCF-AD3E-90407DE32C12}\
5/22/2021 07:38:01:466 PM [VssRequestor][T] C4: Implementation::RevertStoragesToOriginal: volume: \\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\
5/22/2021 07:38:01:466 PM [VssRequestor][T] ShadowStorageManagement::ResizeStorage: max space: 5000900075, volume \\?\VOLUME{480D36F4-4576-49F5-8405-D672161D01EE}\ on storage \\?\Volume{480d36f4-4576-49f5-8405-d672161d01ee}\ result 0x0

Note that is does not resize the C: drive in this case because it "cannot find volume". Now the question I have is... who cannot find the volume? Is it True Image, or is it Windows?

I don't really want to beat this to death, but I do want to make sure you understand my original issue.  The issue is that after running a TI backup, the "slider" in "This PC>Properties>System Protection>Configure..." is set at 100%.  Unless I'm completely missing something, this says that Restore Points could, over time, gobble up your free space.  As a matter of fact, I have had this happen.  A malfunctioning game was generating restore points every time I ran it.  My system drive got 90% full before I realized what was going on.  These restore points were basically junk, so I just disabled system restore on that drive and got rid of them.  Before doing that, though, I noted that the slider was at 100%.  After it was cleaned up, I set it to a reasonable value.

I'm not overly concerned with whether this is TI or VSS.  To me, that is purely academic.  When I run TI backup, my slider goes to 100%.

Walt I understand.  The fact that TI increases the space allocation to 100% is expected behavior. 

Enchantech, yes it is expected behavior, but I don't believe it is correct behavior.

Walt, I understand your issue and we are talking about the same thing. The vssadmin setting to set the size is the same thing as the slider in System Protection.

As I mentioned earlier, you could make a simple batch script to restore the value to what you want and run it either as a post command or a scheduled task so it is automated and won't cause you any problem. If you need assistance doing that, let us know.

BrunoC,

OK, I created a .CMD file and then put that in as a post command.  I have to comment, though, if it's this easy, why hasn't Acronis done it?  Anyway, it passed the "test" button and I'll check it out after my next backup.

Thanks for the assist.

Walt

Walt, I'd like to know what type of backup you are running where you experience this behavior.

I've been doing some testing involving both Disk/Partition backups and File/Folders backups, and involving single or multiple source drives. In every case, the maximum storage is set to 100% during the backup but is restored to its prior value upon completion. The only exception is in the case of a File/Folders backup involving multiple source drives where my C: drive does not get restored but rather is left at 100%.

Is this your experience?

BrunoC

I never backup from multiple drives at once.  My backups are organized by type (videos, music, etc.) and those are all on one drive or another.  The only time I see the problem is when I backup my C: (system) drive.  This is an "image" backup, not a file backup, and the only image backup I do.  I do not think that it ALWAYS happens, so you may be seeing that as well.  I have not checked my non-image backups to see if they cause the issue, but I will take note of that.  I don't use scheduled backups, either.  I just backup when I think I need to.

BTW, I have not been able to use the "post processing" step.  I finally got it to "work", but the simple .cmd file that I created always says "vssadmin is not recognized...".  I've tried fully qualifying it, setting default to system32, etc. with no luck. The very same .cmd works from and admin command prompt.   I SUSPECT that it's some kind of security issue since you can only run it from an admin command prompt, but I can't prove it.  TI says it "succeeded" even when the return code is not zero!  Anyhow, I've pretty much decided, for a variety of reasons, to just keep and eye on the max usage and live with it.  I don't like the task scheduler idea because I have some backups that run for hours, and scheduling may be an issue.

Walt

Walt, when you say "image" backup, what do you mean? How is the backup task set up in ATI?

An image backup is a backup of an entire disc.  When you set it up, you don't specify a file tree of any kind.  It backs up the entire drive.  As it turns out, you can do an "image" backup of partitions.  For example, if you have an SSD for your system drive that is basically too large for just windows, and you partition that, you can exclude the "non windows" partition from the image backup so that TI backs up all the partitions on the disc except for that partition.  It's still an image backup because you have not selected by file or folder.

https://www.acronis.com/en-us/support/documentation/ATI2021/index.html#…

In my case, I have the SSD partitioned so that I can take advantage of its speed for working files, game files, etc.  There are 3 partitions other than my "extra" one that are part of the image backup: Recovery, EFI and C itself.  I always backup my Windows drive in this manner.  Because of activity, this will require VSS or some other snapshot type software for certain.

In the GUI, an image backup will show a picture of a "disc" on the left.  For a file backup, it will show a picture of a "folder" on the left.

As far as I know, to restore an image backup, you must have a TI "Rescue Disc" that is bootable.  You boot from that disc, and then restore from you backup disc to the "new" system drive.  You probably only need this backup if you system disc fails or gets completely screwed up.

Walt, what I was getting at was how you specifically set up the backup for the image (just trying to distinguish between cloning, sector-by-sector, disk/partition, file/folder).

What I interpret is that you have a Disk/Partition style backup task which selects all the partitions on your drive. But it also sounds like you may have a lettered partition in addition to the C: drive... what you refer to as the "non windows" or "extra" partition. Is this the case?

I have been doing some experimenting and have determined that the maximum shadow storage is set by True Image to unbounded (100%) while backing up but then restored to its prior value on completion of the backup. If only one drive is set to unbounded at a time, it gets restored OK. But if multiple drives are involved simultaneously then only the last one changed gets restored properly.

Would you mind doing a quick test. Manually restore the max storage to what you want for all your drives. Then run the command vssadmin list shadowstorage from an administrator level command prompt before running a backup, during the backup and then after the backup completes. Save the results to post here. Thanks.

It's always a good idea to restore the system disk from the rescue media. Otherwise, ATI has to reboot itself into a version that may not be as robust as using the rescue media, which must be booted in the same boot mode as your Windows system (UEFI or Legacy).

BrunoC

I am using disk/partition for this drive only.  ALL of my other backups are file/folder.  I don't actually backup all of the partitions on the drive, just the ones I listed.  The other partition on the drive is essentially a "utility" partition that does not get backed up ever.

OK, I can do that test.

Here is the test.  As you can see, everything worked.  However, as I have said, sometimes it works and sometimes it does not.  I haven't been able to determine what causes this behavior.

Walt, thanks for running the test. Of the three drives (C:, G: and E:), I can see that C: is the only one involved in this backup and the max storage is properly restored. Drive E: is already set to 100%. Is that where you want it? Just to be sure... are E: and G: on separate physical drives from C:?

You say your other backups are file/folder. Do any of those backups select from the C: drive as well as another drive? If so, that could be where the issue lies. I don't know anything about the schedule of these backups so hard for me to say.

BrunoC,

C is the only drive that has system restore enabled, so I'm not sure what that number means for E:.  I saw that as well.  E is my main data drive and is a 4TB raid set.

I lied earlier.  Yes, I DO in fact have one backup that backs up files form C and from E as welll as from virtual drive M.  I am running the same test on that now.  I'll let you know how it comes out.

Yes, E and G are separate physical drives.  G is the target drive for the backups.

Walt

Walt, even though protection is off for a drive, you can still configure the max storage through the System Protection box, or using vssadmin, e.g.
vssadmin Resize ShadowStorage /For=E: /On=E: /MaxSize=10%

For better clarity, it might be best to set E: to something other than 100% to see if it is properly handled.

If you find it leaving C: at 100%, can you also post the VSS Requestor log file. There's a log for each backup job, found in C:\ProgramData\Acronis\VssRequestorLogs.

BrunoC

That's the command I was trying to use as a "post" command for TI, but I could not make that work.  If you figure out how to do that, let me know.  I tried everything in my bag of tricks to no avail.

I have attached the file backup from multiple disk tests.  It failed to reset the max just as you had seen.  So, it appears I may have been blaming the wrong backup.  This was verified by checking the "slider" in System Protection.  100%.

My only concern is whether this is just the "intermittent" nature of the problem, or we actually have it isolated.

BrunoC,

Here is the VSS Requestor Log for the one that did not reset C properly.  Sorry, I forgot to include it.  It has your favorite "cannot find volume" text toward the end.

I discovered there is a way to run TI 2021 from the command prompt.  Push comes to shove, I can create a batch file that runs TI and then resets the maxsize.  I have tested this and it works.  The doc is for 2019, but 2021 is similar.  A few different naming schemes.  However, I feel this is a bit of a "kludge" and don't really like it.

Also, I took you advice and set the maxsize for E to 10%.

Walt

Walt,

Do this to automate the reset.

1. Create a Scheduled Task to do the vssadmin resize command(s) that you want. Be sure to select to run with highest privileges. You can leave it with no trigger. You may wish to resize all your drives as when the problem occurs it will fail on all but one drive.

2. Create a .bat file with this:
schtasks.exe /run /tn <task name>

3. Invoke the .bat file as a post-command.

Also, could you submit a problem report to Acronis on this issue and be sure to include a System Report and include a reference to this thread. I can't do so because my system that runs ATI 2021 has only one drive. I've been doing this analysis with ATI 2019.

EDIT:

In summary, the problem appears to occur when ATI sets the VSS MaxStorage to 100% (unbounded) on multiple drives simultaneously. This looks to happen only in Files/Folders backups involving multiple source drives. Upon completion of the backup, ATI wants to restore the MaxStorage to its prior value but only seems to remember it for the last drive it changed. It looks clear in the VSS Requestor logs.

BrunoC,

That is a much better idea than my "kludge" batch idea!  Thanks!  Wonder why my old brain didn't come up with that one?

Yes, I'll submit a problem report.  I'm going to include your summary if that's OK with you?

Walt

Thanks, Walt. Yes include the summary but also include a link to this thread.

I hope you are able to automate the restoration of MaxStorage well.

I've already implemented your idea successfully.  OK, I'll submit a report.

Believe it or don't, it took me till now to get Acronis to verify that this is indeed a problem.  Will be addressed in "a future update".  I fed them the info from this forum post, and a link to the post itself.  This post is just in case some of you have an interest and are wondering what happened.  Bruno C's suggestion is working just fine for me, so this is no longer a big problem.  However, it's a bug and they should still fix it.

Walt, thanks for getting the problem confirmed and glad my fix works for you too.