Running Macrium destroys System Restore points

Sorry for repeating a question I've asked here before, but I've still
not been able to fix it.

Before installing Macrium my restore points remained intact for as long
as I wished or until storage capacity was reached, which was a matter of
MONTHS. After installing Macrium they are all now destroyed every week
when Macrium makes its scheduled full image. I simply want to know how
to fix that, in terms as close to plain english as possible please.

I find it hard to believe that this issue can be confined to me. I'd
have expected some documented detailed steps, or perhaps even a
one-click script to resolve it. But the explanations I've had from the
Macrium support people are largely over my head and essentially say it's
not a Macrium problem. I'll paste the last one verbatim here for those
with a deeper technical know-how than mine:

--------------------
"Macrium Reflect has no knowledge or direct interaction with the Shadow
Copy Diff area and it really is impossible to know precisely what
decisions Windows has made regarding the data stored there. I can only
speculate that as the oldest shadow, 'DataVolumeRollback' was created
without using VSS Writers then this may lead to smaller diff area than
shadows created with writers. The 'ClientAccessibleWriters' shadows
appear to have been created more recently so the changes made since then
may be small. Certain VSS Writers will cause the diff area to grow
larger when the shadow is created and we don't know whether these were
excluded from those shadows. All writers are included in a Reflect image
so the temporary diff area used during image creation will likely be
larger."
--------------------

Terry
Intel Core i7 6700K (4.0GHz), 32 GB Win 10 Pro Version 1909 (OS Build
18363.900)

Terry Pinnell wrote:

I find it hard to believe that this issue can be confined to me.

It isn't a problem here, because...

I have NEVER used Windows' "restore". Learned long ago Microsoft
utilities are garbage. They don't even work with other Microsoft
utilities.

Using Macrium Reflect is so easy. Open the program and click...

"Create an image of the partition(s) required to backup and restore
Windows"

Keep track of your personal files, and copy them to a secondary drive
before doing a restore. That's the main benefit of backup software. To
keep Windows from sinking. Keeping a simple backup of Windows works
wonders. Especially now that we almost NEVER get locked out of the
operating system. So you can always get in there to copy your personal
files, before getting rid of that copy of Windows. Using Macrium
Reflect, you can also access files in your Windows backups.

Talking about the free version.

Terry Pinnell wrote:
Sorry for repeating a question I've asked here before, but I've still
not been able to fix it.

Before installing Macrium my restore points remained intact for as long
as I wished or until storage capacity was reached, which was a matter of
MONTHS. After installing Macrium they are all now destroyed every week
when Macrium makes its scheduled full image. I simply want to know how
to fix that, in terms as close to plain english as possible please.

I find it hard to believe that this issue can be confined to me. I'd
have expected some documented detailed steps, or perhaps even a
one-click script to resolve it. But the explanations I've had from the
Macrium support people are largely over my head and essentially say it's
not a Macrium problem. I'll paste the last one verbatim here for those
with a deeper technical know-how than mine:

--------------------
"Macrium Reflect has no knowledge or direct interaction with the Shadow
Copy Diff area and it really is impossible to know precisely what
decisions Windows has made regarding the data stored there. I can only
speculate that as the oldest shadow, 'DataVolumeRollback' was created
without using VSS Writers then this may lead to smaller diff area than
shadows created with writers. The 'ClientAccessibleWriters' shadows
appear to have been created more recently so the changes made since then
may be small. Certain VSS Writers will cause the diff area to grow
larger when the shadow is created and we don't know whether these were
excluded from those shadows. All writers are included in a Reflect image
so the temporary diff area used during image creation will likely be
larger."
--------------------

Terry
Intel Core i7 6700K (4.0GHz), 32 GB Win 10 Pro Version 1909 (OS Build
18363.900)

There is a limit of 64 shadow copies in a desktop OS.

Normally shadow copies are volatile and released when
not being used. I would expect a Macrium Full to release
any VSS shadows it uses, after the backup is done.

Shadows may be used for System Restore, with a shadow per
restore point kind of thing.

