Macrium Support Forum

Could Macrium be a possible cause of my System Restore points disappearing?

https://forum.macrium.com/Topic33732.aspx

By terrypin - 22 January 2020 4:45 PM

For several months my System Restore points have been repeatedly vanishing and despite much research I have still not discovered the cause. It appears to be a fairly wide problem. This is one of the several threads in which it's being discussed
https://www.tenforums.com/backup-restore/146930-restore-points-being-deleted-4.html
and in post #14 of that someone suggested that Acronis could be a cause, referring to
https://forum.acronis.com/forum/acronis-backup-117/windows-10-system-restore-show-more-restore-points-box-missing-and-restore-points-being-deleted-or-missing#comment-form

In post #54 of the Win 10 forum thread at least one of the sufferers then confirmed that.

So, although it's admittedly a leap (sign of my desperation!) I'm wondering if the experts have any view on whether Macrium could have a similar issue please?

By jphughan - 22 January 2020 5:01 PM

Depending on the circumstances under which you're seeing this, then Reflect could be an indirect cause.

First, it's important to understand that Reflect and many other image backup solutions (and various other types of tools) rely on a component in Windows called VSS (Volume Snapshot Service). Omitting a bunch of details, VSS can generate a point-in-time snapshot of a live partition, which is what Reflect uses as the source for its backup and what makes it possible to create a valid backup of a partition or set of files that are actively being used.  System Restore points are actually "permanent" VSS snapshots that are retained until they consume the amount of space you've allowed for snapshots (I think the default is 15% of the partition size), after which the oldest snapshots start getting deleted.  The snapshots that Reflect requests are temporary VSS snapshots, i.e. they get deleted after Reflect finishes its backup.  However, the snapshot consumes some space while it exists, and the more write activity that occurs on the partition during a backup, the larger the snapshot has to be in order to preserve the original state of the data at the time the backup began -- yes, the snapshot actually grows during its lifetime rather than being a fixed size at its creation.  This is called "copy-on-write" behavior.  So if you started a backup job and then wrote a ton of data to the partition while the job was running, the size of that temporary snapshot could grow to the point that some or even all of your permanent snapshots that are used for System Restore points have to be deleted in order to keep the total size of your snapshots within the configured quota on the partition.  And if you kept on writing data so that the size of the temporary snapshot on its own exceeded your entire snapshot quota, then Windows would delete the temporary snapshot itself and the Reflect job would fail with a note that the snapshot was deleted before the backup completed.  This is one reason it's a good idea to perform backups during relatively "quiet" periods.

In addition, if you ever restore a Reflect image backup and notice that the System Restore snapshots that would have been there when that backup was created aren't there now that you've restored that backup, that's because part of the VSS snapshot mechanism I described earlier involves notifying applications that a snapshot has been requested (e.g. by Reflect), and applications that have registered to be notified of these snapshot requests are then given an opportunity to use a component called a VSS writer that is allowed to make changes to the contents of the snapshot before Windows tells the requesting application that the snapshot is ready for use. Database applications use this capability to make sure that the data actually written to disk is internally consistent, for example.  VSS writers are also allowed to delete data specifically from a snapshot (while preserving it on disk), and Windows itself has some VSS writers that do this.  System Restore points are not included in VSS snapshots.  The Windows Search service also deletes the search index database because that can grow quite large and is automatically recreated when it's missing.  One way to avoid this outcome is to capture backups from Rescue Media, which does not use VSS because in the Rescue Media environment, the partitions aren't online/active, so VSS isn't necessary -- and consequently, the changes introduced by VSS writers don't occur.

Hopefully one of those accounts for what you're seeing.



By terrypin - 22 January 2020 5:38 PM

Much appreciate that fast and detailed response, thank you, although I confess it's largely above my know how level!

I had checked that these two VSS related services were running
Volume Shadow Copy
Microsoft Software Shadow Copy Provider
Both are set to Automatic.
Reflect is set to do a full backup every Sunday morning. No differential, no incremental., although I may pursue those options at some time.
The last few steps I've taken were:
1. Set up a new entry in Task Scheduler so that an SR would be created at
each startup. using instructions here:
https://www.windowscentral.com/how-create-system-restore-points-automatically-startup-windows-10

2. RPGlobalInterval created in regedit and set to 2 days = 172800 secs
https://techjourney.net/change-the-frequency-or-backup-interval-of-system-restore-in-windows/

3. Enabled Automatic System Restore Points Using Group Policy
https://www.itprotoday.com/windows-10/how-set-automatic-restore-points-windows-10

