VSSADMIN

[Willem Overbeeke]

I'm running VISTA Ultimate. Apart from my system disk I have two identical
USB drives attached to my system (G: and H. For both of them shadow copying
is disabled in the backup and restore center (as they are the destination of
my system and file backups, thus do in no need of roll back themselves).
Looking at them with VSSAdmin List, however, G: does have a shadowstorage
association, H: has not. Consequence: free space on H: is much larger than on
G:

Question 1: why the difference? Is there a VISTA program that effectively
gets rid of the shadow storage association?

I then tried to delete the shadowstorage association for G: using VSSADMIN
Delete (as per the MS technet article. However, this command option seems not
to exist in VISTA.

Question 2: Correct ? Why not ?

I then tried to at least resize it to a low value using VSSADMIN again. This
works, and space is effectively released. However, it seems the system simply
ignores my maximum size and in normal operation expands shadowstorage to 30%
of total disk space again.

Question 3: Correct ? If so, what then is the purpose of the Resize option
in the first place ?

Any enlightenment would be very welcome.

 

[JerryM]

Type an example of Resize,

There may be an error.

Jerry

 

[Willem Overbeeke]

Dear Jerry,

The resize DID function OK, it also shows up as the "maximum size" on a
subsequent VSSADMIN list, only it is ignored by VISTA. The list actually
shows an allocated and maximum shadow copy storage space of 300MB, but the
"used shadow storage space simply grows and grows, up to the famous 30%.

My command (executed as administrator, and confirmed by the program) was:
vssadmin resize shadowstorage /for=G: /on=G: /maxsize=300M

Regards

 

[JerryM]

Also,
Yes, windows has an option to shut off the Paging file on any partition.

Right click Computer and select Properties,
Select Advanced system settings and under Performance click settings,
Click Advanced again,
Click change,
Highlite the drive and click no Paging file, then Set.

Type an example of Resize,

There may be an error.

Jerry

<Snip>

 

[JerryM]

Hi, Willem,

Try changing the last entry to /Maxsize=2GB
This is the minimum size.

Jerry

 

[Willem Overbeeke]

Dear Jerry,

First of all, thank you for your very prompt replies. Could I pester you (or
anybody else for that matter) some more?

I did look at the paging file for G: This is and was switched off already.
By the way, I fail to see the link between paging file and shadow storage.

I now put the maxsize of G:'s shadow storage to 2G. This did reduce the
maimum and allowed space accordingly, as well as trimming the used space to
below the maximum. I'll await further developments during normal operation.

This, by the way, leaves me with my two other questions:
1. Why doesn't VSSADMIN DELETE exist in VISTA?
2. What can have been the reason that on two identical disks (G: and H,
connected in identical ways on USB, one was created with a shadow storage
association and the other was not? Is there a way of initially creating a
partition without a shadow storage association?

I would be very grateful for some more fruits of your superior wisdom

 

[JerryM]

Hi, Willem,

I think Shadow storage is just another name used for Restore points.
By reducing your G: drive to 2GB, you still have about 7 days of restore
points.
Unfortunately Shadowstorage is part of the operating system and can't be
deleted,
So that is the reason for it using more space than your H: drive.

The paging file is used as an overflow from your active memory.
You should let the system control the size of G: paging file in case of
overflow.
It shrinks and expands as needed.
By turning off paging files on other drives, you save a lot of reserved
space,
Since System restore only restores system files, not extra programs you
installed.

Vista uses approximately 3.5 GB of disk space so there is less free space to
use for extra programs.

I hope this answers some of your questions,
Jerry

Dear Jerry,

First of all, thank you for your very prompt replies. Could I pester you
(or
anybody else for that matter) some more?

I did look at the paging file for G: This is and was switched off already.
By the way, I fail to see the link between paging file and shadow storage.

I now put the maxsize of G:'s shadow storage to 2G. This did reduce the
maimum and allowed space accordingly, as well as trimming the used space
to
below the maximum. I'll await further developments during normal
operation.

This, by the way, leaves me with my two other questions:
1. Why doesn't VSSADMIN DELETE exist in VISTA?
2. What can have been the reason that on two identical disks (G: and H,
connected in identical ways on USB, one was created with a shadow storage
association and the other was not? Is there a way of initially creating a
partition without a shadow storage association?

I would be very grateful for some more fruits of your superior wisdom

<Snip>

 

[Willem Overbeeke]

Hi Jerry,

Thanks for your response. I DO understand the difference between
shadowstorage and the paging file. That is exactly why I did not understand
your reference to the latter in this context.

In fact my C: disk is the only one with a paging file, as this is the boot
drive. Apart from that I have D: (which is a partition on C and two USB
drives G: and H: (identical size: 250 GB each, used for backup purposes and
alternatively stored in a burglar/fire resistant safe). They were set up in
exactly the same way. Nevertheless G: has shadowstorage configured, H: has
not. So, obviously, shadowstorage is not a necessary condition for a VISTA
compliant disk. But, as VSSADMIN delete shadowstorage does not seem to work
on VISTA, this is the background of my second question: what can be the
reason of this difference. If I knew that, I could perhaps reformat or
re-install G: in the same way as H:.

Any ideas?

 

[JerryM]

Hi, Willem,

I got off on the wrong solutions to your drives.
I thought the Operating system on G: drive was your boot drive.

Using Disk management your can delete the drives hooked up to your USB ports
creating unallocated partitions, then recreate new partitions and formatting
them using NTFS.

Other than that, I don't know what else I can do to help.

Jerry

 

[Willem Overbeeke]

Hi, Jerry,

I had exactly the same idea when lying on my bed at the moment that you,
given the time difference, were posting your reply. I suppose some kind of
psi phenomenon?

Be this as it may, I did recreate both partitions, and they then both came
up without shadowstorage allocations. However, on performing my first backup
onto the disks, the shadowstorage was recreated, and again, since then,
expands freely, though the "allocated size is 300M (I suppose a system
default). I have now set the maxsize to 2G for each disk and will monitor if
that is ignored as well in due course. As a work-around I have created a
small .bat command file, which resets the maxsize to 2G, on which occasion
the effective use is trimmed to 0).

But it does seem that the restore point settings (which are "off" for both
disks) have no impact on shadowstorage.

This also obviates my question about the vssadmin delete option. Even if
such were possible, VISTA simply would recreate the space on the first
"trigger".

I suppose this is as far as we can get on the topic, MS itself not reacting
to these kinds of issue anyway. So please feel free to refrain from further
efforts in the matter, unless you want to.

For the sake of completeness I plan to update you on the result of my 2G
limit. Your expert input was highly appreciated.

Best regards,

 

[JerryM]

Thanks for your understanding, Willem,

If I can think of anything else, I'll let you know,
and I'll keep watching if you come up with a fix.

Good Luck,
Jerry

Hi, Jerry,

I had exactly the same idea when lying on my bed at the moment that you,
given the time difference, were posting your reply. I suppose some kind of
psi phenomenon?

Be this as it may, I did recreate both partitions, and they then both came
up without shadowstorage allocations. However, on performing my first
backup
onto the disks, the shadowstorage was recreated, and again, since then,
expands freely, though the "allocated size is 300M (I suppose a system
default). I have now set the maxsize to 2G for each disk and will monitor
if
that is ignored as well in due course. As a work-around I have created a
small .bat command file, which resets the maxsize to 2G, on which occasion
the effective use is trimmed to 0).

But it does seem that the restore point settings (which are "off" for both
disks) have no impact on shadowstorage.

This also obviates my question about the vssadmin delete option. Even if
such were possible, VISTA simply would recreate the space on the first
"trigger".

I suppose this is as far as we can get on the topic, MS itself not
reacting
to these kinds of issue anyway. So please feel free to refrain from
further
efforts in the matter, unless you want to.

For the sake of completeness I plan to update you on the result of my 2G
limit. Your expert input was highly appreciated.

Best regards,

<Snip>

 

[Willem Overbeeke]

Dear Jerry,

Final update and, I suggest, closure of this thread, unless "Microsoft VISTA
updating" want to pick it up:
This is the summary:

For VISTA:

A VSSADMIN resize shadowstorage DOES reset the "allocated", and the
"maximum" size, deleting shadow copies as necessary, but it does NOT fix the
maximum size permanently. As and when the VSS service needs more space, it
will take it, up to the famous 30%.

VSSADMIN delete shadowstorage does not exist

There is NO WAY to "switch off" shadowstorage for a volume permanently
either. You may create a partition without shadow storage, but during normal
system operation a shadow storage file is created and expanded automatically.

Not creating or switching off "Restore Points" for a volume under Backup and
Restore Center Security Settings does not affect the shadow storage
allocation on that volume, nor does it remove such allocation.

I feel this is NOT according to the design objectives, nor does it reflect
an optimal allocation of space to disk devices that are used solely for
backup storage (and not for operational files), and it clearly conflicts with
documented behaviour.

For the time being I'll keep on using my "temporary fix" consisting of a
daily batch procedure to clean-out the shadow storage on G: and H:.

It has been a pleasure having your support in this matter. Best regards,