If a system runs out of shadows, it's possible there
is some policy or procedure for recycling some of them.

The command

vssadmin list shadows

might be used to get some idea which ones are in usage.

If you're doing Macrium Incremental, Differential,
Incremental Forever, I expect this could use up to a
third of your shadows. At a guess. The System Restore
could use some, but then there's space tied to each one,
so it wouldn't be all that convenient for System Restore
to run amok and use all 64 of them.

Paul

Paul wrote:

Terry Pinnell wrote:

Sorry for repeating a question I've asked here before, but I've
still not been able to fix it.

Before installing Macrium my restore points remained intact for
as long as I wished or until storage capacity was reached, which
was a matter of MONTHS. After installing Macrium they are all now
destroyed every week when Macrium makes its scheduled full image.
I simply want to know how to fix that, in terms as close to plain
english as possible please.

I find it hard to believe that this issue can be confined to me.
I'd have expected some documented detailed steps, or perhaps even
a one-click script to resolve it. But the explanations I've had
from the Macrium support people are largely over my head and
essentially say it's not a Macrium problem. I'll paste the last
one verbatim here for those with a deeper technical know-how than
mine:

-------------------- "Macrium Reflect has no knowledge or direct
interaction with the Shadow Copy Diff area and it really is
impossible to know precisely what decisions Windows has made
regarding the data stored there. I can only speculate that as the
oldest shadow, 'DataVolumeRollback' was created without using VSS
Writers then this may lead to smaller diff area than shadows
created with writers. The 'ClientAccessibleWriters' shadows
appear to have been created more recently so the changes made
since then may be small. Certain VSS Writers will cause the diff
area to grow larger when the shadow is created and we don't know
whether these were excluded from those shadows. All writers are
included in a Reflect image so the temporary diff area used
during image creation will likely be larger."
--------------------

Terry Intel Core i7 6700K (4.0GHz), 32 GB Win 10 Pro Version 1909
(OS Build 18363.900)

There is a limit of 64 shadow copies in a desktop OS.

Normally shadow copies are volatile and released when not being
used. I would expect a Macrium Full to release any VSS shadows it
uses, after the backup is done.

Shadows may be used for System Restore, with a shadow per restore
point kind of thing.

If a system runs out of shadows, it's possible there is some
policy or procedure for recycling some of them.

The command

vssadmin list shadows

might be used to get some idea which ones are in usage.

If you're doing Macrium Incremental, Differential, Incremental
Forever, I expect this could use up to a third of your shadows. At
a guess. The System Restore could use some, but then there's space
tied to each one, so it wouldn't be all that convenient for System
Restore to run amok and use all 64 of them.

Did I miss the summary?
You know... "Therefore..."

On 2020-07-07 12:39 p.m., John Doe wrote:
Paul wrote:

Terry Pinnell wrote:

Sorry for repeating a question I've asked here before, but I've
still not been able to fix it.

Before installing Macrium my restore points remained intact for
as long as I wished or until storage capacity was reached, which
was a matter of MONTHS. After installing Macrium they are all now
destroyed every week when Macrium makes its scheduled full image.
I simply want to know how to fix that, in terms as close to plain
english as possible please.

I find it hard to believe that this issue can be confined to me.
I'd have expected some documented detailed steps, or perhaps even
a one-click script to resolve it. But the explanations I've had
from the Macrium support people are largely over my head and
essentially say it's not a Macrium problem. I'll paste the last
one verbatim here for those with a deeper technical know-how than
mine:

-------------------- "Macrium Reflect has no knowledge or direct
interaction with the Shadow Copy Diff area and it really is
impossible to know precisely what decisions Windows has made
regarding the data stored there. I can only speculate that as the
oldest shadow, 'DataVolumeRollback' was created without using VSS
Writers then this may lead to smaller diff area than shadows
created with writers. The 'ClientAccessibleWriters' shadows
appear to have been created more recently so the changes made
since then may be small. Certain VSS Writers will cause the diff
area to grow larger when the shadow is created and we don't know
whether these were excluded from those shadows. All writers are
included in a Reflect image so the temporary diff area used
during image creation will likely be larger."
--------------------