Will reboot shortly and then thought I'd make a couple of new SR points, wait a day or two, check if they still exist, force a new run of my full backup, and check again.

Is there any other test I can do to rule out Reflect please?



By jphughan - 22 January 2020 6:44 PM

The real test would be to check which System Restore snapshots you have immediately prior to a Reflect job starting, and then seeing what snapshots you have afterward.  If you lost some snapshots during the backup, it's likely because the temporary snapshot that Reflect needed in order to create the backup required space that forced some older snapshots to be deleted in order to keep within your partition's snapshot quota.  The way to minimize the likelihood of this (or the quantity of deletions required) would be to minimize the amount of write activity that occurs on your system while a backup is running, and/or to increase the VSS snapshot quota for the partition(s) in question.  The latter won't change the behavior directly, but it will allow you to preserve more snapshots overall -- so if your concern for example is that you want to be able to keep snapshots going back a particular period of time and right now they're getting deleted sooner than that, then increasing your VSS snapshot quota will mean you'll be able to hang onto more of them.
By terrypin - 24 January 2020 6:04 AM

Thanks for the follow up. See also my latest post here:
https://www.tenforums.com/backup-restore/144782-sytem-restore-points-frequently-disappearing.html#post1823562
By jphughan - 24 January 2020 2:40 PM

Well if you can narrow down the timeframe when the SR points get deleted by checking them frequently, you may be able to find useful information in Event Viewer that might explain the reason for the deletion. And with respect to Sygnus21’s reply over there, just for accuracy’s sake, it wouldn’t be Reflect deleting SR points. It would still be Windows deleting them in order to remain within the VSS snapshot storage quota. The REASON they would be deleted in the scenario I described would be to preserve the new temporary snapshot that Reflect is using to perform a backup, but it’s still Windows doing the work.
By terrypin - 26 January 2020 9:41 AM

So, it's down to a Macrium v Microsoft conflict.

https://www.dropbox.com/s/96kwjd3uzll1sig/SRs-Deleted-2.jpg?raw=1

https://www.dropbox.com/s/3r0haiocngf7ieg/SRs-Deleted-3.jpg?raw=1
By jphughan - 26 January 2020 3:15 PM

That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.
By terrypin - 27 January 2020 10:36 AM

jphughan - 26 January 2020 3:15 PM
That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.

posted 27 January 2020 10:29 AM
terrypin
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)
Group: Awaiting Activation
Posts: 15, Visits: 50
Last active: 27 January 2020 10:27 AM
    
On advice elsewhere I ran this from a command prompt:

vssadmin list shadows


It seems to tell me there are four 'shadow copies', including the 21/1/20 that's no longer shown in the SR dialog shown in my screenshot. The latest entry coincides with this morning's MR image run. In total it seems a modest amount of storage, well below the 12 GB reserved, which I would not expect to give rise to the deletions you describe? That indication of small volumes seesm confirmed by the TreeSize display I've included too.


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

C:\WINDOWS\system32>vssadmin 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: {0164a638-0dc6-484e-a796-08aca6111170}
Contained 1 shadow copies at creation time: 21/01/20 06:17:24
Shadow Copy ID: {270cffa2-c841-404c-b984-1ae55f377b19}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
 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: {48c6716c-32d4-4334-928b-b372055fffdf}
Contained 1 shadow copies at creation time: 23/01/20 09:45:24
Shadow Copy ID: {39e3e10d-b889-4918-911b-cd2c8159480e}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
 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: {1d82cfe8-524e-4ac3-829b-e275c0325c10}
Contained 1 shadow copies at creation time: 23/01/20 16:42:19
Shadow Copy ID: {f452886c-179a-4b52-b3f7-e172ec77eccf}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
 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 05:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
 Original Volume:
(GSmile\\?\Volume{00028375-0000-0000-0000-100000000000}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
 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
 
--------------------

TreeSize implies there's only 1.5 GB consumed by SR.
https://www.dropbox.com/s/gus81khya0k5xyz/SRs-TreeSize26Jan2020-2.jpg?raw=1

BTW, that's strangely only half of that shown in the SR window. Also, it's apparently made up entirely of MS Apps, hardly any of which I use!

P.S. I see that parts of the addresses displayed by that VSS command get poorly interpreted here, but I hope they're still intelligible.

By Nick - 27 January 2020 12:34 PM

terrypin - 27 January 2020 10:36 AM
jphughan - 26 January 2020 3:15 PM
That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.

posted 27 January 2020 10:29 AM
terrypin
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)
Group: Awaiting Activation
Posts: 15, Visits: 50
Last active: 27 January 2020 10:27 AM
    
