Maximum size of shadow copies / restore points

  • Thread starter Thread starter DevilsPGD
  • Start date Start date
D

DevilsPGD

I've noticed what appears to be an interesting quirk with shadow copies.
It looks like Vista bases shadow copies on a "maximum space" rather then
on a guaranteed minimum available space basis.

While reasonable on the surface, there is one problem with this
implementation. If you create a file larger then your shadow copy's
maximum size, delete it, then recreate the file (potentially a few
times), the effective result is that all shadow copies are lost even
though there may be enough space for the cumulative changes to be stored
on the volume in question.

Is my interpretation of this situation correct? If so, is there any way
to change how Vista acts? I would be quite happy for Vista to simply
guarantee me a minimum of 10GB of available space on each logical
partition, deleting shadow copies as needed when approaching the limit,
rather them limiting shadow copies to a fixed total amount of space.

I have run into this situation in the real world when working with 4.7GB
file sets which were compressed and split into smaller parts for
transmission. Despite having a 400GB drive, with over 100GB free at all
times, I ended up with no shadow copies / restore points when I ended up
needing to recover an unrelated file (luckily my file servers all
generate shadow copies too, so I was able to recover the file)
 
Windows Vista reserves 15% of your hard drive(s) for shadow copies, by
default.

You can change this with the "vssadmin" command. If you have problems with
the syntax, yell for help.
 
In message <[email protected]> "Robert
Blacher said:
Windows Vista reserves 15% of your hard drive(s) for shadow copies, by
default.

You can change this with the "vssadmin" command. If you have problems with
the syntax, yell for help.

Unfortunately the solution isn't that simple, it needs to guarantee a
fixed amount of free space, rather then limit to a maximum size,
otherwise as actual disk allocation changes we'll run out of disk space.

I guess I'm more complaining about a poor implementation, with the side
effect of hoping there was a fix by way of a reconfiguration, but I
don't see anything in vssadmin.
 
Back
Top