Terry Intel Core i7 6700K (4.0GHz), 32 GB Win 10 Pro Version 1909
(OS Build 18363.900)

There is a limit of 64 shadow copies in a desktop OS.

Normally shadow copies are volatile and released when not being
used. I would expect a Macrium Full to release any VSS shadows it
uses, after the backup is done.

Shadows may be used for System Restore, with a shadow per restore
point kind of thing.

If a system runs out of shadows, it's possible there is some
policy or procedure for recycling some of them.

The command

vssadmin list shadows

might be used to get some idea which ones are in usage.

If you're doing Macrium Incremental, Differential, Incremental
Forever, I expect this could use up to a third of your shadows. At
a guess. The System Restore could use some, but then there's space
tied to each one, so it wouldn't be all that convenient for System
Restore to run amok and use all 64 of them.

Did I miss the summary?
You know... "Therefore..."

Just checked mine and they are all there after my 11:00 daily scheduled
backup.
I never use them, too unreliable.
Macrium does a daily full backup, Very reliable.

Rene

John Doe wrote:


Did I miss the summary?
You know... "Therefore..."

There's two possibilities.

1) 64 shadow limit. The OP is running something which
is "holding onto" shadows. For example, using two backup
products at the same time, one of them might be possessive
of shadows. Only WinXP was volatile and cleared all of them on
a reboot. Later OSes support using the shadows across boots.

Any software tracking "generations", such as File History,
a shadow makes an excellent zero cost management mechanism.

2) Shadows are likely to have limited storage. I can think
of two controls. The System Restore has a capacity setting
in percent (or gigabytes). Perhaps something is sharing in
that pool, and when the pool is empty, stuff gets thrown away.

The Windows Backup stuff, there was a percentage of disk max setting
for it as well. This tended to be a hidden setting, so you'd need
a suitable tenforums.com tutorial to find out about it.

HTH,
Paul

Paul wrote:

There is a limit of 64 shadow copies in a desktop OS.

Maximum is 512. Default is 64. Since rare few users tweak the registry
setting, the vast majority can save 64 shadows.

https://docs.microsoft.com/en-us/win...w-copy-service
Section "What's the maximum number of software shadow copies created by
the system provider that I can maintain for a volume?"

Normally shadow copies are volatile and released when
not being used. I would expect a Macrium Full to release
any VSS shadows it uses, after the backup is done.

The 64 default is to accomodate multiple VSS-capable processes that may
be running concurrently, so it's a rather high count for its default. A
shadows should always be released after the process is done with a
shadow. Other than when it was generated by a particular process, it
has no value after the process is gone. I've not heard of multiple
programs trying to share a shadow.

Shadows may be used for System Restore, with a shadow per
restore point kind of thing.

I don't think the issue is with the disappearance of a shadow, but
rather with the disappearance of the system restore files which are
stored under the System Volume Information folder (normally hidden).

System Restore files are retained up to the configured maximum of
reserved storage. Reserving, say, 100GB does not immediately consume
that much of the drive's capacity. It is in reserve. That is the max
space the restore points can consume. When another restore point is
created, and if the reserve space is max'ed out, the oldest restore
points get permanently deleted to make room for the new one.

The OP didn't mention what he configured for the reserved space size for
System Restore?

However, if the OP is saving image backups, why waste the space to save
restore points? Once I got a a month of image backups (monthly full,
weekly differentials, daily incrementals) and 1 more full backup, I
disabled System Restore. Image restores are reliable and return the
partition(s) back to their prior state. System restores are not
reliable, and result in a hodgepodge state after a restore.