On advice elsewhere I ran this from a command prompt:

vssadmin list shadows


It seems to tell me there are four 'shadow copies', including the 21/1/20 that's no longer shown in the SR dialog shown in my screenshot. The latest entry coincides with this morning's MR image run. In total it seems a modest amount of storage, well below the 12 GB reserved, which I would not expect to give rise to the deletions you describe? That indication of small volumes seesm confirmed by the TreeSize display I've included too.


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

C:\WINDOWS\system32>vssadmin 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: {0164a638-0dc6-484e-a796-08aca6111170}
Contained 1 shadow copies at creation time: 21/01/20 06:17:24
Shadow Copy ID: {270cffa2-c841-404c-b984-1ae55f377b19}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
 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: {48c6716c-32d4-4334-928b-b372055fffdf}
Contained 1 shadow copies at creation time: 23/01/20 09:45:24
Shadow Copy ID: {39e3e10d-b889-4918-911b-cd2c8159480e}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
 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: {1d82cfe8-524e-4ac3-829b-e275c0325c10}
Contained 1 shadow copies at creation time: 23/01/20 16:42:19
Shadow Copy ID: {f452886c-179a-4b52-b3f7-e172ec77eccf}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
 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 05:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
 Original Volume:
(GSmile\\?\Volume{00028375-0000-0000-0000-100000000000}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
 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
 
--------------------

TreeSize implies there's only 1.5 GB consumed by SR.
https://www.dropbox.com/s/gus81khya0k5xyz/SRs-TreeSize26Jan2020-2.jpg?raw=1

BTW, that's strangely only half of that shown in the SR window. Also, it's apparently made up entirely of MS Apps, hardly any of which I use!

P.S. I see that parts of the addresses displayed by that VSS command get poorly interpreted here, but I hope they're still intelligible.


Thanks for posting.

Macrium Reflect doesn't create 'Persistent' shadow copies, It creates non persistent 'Differential' shadows using VSS Writers that only persist during the backup.  As described by @jphughan, maintenance of the shadow copy storage area is handled entirely by the Windows VSS subsystem.  If the shadow copy diff area grows significantly during a backup then this could cause existing shadows to be purged while the backup is running. This is normal and expected. If you are seeing unexpected purges of older shadows then you could try increasing your shadow storage to handle the temporary diff area created by non persistent shadows or create images during periods of low disk activity. 

You will only see Reflect shadow copies using 'vssadmin list shadows' while a backup is running. The Shadow type is 'Backup', and the attributes shows 'Differential'. Here's an example:

Contents of shadow copy set ID: {b7e70817-a9b0-4bf4-a609-231de97ed27f}
 Contained 1 shadow copies at creation time: 27/01/2020 11:47:54
  Shadow Copy ID: {431e03d5-aa90-4bd4-b36b-b31d7e3207ef}
   Original Volume: (C: )\\?\Volume{7d01874d-3650-45bb-8fce-b96b76cce09a}\
   Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
   Originating Machine: MS-W-0.macrium.local
   Service Machine: MS-W-0.macrium.local
   Provider: 'Microsoft Software Shadow Copy provider 1.0'
   Type: Backup
   Attributes: Differential, Auto recovered
By terrypin - 28 January 2020 8:58 PM

Nick - 27 January 2020 12:34 PM
terrypin - 27 January 2020 10:36 AM
jphughan - 26 January 2020 3:15 PM
That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.

posted 27 January 2020 10:29 AM
terrypin
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)
Group: Awaiting Activation
Posts: 15, Visits: 50
Last active: 27 January 2020 10:27 AM
    
On advice elsewhere I ran this from a command prompt:

vssadmin list shadows


It seems to tell me there are four 'shadow copies', including the 21/1/20 that's no longer shown in the SR dialog shown in my screenshot. The latest entry coincides with this morning's MR image run. In total it seems a modest amount of storage, well below the 12 GB reserved, which I would not expect to give rise to the deletions you describe? That indication of small volumes seesm confirmed by the TreeSize display I've included too.


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

C:\WINDOWS\system32>vssadmin 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: {0164a638-0dc6-484e-a796-08aca6111170}
Contained 1 shadow copies at creation time: 21/01/20 06:17:24
Shadow Copy ID: {270cffa2-c841-404c-b984-1ae55f377b19}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
 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: {48c6716c-32d4-4334-928b-b372055fffdf}
