System Restore Points Keep Getting Deleted

[crashnet]

I have system protection for system settings and files set to 2gb on c: for c:

there are two triggers in the scheduled tasks, and both work (a restore point gets created when the conditions are met)

• when i install updates or uninstall a program
• when i start the machine

Also, when i manually run the task or the command line used by the tasks, a restore point is created.

BUT the restore points eventually get deleted. I had two of them earlier today, using less than 400mb, now I have none. they don't get deleted after a restart. i haven't been able to pinpoint when they get deleted, but they don't last more than a day or two. and they never get anywhere near the allowed 2gb, though they do get past the allocated 300mb

VSS service is set to manual start, which is the default.

system protection is ONLY on for drive C:. I tried to disable it for drive C:, restart the machine, then re-enable it. no go.

i ran a SFC, no errors.

I ran MSE, MBAM, Temp Folder Cleaner and Sophos anti-rootkit, nothing found.

I ran a registry clean and compact (eusing), no difference.

my system was upgrade from Vista, where system restore worked fine.

i don't know what else to do. I have a daily backups, but system restore is a lot more convenient. I would like to get it to run.

thank you in advance for any input

 

[Brink]

Hello Crashnet,

See if increasing the max disk space storage for restore points to say around 10 GB instead will allow them to continue to be stored.

http://www.sevenforums.com/tutorials/335-system-protection-change-disk-space-usage.html

Hope this helps,
Shawn

 

[crashnet]

growing the storage to 10gb didnt work. the restore point I had available yesterday got deleted. the one created a 6am on schedule is the only one available as of 10:30am today.

 

[richc46]

I am sorry that you are having a problem and the solution provided by Brink has not worked.

I have seen this problem, before, from other members of this forum. One possible cause is that you are are scheduling a automatic defrag, which includes the partition where the restore points are activated. If this is the case, you will have to save your restore points to another partition. You can check on the task scheduler to verify the schedule of defrag. Sometimes 3rd party software, also schedules a defrag, such as and A/V.

I have included information on this problem as provided by MS


Shadow copies may be lost when you defragment a volume

Here is another information bulletin from MS, that may provide you with other information that may help you to solve your problem
http://support.microsoft.com/kb/301224

 

[crashnet]

I have been getting Event ID 33 via Volsnap: The oldest shadow copy of volume C: was deleted to keep disk space usage for shadow copies of volume C: below the user defined limit.

But there is plenty of space

C:\Users\user>vssadmin list shadowstorage
vssadmin 1.1

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{efbde587-d98c-11dc-a5ff-806e6f6e6963}\
   Shadow Copy Storage volume: (C:)\\?\Volume{efbde587-d98c-11dc-a5ff-806e6f6e69
63}\
   Used Shadow Copy Storage space: 7.306 GB (16%)
   Allocated Shadow Copy Storage space: 7.626 GB (16%)
   Maximum Shadow Copy Storage space: 9.001 GB (20%)

7.3gbs used and I have NO restore points available right now...

The cluster size on C: is 4k

And I have Diskeeper running.

The only part in the whole thing that doesnt make sense is in KB 312067

If the file system's cluster size is 16 KB or larger, the provider can recognize disk defragmentation I/O and handle it correctly. Microsoft recommends that you use a 16-KB or larger cluster allocation unit size when you format the volume if you plan to defragment volumes that are used for shadow copies of shared folders.

I am NOT creating shadow copies of shared folders. What would the solution possibly be in my case, besides changing cluster size to 16kb (which would be a pain)?

I thought of excluding from defragmentation the area with the restore points are stored, but I am not sure this would make any difference because the purported cause of the problem is

If the file system's cluster size is smaller than 16 KB, the System Shadow Copy provider cannot easily determine that disk defragmentation I/O is different from typical write I/O, and performs a copy-on-write operation. This might cause the Shadow Copy storage area to grow very quickly.

There has got to be a simpler solution to this problem than changing cluster size... this seems to be VSS problem, not a diskeeper problem. it occurs with other defragmenters too:

http://forums.techguy.org/windows-vista/622999-system-restore-deleting-restore-points.html

 

[crashnet]

Problem solved!

Diskeeper has a (VSS) Compatible Mode defrag which was not turned on.

thanks Richard and everyone else

 

[richc46]

Thanks for telling us. We are glad that we could help.


Come back any time to share your expertise or to utilize our knowldege.

Take care.