Other than filling up reserved space for restore points which purges the
oldest to make room for the newest (which would have a lot higher
turnover if the reserved space was small), I don't see Macrium Reflect
doing anything with restore files. Reflect does not create a restore
point before it runs a backup job. However, it is possible to add pre-
and post-commands to backup jobs, like running CCleaner as a pre-command
(ccleaner.exe /auto), or the Windows cleanup wizard (cleanmgr.exe with
the sage parameter if previously saved), or another cleanup tool to
prevent garbage from getting included in a backup, and the cleanup tool
could be getting rid of restore points.

Running backup jobs by Macrium Reflect does not delete restore point
files. A command added to a backup job might delete restore points.
Installing Reflect will create a restore point hence possibly deleting
the oldest restore point to make room for a new one.

The OP never mentioned if "running Macrium" (which presumably means the
Reflect product, since Macrium is the company name, and they produce
multiple programs) means he was creating backup images or if he was
restoring from them. When creating backup image, it is Microsoft that
decided that restore points are NOT included in the shadow. After all,
if you're using a backup program, especially one that saves and restore
images of the partition(s), you certainly are not relying on restore
points to further do some additional restore. Since files for System
Restore are not included by VSS when creating a shadow, the backup
program won't have those files in the shadow to save into the image
backup file.

Long ago, when users had to use a backup+OS environment on boot up (VSS
got introduced in Windows XP, and not available before then), VSS wasn't
even needed. All files in the OS partitions were quiescent. None were
in use. The OS was not loaded from the disk. Instead the OS and the
backup program were loaded from bootable media (other than the disk),
like from a CD or boot-time image (.dat) file. Since all files in the
target partition(s) were quiescent, none were in use, so backup programs
didn't have a problem with those files changing or getting locked during
a backup job. That's about the only way I can see that a backup program
wouldn't need to use VSS (which does not include the restore points).
Alternatively, there are some backup programs that use their own VSS
writer, and it's up to them if they wanted to include restore points.
Since you're using an image backup program, restore points are
superfluous and a waste of space.

The shadow(s) created by Microsoft's VSS do not have the restore points,
so backup programs using the shadow(s) won't have them, either, to
include in their backups. However, "running Macrium" doesn't say if the
OP is creating backups or if he is restoring from them. Most would
assume the OP is capturing a live OS (running the backup program within
Windows and using VSS) rather than ensuring the OS is quiscent by
booting to an alternate OS under which the backup program is ran and
when VSS is not applicable. Macrium Reflect can be ran as a program
within a live OS, or in rescue mode as a boot-time image (.dat file in
boot menu, or on separate media, like CD) running its own OS where VSS
isn't needed.

You are not authorised to read my posts in plain text. Please install HTML enabled newsreader, such as latest Thunderbird https://www.thunderbird.net, to benefit from solutions posted in my posts.

--

With over 1.2 billion devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

???? Good Guy ???? wrote:
[-- text/plain, encoding 8bit, charset: utf-8, 8 lines --]

You are not authorised to read my posts in plain text. Please install HTML enabled newsreader, such as latest Thunderbird https://www.thunderbird.net, to benefit from solutions posted in my posts.

Why no plain text format?
--
Life is so crazy! ..!.. *isms, sins, hates, (d)evil, illnesses (e.g., COVID-19/2019-nCoV/SARS-CoV-2), deaths, heat waves, fires, out(r)ages, unlucky #4, 2020, greeds, etc.
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org /
/ /\ /\ \ http://antfarm.ma.cx. Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

Paul wrote:
John Doe wrote:


Did I miss the summary?
You know... "Therefore..."

There's two possibilities.

1) 64 shadow limit. The OP is running something which
is "holding onto" shadows. For example, using two backup
products at the same time, one of them might be possessive
of shadows. Only WinXP was volatile and cleared all of them on
a reboot. Later OSes support using the shadows across boots.

Any software tracking "generations", such as File History,
a shadow makes an excellent zero cost management mechanism.

2) Shadows are likely to have limited storage. I can think
of two controls. The System Restore has a capacity setting
in percent (or gigabytes). Perhaps something is sharing in
that pool, and when the pool is empty, stuff gets thrown away.

