Barkley Bees
2008-12-17 15:45:59 UTC
I have deployed two identical servers (Storage Server 2003 R2 SP2 x64 - Dell
NF500 + MD3000) with DFS Namespaces and Replication and one shared folder on
the D: volume. This folder (Users) replicates between the two servers.
I have also configured Volume shadow copies on the D: volume of each server
and assigned 3.8TB for the shadow data (total volume is 10.9TB). I have
decided to keep the default schedule of 7am and 12pm for now.
Anyhow, for the first week or so it was taking snaps with no problem. Then
the other day I had about 10 pilot users copy their user folder data to the
new server (total ~12GB). All seemed well with replication working correctly
between the servers but then today I noticed that the volume snapshots are
disappearing which is quite dismaying to say the least. For the last two
days I am seeing the below in the event log:
--------------------------------------------------------------------------------------------------------------------
Event Type: Error
Event Source: VolSnap
Event Category: None
Event ID: 25
Description:
The shadow copies of volume D: were deleted because the shadow copy storage
could not grow in time. Consider reducing the IO load on the system or
choose a shadow copy storage volume that is not being shadow copied.
--------------------------------------------------------------------------------------------------------------------
I understand that under high IO load (as the error message states) that this
has been known to happen but this is with only 10 test users. We have
another file server (2TB of data) with VSS enabled and accessed by ~500-750
users that has never experienced this issue. It, like the new server, is
saving the volume snapshots to the same volume as the data.
I'm unsure as to what may be the actual cause here. Is it incorrect for me
to have VSS enabled on both servers that are replicating to each other (I
wouldn't think is related). Appreciate any advice or feedback from folks who
may have experience this or similar.
Note: I verified that disk write cache is not disabled.
http://support.microsoft.com/kb/826936 (several other similar kb's on the
matter but no clear resolution yet)
NF500 + MD3000) with DFS Namespaces and Replication and one shared folder on
the D: volume. This folder (Users) replicates between the two servers.
I have also configured Volume shadow copies on the D: volume of each server
and assigned 3.8TB for the shadow data (total volume is 10.9TB). I have
decided to keep the default schedule of 7am and 12pm for now.
Anyhow, for the first week or so it was taking snaps with no problem. Then
the other day I had about 10 pilot users copy their user folder data to the
new server (total ~12GB). All seemed well with replication working correctly
between the servers but then today I noticed that the volume snapshots are
disappearing which is quite dismaying to say the least. For the last two
days I am seeing the below in the event log:
--------------------------------------------------------------------------------------------------------------------
Event Type: Error
Event Source: VolSnap
Event Category: None
Event ID: 25
Description:
The shadow copies of volume D: were deleted because the shadow copy storage
could not grow in time. Consider reducing the IO load on the system or
choose a shadow copy storage volume that is not being shadow copied.
--------------------------------------------------------------------------------------------------------------------
I understand that under high IO load (as the error message states) that this
has been known to happen but this is with only 10 test users. We have
another file server (2TB of data) with VSS enabled and accessed by ~500-750
users that has never experienced this issue. It, like the new server, is
saving the volume snapshots to the same volume as the data.
I'm unsure as to what may be the actual cause here. Is it incorrect for me
to have VSS enabled on both servers that are replicating to each other (I
wouldn't think is related). Appreciate any advice or feedback from folks who
may have experience this or similar.
Note: I verified that disk write cache is not disabled.
http://support.microsoft.com/kb/826936 (several other similar kb's on the
matter but no clear resolution yet)