Contained 1 shadow copies at creation time: 23/01/20 09:45:24
Shadow Copy ID: {39e3e10d-b889-4918-911b-cd2c8159480e}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
 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: {1d82cfe8-524e-4ac3-829b-e275c0325c10}
Contained 1 shadow copies at creation time: 23/01/20 16:42:19
Shadow Copy ID: {f452886c-179a-4b52-b3f7-e172ec77eccf}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
 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 05:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
 Original Volume:
(GSmile\\?\Volume{00028375-0000-0000-0000-100000000000}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
 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
 
--------------------

TreeSize implies there's only 1.5 GB consumed by SR.
https://www.dropbox.com/s/gus81khya0k5xyz/SRs-TreeSize26Jan2020-2.jpg?raw=1

BTW, that's strangely only half of that shown in the SR window. Also, it's apparently made up entirely of MS Apps, hardly any of which I use!

P.S. I see that parts of the addresses displayed by that VSS command get poorly interpreted here, but I hope they're still intelligible.


Thanks for posting.

Macrium Reflect doesn't create 'Persistent' shadow copies, It creates non persistent 'Differential' shadows using VSS Writers that only persist during the backup.  As described by @jphughan, maintenance of the shadow copy storage area is handled entirely by the Windows VSS subsystem.  If the shadow copy diff area grows significantly during a backup then this could cause existing shadows to be purged while the backup is running. This is normal and expected. If you are seeing unexpected purges of older shadows then you could try increasing your shadow storage to handle the temporary diff area created by non persistent shadows or create images during periods of low disk activity. 

You will only see Reflect shadow copies using 'vssadmin list shadows' while a backup is running. The Shadow type is 'Backup', and the attributes shows 'Differential'. Here's an example:

Contents of shadow copy set ID: {b7e70817-a9b0-4bf4-a609-231de97ed27f}
 Contained 1 shadow copies at creation time: 27/01/2020 11:47:54
  Shadow Copy ID: {431e03d5-aa90-4bd4-b36b-b31d7e3207ef}
   Original Volume: (C: )\\?\Volume{7d01874d-3650-45bb-8fce-b96b76cce09a}\
   Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
   Originating Machine: MS-W-0.macrium.local
   Service Machine: MS-W-0.macrium.local
   Provider: 'Microsoft Software Shadow Copy provider 1.0'
   Type: Backup
   Attributes: Differential, Auto recovered

Thanks Nick. Much of this topic is outside my know how level but I get the gist.

What are your thoughts re my point that storage usage seems very small?
By Nick - 29 January 2020 11:10 AM

terrypin - 28 January 2020 8:58 PM
Nick - 27 January 2020 12:34 PM
terrypin - 27 January 2020 10:36 AM
jphughan - 26 January 2020 3:15 PM
That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.

posted 27 January 2020 10:29 AM
terrypin
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)
Group: Awaiting Activation
Posts: 15, Visits: 50
Last active: 27 January 2020 10:27 AM
    
On advice elsewhere I ran this from a command prompt:

vssadmin list shadows


It seems to tell me there are four 'shadow copies', including the 21/1/20 that's no longer shown in the SR dialog shown in my screenshot. The latest entry coincides with this morning's MR image run. In total it seems a modest amount of storage, well below the 12 GB reserved, which I would not expect to give rise to the deletions you describe? That indication of small volumes seesm confirmed by the TreeSize display I've included too.


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

C:\WINDOWS\system32>vssadmin 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: {0164a638-0dc6-484e-a796-08aca6111170}
Contained 1 shadow copies at creation time: 21/01/20 06:17:24
Shadow Copy ID: {270cffa2-c841-404c-b984-1ae55f377b19}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
 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: {48c6716c-32d4-4334-928b-b372055fffdf}
Contained 1 shadow copies at creation time: 23/01/20 09:45:24
Shadow Copy ID: {39e3e10d-b889-4918-911b-cd2c8159480e}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
 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: {1d82cfe8-524e-4ac3-829b-e275c0325c10}
Contained 1 shadow copies at creation time: 23/01/20 16:42:19
Shadow Copy ID: {f452886c-179a-4b52-b3f7-e172ec77eccf}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
 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 05:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
 Original Volume:
(GSmile\\?\Volume{00028375-0000-0000-0000-100000000000}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
 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
 
--------------------

TreeSize implies there's only 1.5 GB consumed by SR.
https://www.dropbox.com/s/gus81khya0k5xyz/SRs-TreeSize26Jan2020-2.jpg?raw=1

BTW, that's strangely only half of that shown in the SR window. Also, it's apparently made up entirely of MS Apps, hardly any of which I use!

P.S. I see that parts of the addresses displayed by that VSS command get poorly interpreted here, but I hope they're still intelligible.


Thanks for posting.

Macrium Reflect doesn't create 'Persistent' shadow copies, It creates non persistent 'Differential' shadows using VSS Writers that only persist during the backup.  As described by @jphughan, maintenance of the shadow copy storage area is handled entirely by the Windows VSS subsystem.  If the shadow copy diff area grows significantly during a backup then this could cause existing shadows to be purged while the backup is running. This is normal and expected. If you are seeing unexpected purges of older shadows then you could try increasing your shadow storage to handle the temporary diff area created by non persistent shadows or create images during periods of low disk activity. 

You will only see Reflect shadow copies using 'vssadmin list shadows' while a backup is running. The Shadow type is 'Backup', and the attributes shows 'Differential'. Here's an example:

Contents of shadow copy set ID: {b7e70817-a9b0-4bf4-a609-231de97ed27f}
 Contained 1 shadow copies at creation time: 27/01/2020 11:47:54
  Shadow Copy ID: {431e03d5-aa90-4bd4-b36b-b31d7e3207ef}
   Original Volume: (C: )\\?\Volume{7d01874d-3650-45bb-8fce-b96b76cce09a}\
   Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
   Originating Machine: MS-W-0.macrium.local
   Service Machine: MS-W-0.macrium.local
   Provider: 'Microsoft Software Shadow Copy provider 1.0'
   Type: Backup
   Attributes: Differential, Auto recovered

Thanks Nick. Much of this topic is outside my know how level but I get the gist.

What are your thoughts re my point that storage usage seems very small?

Thanks for getting back.

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.
By terrypin - 7 July 2020 11:28 AM

Nick - 27 January 2020 12:34 PM
terrypin - 27 January 2020 10:36 AM
jphughan - 26 January 2020 3:15 PM
That’s not a conflict. It looks like what I explained above is what’s happening, which is what’s DESIGNED to happen. If the system doesn’t have enough space in the snapshot quota to maintain a new snapshot that grows as needed based on disk write activity, then Windows starts deleting the oldest snapshots as needed to recover space. The only alternative behaviors would be Windows exceeding your storage quota, which defeats the point of a quota, or else deleting the most recent snapshot that Reflect is using in order to preserve the old snapshot AND remain below the quota — but that would cause backups to fail.

If you want to be able to maintain more snapshots, then increase the VSS snapshot storage quota on your C volume. And/or just consider that when you have Reflect backups that you’re making on a regular basis, the need for System Restore is dubious are best. Even among people who DON’T make regular image backups, System Restore is sort of a “nice to have....when it actually works” sort of thing.

posted 27 January 2020 10:29 AM
terrypin
New Member
New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)New Member (21 reputation)
Group: Awaiting Activation
Posts: 15, Visits: 50
Last active: 27 January 2020 10:27 AM
    
On advice elsewhere I ran this from a command prompt:

vssadmin list shadows


It seems to tell me there are four 'shadow copies', including the 21/1/20 that's no longer shown in the SR dialog shown in my screenshot. The latest entry coincides with this morning's MR image run. In total it seems a modest amount of storage, well below the 12 GB reserved, which I would not expect to give rise to the deletions you describe? That indication of small volumes seesm confirmed by the TreeSize display I've included too.


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

C:\WINDOWS\system32>vssadmin 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: {0164a638-0dc6-484e-a796-08aca6111170}
Contained 1 shadow copies at creation time: 21/01/20 06:17:24
Shadow Copy ID: {270cffa2-c841-404c-b984-1ae55f377b19}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
 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: {48c6716c-32d4-4334-928b-b372055fffdf}
Contained 1 shadow copies at creation time: 23/01/20 09:45:24
Shadow Copy ID: {39e3e10d-b889-4918-911b-cd2c8159480e}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
 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: {1d82cfe8-524e-4ac3-829b-e275c0325c10}
Contained 1 shadow copies at creation time: 23/01/20 16:42:19
Shadow Copy ID: {f452886c-179a-4b52-b3f7-e172ec77eccf}
 Original Volume:
(CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
 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 05:38:05
Shadow Copy ID: {1ee712ad-ede6-4741-99fa-c75f24c0feee}
 Original Volume:
(GSmile\\?\Volume{00028375-0000-0000-0000-100000000000}\
 Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
 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
 
--------------------

TreeSize implies there's only 1.5 GB consumed by SR.
https://www.dropbox.com/s/gus81khya0k5xyz/SRs-TreeSize26Jan2020-2.jpg?raw=1

BTW, that's strangely only half of that shown in the SR window. Also, it's apparently made up entirely of MS Apps, hardly any of which I use!

P.S. I see that parts of the addresses displayed by that VSS command get poorly interpreted here, but I hope they're still intelligible.


Thanks for posting.

Macrium Reflect doesn't create 'Persistent' shadow copies, It creates non persistent 'Differential' shadows using VSS Writers that only persist during the backup.  As described by @jphughan, maintenance of the shadow copy storage area is handled entirely by the Windows VSS subsystem.  If the shadow copy diff area grows significantly during a backup then this could cause existing shadows to be purged while the backup is running. This is normal and expected. If you are seeing unexpected purges of older shadows then you could try increasing your shadow storage to handle the temporary diff area created by non persistent shadows or create images during periods of low disk activity. 

You will only see Reflect shadow copies using 'vssadmin list shadows' while a backup is running. The Shadow type is 'Backup', and the attributes shows 'Differential'. Here's an example:

Contents of shadow copy set ID: {b7e70817-a9b0-4bf4-a609-231de97ed27f}
 Contained 1 shadow copies at creation time: 27/01/2020 11:47:54
  Shadow Copy ID: {431e03d5-aa90-4bd4-b36b-b31d7e3207ef}
   Original Volume: (C: )\\?\Volume{7d01874d-3650-45bb-8fce-b96b76cce09a}\
   Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
   Originating Machine: MS-W-0.macrium.local
   Service Machine: MS-W-0.macrium.local
   Provider: 'Microsoft Software Shadow Copy provider 1.0'
   Type: Backup
   Attributes: Differential, Auto recovered

Thanks. But the reason I haven't replied earlier is that frankly I've understood very little of the explanations so far. I'm not a programmer, system administrator or a 'techie' of any sort. Just an experienced end user who would like to benefit from the respective insurances of both Macrium and System Restore Points. 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 image. I simply want to know how to fix that, in plain english terms please!

I find it hard to believe that this issue can be confined to me. Surely there must be some documented detailed steps, or perhaps even a one-click script to resolve it on this Intel Core i7 6700K (4.0GHz), 32 GB Win 10 PC?

Terry



By jphughan - 7 July 2020 2:12 PM

@terrypin I realize you're not a techie, but the underlying issue is a technical one, so understanding what's going on is going to require some technical discussion.  It's not as if there's a "Stop deleting my System Restore points" checkbox somewhere.  But I'll take a run at trying to break this down with as little technical jargon as possible.

System Restore points rely on what are called "VSS snapshots", which are basically point-in-time "versions" of your C partition.  That's how System Restore allows you to go back in time to recover older versions of your system. Windows has a storage quota for these snapshots, i.e. the maximum amount of storage they can consume, and when the total size of your snapshots reaches that limit, Windows automatically purges snapshots as needed (starting with the oldest) in order to retain new snapshots without exceeding the quota.  The snapshots created by System Restore are "persistent" snapshots, i.e. they stick around until they get purged to recover space or by you choosing to delete them.

When you make a Reflect backup, it creates a temporary VSS snapshot.  For technical reasons I won't delve into, this is necessary in order to make it possible to capture a valid image of a live system, but it's not needed beyond the image operation, which is why it's temporary.  If all of your System Restore points are being deleted when Reflect runs, it's probably because that temporary snapshot that Reflect needs in order to perform an image backup is growing so large that it's causing the total size of your shadow copies to reach your storage quota, and therefore Windows is having to delete those older permanent snapshots that support your System Restore points in order to keep that temporary snapshot "alive" for the image backup process to complete.  At the end of the image backup process, the temporary snapshot gets deleted, but obviously the permanent snapshots that were purged don't return.

The only way a snapshot grows is due to write activity on the disk that occurs after it was made -- yes, the snapshot grows based on write activity that occurs AFTER it is created, for other technical reasons I won't delve into.  So if my theory above is correct, the proper fix would be to figure out what's generating so much write activity on your PC while Reflect is trying to make an image backup and stopping that, or else rescheduling your Reflect backup for a time when that write activity won't be occurring.  That way the temporary snapshot won't grow, and therefore Windows will be able to keep the permanent snapshots that support your System Restore points without risking exceeding your storage quota.

If that's too difficult, then one workaround you can try would be to simply increase the storage quota for your snapshots.  To do that, open an elevated Command Prompt (right-click Command Prompt, select Run as Administrator), and first enter this:

vssadmin list shadowstroage /for=C:


See what the "Maximum Shadow Copy Storage space" line says.  Then run this command to increase it to some larger value.  In the example below, I saw that my current storage space was 5% of the volume size, so I'm setting it to 10%:

vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=10%


But just understand that that's a bit like having a roof leak and simply putting a larger bucket on the floor under it rather than fixing the leak.
By terrypin - 7 July 2020 7:47 PM

@jphughan

Many thanks for that, I really appreciate your patience. I'm going to study your post carefully tomorrow. Just finished a Zoom-based virtual tasting of four Spanish wines (but with real bottles) with our local wine appreciation society, so don't think I would do it justice right now!
Terry
By terrypin - 8 July 2020 9:45 AM

jphughan - 7 July 2020 2:12 PM
@terrypin I realize you're not a techie, but the underlying issue is a technical one, so understanding what's going on is going to require some technical discussion.  It's not as if there's a "Stop deleting my System Restore points" checkbox somewhere.  But I'll take a run at trying to break this down with as little technical jargon as possible.

System Restore points rely on what are called "VSS snapshots", which are basically point-in-time "versions" of your C partition.  That's how System Restore allows you to go back in time to recover older versions of your system. Windows has a storage quota for these snapshots, i.e. the maximum amount of storage they can consume, and when the total size of your snapshots reaches that limit, Windows automatically purges snapshots as needed (starting with the oldest) in order to retain new snapshots without exceeding the quota.  The snapshots created by System Restore are "persistent" snapshots, i.e. they stick around until they get purged to recover space or by you choosing to delete them.

When you make a Reflect backup, it creates a temporary VSS snapshot.  For technical reasons I won't delve into, this is necessary in order to make it possible to capture a valid image of a live system, but it's not needed beyond the image operation, which is why it's temporary.  If all of your System Restore points are being deleted when Reflect runs, it's probably because that temporary snapshot that Reflect needs in order to perform an image backup is growing so large that it's causing the total size of your shadow copies to reach your storage quota, and therefore Windows is having to delete those older permanent snapshots that support your System Restore points in order to keep that temporary snapshot "alive" for the image backup process to complete.  At the end of the image backup process, the temporary snapshot gets deleted, but obviously the permanent snapshots that were purged don't return.

The only way a snapshot grows is due to write activity on the disk that occurs after it was made -- yes, the snapshot grows based on write activity that occurs AFTER it is created, for other technical reasons I won't delve into.  So if my theory above is correct, the proper fix would be to figure out what's generating so much write activity on your PC while Reflect is trying to make an image backup and stopping that, or else rescheduling your Reflect backup for a time when that write activity won't be occurring.  That way the temporary snapshot won't grow, and therefore Windows will be able to keep the permanent snapshots that support your System Restore points without risking exceeding your storage quota.

If that's too difficult, then one workaround you can try would be to simply increase the storage quota for your snapshots.  To do that, open an elevated Command Prompt (right-click Command Prompt, select Run as Administrator), and first enter this:

vssadmin list shadowstroage /for=C:


See what the "Maximum Shadow Copy Storage space" line says.  Then run this command to increase it to some larger value.  In the example below, I saw that my current storage space was 5% of the volume size, so I'm setting it to 10%:

vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=10%


But just understand that that's a bit like having a roof leak and simply putting a larger bucket on the floor under it rather than fixing the leak.

Here's what the basic command reports:
--------------------
C:\WINDOWS\system32>vssadmin 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: (CSmile\\?\Volume{0aa994fb-aeb9-4b19-863d-c873ece9fcb0}\
 Shadow Copy Storage volume: (CSmile\\?\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%)
--------------------
Surely, that doesn't indicate the problem is caused by 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:

By jphughan - 8 July 2020 12:52 PM

The 416 MB is the storage occupied by your existing persistent snapshots. But if you were to start an image backup and write more than 11.5 GB worth of changes (max space minus the used space) during the backup, then Windows would have to delete the existing persistent snapshots to allow that temporary snapshot to remain. And if you wrote more than 11.9 GB worth of changes during the backup, then Windows would have to drop even the temporary snapshot, which would cause the backup to fail. Is that what’s happening? I don’t know, but I would stop short of using the word “surely” here. You can still try raising your snapshot storage quota just to see if it makes a difference. You can always change it back to 5%, after all.
By terrypin - 8 July 2020 2:11 PM

Thanks, I’ll try that next. I’d be surprised if I’m
changing more than 11 GB every week but I’ll try to test that methodically. And that could also be consistent with the fact that my SRs did NOT get deleted when I tried a MANUAL backup this morning!

Were there any clues in my configuration?
By jphughan - 8 July 2020 3:05 PM

No clues on the configuration, but I wouldn’t have expected any there. And to be clear, the 11GB worth of changes would need to be written while the backup is running, since that’s the only time Windows needs to keep the temporary snapshot for Reflect alive, not between backups. If that sounds even less plausible, then I’m not sure where to look next here. You haven’t RESTORED any backups, have you? Reflect backups captured from within Windows do not include System Restore points because Windows itself doesn’t include them in the snapshots it creates, so if you restore a Reflect backup, then it will NOT have the System Restore points that existed at the time that backup was captured.
By terrypin - 14 July 2020 3:10 PM

Still no idea why, but happy to report that after changing only the start time, from 05:00 to 06:00, all my SR points were preserved after last Sunday's full backup!

Of course, if I was being really thorough, I'd revert to 05:00 and check again next Sunday, to eliminate the possibility that it was some other (unknown) cause that has somehow fixed itself. Curiosity tempts me - but I'll pass. Wink

Thanks a lot for your help and patience.

Terry
By BobUlius - 28 December 2020 1:33 AM

I have this issue. Found this by first finding the mention that Acronis could be responsible, then coming over here to search.

Every few days, maybe less but I think at ;least a few days survive, my MANUAL restore points are gone.
Windows generated RP's are there.

I suspected the task for DiskCleanup which runs cleanmgr in "autoclean" mode,, but unclear if that would deleted restore points. All I find can neither confirm nor deny. it removes restore points. In fact, to manually run Cleanmgr and remove Restore Points requires digging down quite a bit to ge to that possibility.

The the System Restore Task which "appears" to only generate a new restore point, but not delete any before it.

I run Macrium Twice every night. During those hours I am doing nothing sdo the copy should not grrow. I have 650GB free disc space and maybe 40 GB free System Restore space.

Every night Incremental to two different drive, hence running twice.
Sundays Differential
First of the month Full

So my first reads of the above explanations say Macrium should not be the culprit. But with my description of my issue above, could it be?

By BobUlius - 28 December 2020 2:42 AM

I continue to research this a lot!

Some say VSS should be set to automatics to fix this. Mine is set to manual. And Macrium works fine that way. Could changing that to Automatic fix this perhaps?
By Beardy - 28 December 2020 2:50 AM

@BobUlius It doesn't look difficult to investigate, at least by elimination.
Is your cleanup job running with elevated privileges?
cleanmgr.exe /autoclean can be run from an elevated command prompt & the effect (if any) observed immediately afterward.

cleanmgr.exe /autoclean can also be run as a normal user (not elevated) in which case it skips cleaning up "system files", so reducing its rights might help if it turns out to be the culprit.

Increasing the shadow storage as discussed earlier in this thread costs nothing either, so if cleanmgr isn't the culprit, try it & see if it helps.
By BobUlius - 28 December 2020 3:38 AM

Beardy - 28 December 2020 2:50 AM
@BobUlius It doesn't look difficult to investigate, at least by elimination.
Is your cleanup job running with elevated privileges?
cleanmgr.exe /autoclean can be run from an elevated command prompt & the effect (if any) observed immediately afterward.

cleanmgr.exe /autoclean can also be run as a normal user (not elevated) in which case it skips cleaning up "system files", so reducing its rights might help if it turns out to be the culprit.

Increasing the shadow storage as discussed earlier in this thread costs nothing either, so if cleanmgr isn't the culprit, try it & see if it helps.


Great idea on privileges. Shall try. Just created a restore point and want to see if it remains there in the morning.

Hard to imagine 45GB space is not enough to allocate to Restore. But sure, can try that as well.

Thanks.


By jphughan - 28 December 2020 5:06 AM

VSS is supposed to be set to Manual. Not sure what’s going on with your snapshots though.
By BobUlius - 28 December 2020 6:16 PM

Well, Macrium ran twice last night and Restore Points were not deleted, so not a likely culprit. Same with DiskCleanup. Also ran and did not delete the Restore Points.

Still searching for what deletes my manual points.