If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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) |
Ads |
#2
|
|||
|
|||
Running Macrium destroys System Restore points
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. |
#3
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#4
|
|||
|
|||
Running Macrium destroys System Restore points
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..." |
#5
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#6
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#7
|
|||
|
|||
Running Macrium destroys System Restore points
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. |
#8
|
|||
|
|||
Running Macrium destroys System Restore points
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. |
#9
|
|||
|
|||
Running Macrium destroys System Restore points
???? 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| | \ _ / ( ) |
#10
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#11
|
|||
|
|||
Running Macrium destroys System Restore points
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. |
#12
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#13
|
|||
|
|||
Running Macrium destroys System Restore points
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. |
#14
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
#15
|
|||
|
|||
Running Macrium destroys System Restore points
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 |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|