The Windows Backup stuff, there was a percentage of disk max setting
for it as well. This tended to be a hidden setting, so you'd need
a suitable tenforums.com tutorial to find out about it.

HTH,
Paul

https://support.barracudamsp.com/Kno..._Storage_Space

vssadmin resize shadowstorage /on=x: /for=x: /maxsize=20%

Even listing shadowstorage would be a start.

Paul

VanguardLH wrote:

Paul wrote:

There is a limit of 64 shadow copies in a desktop OS.

Maximum is 512. Default is 64. Since rare few users tweak the registry
setting, the vast majority can save 64 shadows.

https://docs.microsoft.com/en-us/win...w-copy-service
Section "What's the maximum number of software shadow copies created by
the system provider that I can maintain for a volume?"

Normally shadow copies are volatile and released when
not being used. I would expect a Macrium Full to release
any VSS shadows it uses, after the backup is done.

The 64 default is to accomodate multiple VSS-capable processes that may
be running concurrently, so it's a rather high count for its default. A
shadows should always be released after the process is done with a
shadow. Other than when it was generated by a particular process, it
has no value after the process is gone. I've not heard of multiple
programs trying to share a shadow.

Shadows may be used for System Restore, with a shadow per
restore point kind of thing.

I don't think the issue is with the disappearance of a shadow, but
rather with the disappearance of the system restore files which are
stored under the System Volume Information folder (normally hidden).

System Restore files are retained up to the configured maximum of
reserved storage. Reserving, say, 100GB does not immediately consume
that much of the drive's capacity. It is in reserve. That is the max
space the restore points can consume. When another restore point is
created, and if the reserve space is max'ed out, the oldest restore
points get permanently deleted to make room for the new one.

The OP didn't mention what he configured for the reserved space size for
System Restore?

However, if the OP is saving image backups, why waste the space to save
restore points?

Here are three reasons and I bet there are others:

1. SR is a complementary tool, not an alternative.

2. Simplicity. In a couple of clicks SR can often immediately fix an
accident or obscure issue. Restoring a Macrium image is something I’ve
never done so far and never hope to do. It seems a relatively
complicated and risky task for someone who is not a programmer, system
administrator or other techie! Just an experienced user wanting the
benefit of at least two insurance policies against OS file damage:
Macrium and SR.

3. One problem with restoring a disk image from Macrium is that I gather
it would also restore data. So personal files I keep on that partition
(for various reasons), which I have created or edited since my last
weekly Sunday Macrium image backup would have to be restored from my
regular nightly data backup. SR wouldn't touch those, avoiding that
extra task with another program.


Once I got a a month of image backups (monthly full,
weekly differentials, daily incrementals) and 1 more full backup, I
disabled System Restore. Image restores are reliable and return the
partition(s) back to their prior state. System restores are not
reliable, and result in a hodgepodge state after a restore.

Other than filling up reserved space for restore points which purges the
oldest to make room for the newest (which would have a lot higher
turnover if the reserved space was small), I don't see Macrium Reflect
doing anything with restore files. Reflect does not create a restore
point before it runs a backup job. However, it is possible to add pre-
and post-commands to backup jobs, like running CCleaner as a pre-command
(ccleaner.exe /auto), or the Windows cleanup wizard (cleanmgr.exe with
the sage parameter if previously saved), or another cleanup tool to
prevent garbage from getting included in a backup, and the cleanup tool
could be getting rid of restore points.

Running backup jobs by Macrium Reflect does not delete restore point
files. A command added to a backup job might delete restore points.
Installing Reflect will create a restore point hence possibly deleting
the oldest restore point to make room for a new one.

The OP never mentioned if "running Macrium" (which presumably means the
Reflect product, since Macrium is the company name, and they produce
multiple programs) means he was creating backup images or if he was
restoring from them.

Quote from my post:
"After installing Macrium they are all now destroyed every week
when Macrium makes its scheduled full image." Obviously a backup, not a
restore.


When creating backup image, it is Microsoft that
decided that restore points are NOT included in the shadow. After all,
if you're using a backup program, especially one that saves and restore
images of the partition(s), you certainly are not relying on restore
points to further do some additional restore. Since files for System
Restore are not included by VSS when creating a shadow, the backup
program won't have those files in the shadow to save into the image
backup file.

Long ago, when users had to use a backup+OS environment on boot up (VSS
got introduced in Windows XP, and not available before then), VSS wasn't
even needed. All files in the OS partitions were quiescent. None were
in use. The OS was not loaded from the disk. Instead the OS and the
backup program were loaded from bootable media (other than the disk),
like from a CD or boot-time image (.dat) file. Since all files in the
target partition(s) were quiescent, none were in use, so backup programs
didn't have a problem with those files changing or getting locked during
a backup job. That's about the only way I can see that a backup program
wouldn't need to use VSS (which does not include the restore points).
Alternatively, there are some backup programs that use their own VSS
writer, and it's up to them if they wanted to include restore points.
Since you're using an image backup program, restore points are
superfluous and a waste of space.

The shadow(s) created by Microsoft's VSS do not have the restore points,
so backup programs using the shadow(s) won't have them, either, to
include in their backups. However, "running Macrium" doesn't say if the
OP is creating backups or if he is restoring from them.

To repeat:
"After installing Macrium they are all now destroyed every week
when Macrium makes its scheduled full image." Obviously a backup, not a
restore.

Most would
assume the OP is capturing a live OS (running the backup program within
Windows and using VSS) rather than ensuring the OS is quiscent by
booting to an alternate OS under which the backup program is ran and
when VSS is not applicable. Macrium Reflect can be ran as a program
within a live OS, or in rescue mode as a boot-time image (.dat file in
boot menu, or on separate media, like CD) running its own OS where VSS
isn't needed.

John Doe wrote:

Terry Pinnell wrote:

I find it hard to believe that this issue can be confined to me.

It isn't a problem here, because...

I have NEVER used Windows' "restore". Learned long ago Microsoft
utilities are garbage. They don't even work with other Microsoft
utilities.

Using Macrium Reflect is so easy. Open the program and click...

"Create an image of the partition(s) required to backup and restore
Windows"

Keep track of your personal files, and copy them to a secondary drive
before doing a restore. That's the main benefit of backup software. To
keep Windows from sinking. Keeping a simple backup of Windows works
wonders. Especially now that we almost NEVER get locked out of the
operating system. So you can always get in there to copy your personal
files, before getting rid of that copy of Windows. Using Macrium
Reflect, you can also access files in your Windows backups.

Talking about the free version.

See my reply to @VanguardLH

Rene Lamontagne wrote:

On 2020-07-07 12:39 p.m., John Doe wrote:
Paul wrote:

Terry Pinnell wrote:

Sorry for repeating a question I've asked here before, but I've
still not been able to fix it.

Before installing Macrium my restore points remained intact for
as long as I wished or until storage capacity was reached, which
was a matter of MONTHS. After installing Macrium they are all now
destroyed every week when Macrium makes its scheduled full image.
I simply want to know how to fix that, in terms as close to plain
english as possible please.

I find it hard to believe that this issue can be confined to me.
I'd have expected some documented detailed steps, or perhaps even
a one-click script to resolve it. But the explanations I've had
from the Macrium support people are largely over my head and
essentially say it's not a Macrium problem. I'll paste the last
one verbatim here for those with a deeper technical know-how than
mine:

-------------------- "Macrium Reflect has no knowledge or direct
interaction with the Shadow Copy Diff area and it really is
impossible to know precisely what decisions Windows has made
regarding the data stored there. I can only speculate that as the
oldest shadow, 'DataVolumeRollback' was created without using VSS
Writers then this may lead to smaller diff area than shadows
created with writers. The 'ClientAccessibleWriters' shadows
appear to have been created more recently so the changes made
since then may be small. Certain VSS Writers will cause the diff
area to grow larger when the shadow is created and we don't know
whether these were excluded from those shadows. All writers are
included in a Reflect image so the temporary diff area used
during image creation will likely be larger."
--------------------

Terry Intel Core i7 6700K (4.0GHz), 32 GB Win 10 Pro Version 1909
(OS Build 18363.900)

There is a limit of 64 shadow copies in a desktop OS.

Normally shadow copies are volatile and released when not being
used. I would expect a Macrium Full to release any VSS shadows it
uses, after the backup is done.

Shadows may be used for System Restore, with a shadow per restore
point kind of thing.

If a system runs out of shadows, it's possible there is some
policy or procedure for recycling some of them.

The command

vssadmin list shadows

might be used to get some idea which ones are in usage.

If you're doing Macrium Incremental, Differential, Incremental
Forever, I expect this could use up to a third of your shadows. At
a guess. The System Restore could use some, but then there's space
tied to each one, so it wouldn't be all that convenient for System
Restore to run amok and use all 64 of them.

Did I miss the summary?
You know... "Therefore..."

Just checked mine and they are all there after my 11:00 daily scheduled
backup.
I never use them, too unreliable.
Macrium does a daily full backup, Very reliable.

Rene


Do you have any stats please? IOW, for SR and Macrium respectively, over
the same period, how many runs and how many failures?

For me, a rough guess over say the last year would be something like:
SR: 5 runs, 0 failures
MR: 0 runs, 0 failures.

Paul wrote:

Paul wrote:
John Doe wrote:


Did I miss the summary?
You know... "Therefore..."

There's two possibilities.

1) 64 shadow limit. The OP is running something which
is "holding onto" shadows. For example, using two backup
products at the same time, one of them might be possessive
of shadows. Only WinXP was volatile and cleared all of them on
a reboot. Later OSes support using the shadows across boots.

Any software tracking "generations", such as File History,
a shadow makes an excellent zero cost management mechanism.

2) Shadows are likely to have limited storage. I can think
of two controls. The System Restore has a capacity setting
in percent (or gigabytes). Perhaps something is sharing in
that pool, and when the pool is empty, stuff gets thrown away.

The Windows Backup stuff, there was a percentage of disk max setting
for it as well. This tended to be a hidden setting, so you'd need
a suitable tenforums.com tutorial to find out about it.

HTH,
Paul

https://support.barracudamsp.com/Kno..._Storage_Space

vssadmin resize shadowstorage /on=x: /for=x: /maxsize=20%

Even listing shadowstorage would be a start.

Paul

Thanks Paul. Mostly outside my know-how area but your comments seem
consistent with those from Macrium.

Does this paste from an elevated command prompt run offer any clues
please?

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

Contents of shadow copy set ID: {5006c321-59ec-4456-bc54-690f3bb6c86f}
Contained 1 shadow copies at creation time: 07/07/20 12:03:40
Shadow Copy ID: {244971bf-e7d6-4e3a-bd5e-e590067f142a}
Original Volume:
(C\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy11
Originating Machine: Terry-2016
Service Machine: Terry-2016
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release,
Differential, Auto recovered

Contents of shadow copy set ID: {b62323b3-95bf-479e-874d-0bb2b17a745d}
Contained 1 shadow copies at creation time: 04/11/18 06:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
Original Volume:
(G\\?\Volume{00028375-0000-0000-0000-100000000000}\
Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Originating Machine: Terry-2016
Service Machine: Terry-2016
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: DataVolumeRollback
Attributes: Persistent, No auto release, No writers,
Differential
--------------------




And to see storage usage:
--------------------
C:\WINDOWS\system32vssadmin list shadowstorage /for=C:
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{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Shadow Copy Storage volume:
(C\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Used Shadow Copy Storage space: 416 MB (0%)
Allocated Shadow Copy Storage space: 753 MB (0%)
Maximum Shadow Copy Storage space: 11.9 GB (5%)
--------------------
That doesn't seem to indicate any attempt to use more space (416 MB)
than that allocated (11.9 GB)?

Also, if it helps, my last regular weekly MR full backup was on Sunday
5th July and its configuration looks like this:
https://www.dropbox.com/s/lgvquvd88i...Both.jpg?raw=1

Terry Pinnell wrote:
Paul wrote:

Paul wrote:
John Doe wrote:

Did I miss the summary?
You know... "Therefore..."
There's two possibilities.

1) 64 shadow limit. The OP is running something which
is "holding onto" shadows. For example, using two backup
products at the same time, one of them might be possessive
of shadows. Only WinXP was volatile and cleared all of them on
a reboot. Later OSes support using the shadows across boots.

Any software tracking "generations", such as File History,
a shadow makes an excellent zero cost management mechanism.

2) Shadows are likely to have limited storage. I can think
of two controls. The System Restore has a capacity setting
in percent (or gigabytes). Perhaps something is sharing in
that pool, and when the pool is empty, stuff gets thrown away.

The Windows Backup stuff, there was a percentage of disk max setting
for it as well. This tended to be a hidden setting, so you'd need
a suitable tenforums.com tutorial to find out about it.

HTH,
Paul
https://support.barracudamsp.com/Kno..._Storage_Space

vssadmin resize shadowstorage /on=x: /for=x: /maxsize=20%

Even listing shadowstorage would be a start.

Paul

Thanks Paul. Mostly outside my know-how area but your comments seem
consistent with those from Macrium.

Does this paste from an elevated command prompt run offer any clues
please?

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

Contents of shadow copy set ID: {5006c321-59ec-4456-bc54-690f3bb6c86f}
Contained 1 shadow copies at creation time: 07/07/20 12:03:40
Shadow Copy ID: {244971bf-e7d6-4e3a-bd5e-e590067f142a}
Original Volume:
(C\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy11
Originating Machine: Terry-2016
Service Machine: Terry-2016
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release,
Differential, Auto recovered

Contents of shadow copy set ID: {b62323b3-95bf-479e-874d-0bb2b17a745d}
Contained 1 shadow copies at creation time: 04/11/18 06:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
Original Volume:
(G\\?\Volume{00028375-0000-0000-0000-100000000000}\
Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Originating Machine: Terry-2016
Service Machine: Terry-2016
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: DataVolumeRollback
Attributes: Persistent, No auto release, No writers,
Differential
--------------------




And to see storage usage:
--------------------
C:\WINDOWS\system32vssadmin list shadowstorage /for=C:
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{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Shadow Copy Storage volume:
(C\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
Used Shadow Copy Storage space: 416 MB (0%)
Allocated Shadow Copy Storage space: 753 MB (0%)
Maximum Shadow Copy Storage space: 11.9 GB (5%)
--------------------
That doesn't seem to indicate any attempt to use more space (416 MB)
than that allocated (11.9 GB)?

Also, if it helps, my last regular weekly MR full backup was on Sunday
5th July and its configuration looks like this:
https://www.dropbox.com/s/lgvquvd88i...Both.jpg?raw=1

When I watch Macrium do backups, I see a few things happening.

vssadmin list shadowstorage

For a backup of C:, I see Macrium using some of the shadowstorage
that System Restore uses. So the System Restore setting seems
to be the setting for Shadows for the entire C: . It's not a private space.

If I backup R: , I can see a shadow opened on R: (presumably in System
Volume Information). The shadowstorage on R: is termed "unlimited", which
means no limiting value was set. Since System Restore status, is listed
as "Off" on R: , there's no possibility of a fight over the "unlimited"
shadow space.

*******

OK, for a backup of C: , if I keep running

vssadmin list shadowstorage

while the backup runs, the used shadow storage grows by maybe 100MB. And
the size of the used space does not decrease once Macrium is finished and
I exit.

You could increase the setting in System Restore and make it much
larger, and while a backup is running, see if the used space becomes
larger for some reason. The space used in shadowstorage during a backup,
seems to be happening at the beginning, when Macrium scans C: for files.

The only disadvantage of making C: shadowstorage larger, is more restore
points could be created than intended. They won't "roll over" properly then.

Paul