I have a Windows Small Business Server 2008 machine being backed up using the Windows Server Backup utility.  The backups are being made to two external USB attached 1TB drives.  Each drive is rotated out weekly, meaning that one drive is attached one week, then the other drive is swapped in the following week, ad infinitum for the best part of a year.  Two backups were being made each day to the attached drive, one at 12pm and one at 9pm.

About two weeks ago it appears that one of the two drives reached capacity and began shedding the oldest backups, as confirmed by the VOLSNAP Event ID: 33 entries in the System Event log.  On the second day, however, ALL shadow copies on the attached backup driver (volume) were deleted, as confirmed by a single VOLSNAP Event ID: 25.  (See below for both Event ID message contents.)  Unfortuneately, neither events were noted until the drive was swapped out with the other drive and some how the problem was propagated to the second drive, resulting in the deletion of all shadow copies on the second drive, too. 

The end result... BOTH drives lost ALL previous backups leaving only the most recent full backup and no clue as to why it happened or how to prevent it from happening again.  Virtually no older backup file versions could be recovered.

I was under the impression that, by design, the WSB utility would only start deleting the oldest backups (on a full drive) in order to make room for the newer backups.  Granted, had I been keeping attention, I would have actually swapped out the full drives before the actually got full, so that NO data was deleted.

If I'm to continue using the Windows Server Backup utility, I need to know what happened and how to absolutely prevent it from happening again.  I never expected to loose BOTH backups at the same time, and due to budget restraints, two rotating backup drives seemed a logical solution.

Here is text from the two VOLSNAP Event ID messages found in the System Log:

Event ID: 25
Source:  volsnap
Level: Error
Description:  The shadow copies of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} 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.

Event ID: 33
Source: volsnap
Level: Information
Description: The oldest shadow copy of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} was deleted to keep disk space usage for shadow copies of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} below the user defined limit.


NOTE:  Though I'm not sure if this has any bearing on the situation, the server is configured to make two snapshots a day of two volumes on the server, however, when I looked at the Shadow Copy settings I couldn't quite be sure if the VSS wasn't somehow also making snapshots on the two external drives, even though I haven't specified VSS to do so.  None show up on the two replacement drives I'm now using, so I'd say not.


Information on how to prevent this from happening again would greatly be appreciated.  (I'll be making sure no backup drive gets even close to being full from now on, that's for sure!)


Thanks,



Joseph.

• Changed type Sushil.Baid [MSFT] Friday, July 02, 2010 12:42 PM old thread

Hello Joseph,
    The EventId 25 from volsnap deleting all the snapshots is not an expected behaviour. I need to follow up with some other teams to find out
    why such an event happened. I have not seen this issue earlier.

    The windows backup explicitly reclaims space for the current backup by deleting older snapshots OR volsnap will automatically delete older
    versions in case of Copy On Write (COW) which is exactly what happened with the EventId: 33 and this is an expected behaviour.

    Can you please share with us some informations:

    1. What is the free/used space of the source volumes?
    2. What is the free/used space of the target volumes?
    3. The VSS shadow copy space on the target volulme. Use the following command from an elevated window. Assuming D: to be the target volume.
        vssadmin list shadowstorage /for=D:

Thanks,

Bikash Agrawala [MSFT]

--------------------------------------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights

• Edited by Bikash AgrawalaMicrosoft employee Wednesday, February 17, 2010 5:59 AM correcting a text

Hello Joseph,
  Can you please share with us the above requested information. Also can you please share if some other application is also acessing the target volume?

Thanks,

Bikash Agrawala [MSFT]

--------------------------------------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights

Hello Joseph,
   can you please share with the informations as requested above. 

  Also can you please zip the folder %windir%\logs\WindowsBackup and send it to bikasha-nospam@microsoft.com (Use the highlighted part only) for analyzing the problem. Please keep the subject of the email same as this thread for easy tracking.

Thanks,

Bikash Agrawala [MSFT]

--------------------------------------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights

Hello Bikash,

The two source volumes that are being backed up are the typical Boot Volume (C:) and our Data Volume (G:). 

The Boot Volume free and used space is approximately 65GB and 154GB, respectively.
The Data Volume free and used space is approximately 183GB and 464GB, repectively.

NOTE:  Boot Volume is configured using a hardware RAID 1 configuration.  The Data Volume is configured using a hardware RAID 5 configuration.


The two target drives are 931GB drives each and contained backups for both the Boot and Data Volumes.  (They were swapped out each week, alternating one for the other drives for alternating weeks.)  The last I had checked they had just over 700GB of backed up data, covering about 1 year of backups.  I was expecting to swap them out for replacement drives BEFORE they became full and started deleting older backups. 

Since the two target drives were used ONLY with the Windows Server Backup utility, and configured by the WSB utility, no other applications or services should have been using the drives.  The WSB utility had removed drive letter assignments in the very beginning for these two target drives when they were added to the WSB utility's list of target disks.


The VSSADMIN results for one of the two drives is:

C:\Windows\system32>vssadmin list shadowstorage /for=v:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Shadow Copy Storage association
   For volume: (V:)\\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e}\
   Shadow Copy Storage volume: (V:)\\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef57
2e}\
   Used Shadow Copy Storage space: 42.928 GB
   Allocated Shadow Copy Storage space: 43.011 GB
   Maximum Shadow Copy Storage space: UNBOUNDED


NOTE:  I'm protecting one of the two original backup drives.  The one that I used to run the above VSSADMIN command on has actually been attached (since the problem occurred) to Windows XP machine while I tried to take a closer look at what went wrong.  I don't know if that will have an effect on the above VSSADMIN results.

I'll send the requested backup log to the address provided.

Thank you, Bikash.  I look forward to finding out what happened, but more importantly, I look forward to finding out how to prevent it from happening again.


Joseph Arthur Caouette III

Bikash,

Correction:

The following sentence...

The Data Volume free and used space is approximately 183GB and 464GB, repectively.

should read...

The Data Volume free and used space is approximately 183GB and 281GB, repectively.



Again, thanks,


Joseph Arthur Caouette III

I am following up offline with the Joseph and the volsnap team. Since this is a difficult to repro it locally, this analysis may take some time.
I will update the thread once I have some useful information to share.

Hi all,

I have the same problem on a 2 nodes cluster (windows 2003 enterprise R2) that host the file resources. About 20 times since the 24 february 2010, I have the event 25 and I loose the "volume shadow copy history" So I m very interesting to find a solution.

Thanks

Jay

 

I have the same setup as Joseph C, and I've just encountered the same problem.

I have SBS 2008 being backed up to one of two USB drives (931GB each), which are swapped weekly; a backup occurs every day at 2300. When last night's backup ran I got a volsnap event ID 25, and all previous backups were deleted from the drive. Like Joseph, I can see that the oldest backups had previously been shed (by seeing event ID 33 over the past couple of weeks). Unlike Joseph, I managed to catch this before swapping the backup drives, so at least I still have half of my backups intact (and I won't be connecting the full drive now).

I am backing up two drives (system & data) the free/used space for which are 173GB/124GB and 211GB/86GB respectively.

I realise that this thread has been untouched for some time, but has anyone come across a solution to this problem yet?

 

Thanks,

Ben

Hi Bikash

same here, in another constellation:

System: Windows 2003 Server R2, SP2, Standard Edition. ( 4GB of RAM, 2 x 1TB SATA RAID1 with a well working SAS-direct attached Tape Library)
C:\ act as the system drive, 80GB, 87% free.
D:\ act as as Backup Drive, 851GB, 38% free.

Backup Programs from other servers are delivering via Network shares their Backups every night. After that has done, the "HP Data Protector Express" (Version 4.00-sp1 Build 43064) make a daily Fullbackup on the Tape Library, LTO4.
The Backup is about 500GB daily, the tape every day have still more than 400GB free space. (800GB space on a Tape)

Last Week, Daily Full Backup Jobs in HP DataProtector Express ended two times with "error 16" and "Failure, Data not found".
( One Day after, the same Job with another Daily Tape runs without Problem, and a Week later, the same failed Job with the same Tape run's again without any Failure........nobody knows why.....??? )

The Event found in Event Viewer was the same:

Source: VolSnap

Category: none

EventID: 25

"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."

Yet have found a Solution for this Issue??

Thanks

Peter

Hi,

Just got the same event 25 here.

Only with me it's on the C: drive, an internal SATA drive.  It occurred during software installation.

Any ides?

Gary

I got an event id: 25 on 11/6/2010 @ 9PM.

The shadow copies of volume F: 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.

 

VSS has always been disabled, but i did have a couple of manual snapshots stored. They are now gone.

 

Any updates on this?

Thanks

I am geting same error this on a SQL Server which hosts our sharepoint DB. We dont use Windows shadow copy services directly but I think Networker Legato uses to backup the server.  This happend couple of time in past 2 weeks and we have to recycle the sql server to get it to work . We have tried updated windows update but no luck.

This server has 2 partitions c:\ and d:\

c:\ has raid 10 and D:\ has raid 6

we use c:\ for system files and d:\ to store sql database files.

after the failure we see following event in the system event log

Event Type: Error
Event Source: VolSnap
Event Category: None
Event ID: 25
Date:  11/23/2010
Time:  2:00:06 AM
User:  N/A
Computer: SVR-NJ-SPDB01
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.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00 00 00 00 02 00 58 00   ......X.
0008: 00 00 00 00 19 00 06 c0   .......À
0010: 03 00 00 00 00 00 00 00   ........
0018: 06 00 00 00 00 00 00 00   ........
0020: 00 00 00 00 00 00 00 00   ........
 

digging dipper in the sql logs i found this

Date  11/23/2010 2:00:06 AM
Log  Windows NT (System)

Source  VolSnap
Category  (0)
Event  3221618713
Computer  

Message
The description for Event ID '-1073348583' in Source 'VolSnap' cannot be found.  The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them.  The following information is part of the event:'\Device\HarddiskVolumeShadowCopy33', 'D:'

  

Has any one tried applying this fix

http://support.microsoft.com/kb/833167

Hey Guys!

Was there any solution to this issue or key information that was uncovered? I'm having the same issue with a Windows Storage Server 2008 R2 Standard.
I've had volsnap throw up the same error as the OP:

Event ID: 25
Source:  volsnap
Level: Error
Description:  The shadow copies of volume C:\Data Volumes\Data 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.

3 times now we've lost 2 weeks of snapshots because of the purge this event triggers.

If anyone found information on solving this issue they could share I would greatly appreciate it!

I'd like to add myself to the list of people experiencing this issue.

 

We're currently using Backup Exec (but not using any of BE's AOFO technology) to transfer a backup of a SQL database from disk to tape. The backup files are held on a drive of around 14 TB, split into files of around 1 TB or less. The total size of the backup files is around 12 TB.

 

Shadow copies are not enabled on the drive holding the backups, but it looks like the process of backing up the files causes the VSS to take a snapshot of the drive in case the files change during the backup.

 

In the past, we have tried designating a different drive as the storage volume for the shadow copies, but with 12 TB of data it's difficult to find a drive with sufficient space.

 

I'd like to know if it is somehow possible to disable the VSS snapshot process for this drive? The SQL backup files are static (the actual SQL backup to disk has finished by the time the backup to tape starts), so we know that the files will not change during the backup. Therefore there is no need for the drive to be snapped before the backup starts. If we could stop this from happening then this would likely solve our problems.

 

Thanks,

Chris.

I got the same error also. Any idea? does it occur only on heavy I/O? what is heavy? everything lost :(

 

The setup:

Windows Storage Server 2k8 R2 Standard

7 Disk RAID 5 Array
DFSR - Read Only replica w/ Shadow Copies (2xDaily)
Backup Exec 12.5 - Backing up via Shadow Copy Components (After Hours)

I've run into the same issue with our backup server. We're using BackupExec in conjunction with HP's automated storage manager. Both leverage VSS. We've lost several weeks worth of snapshots several times now. In talking with both HP and Symantec they both make reference to this error being an expected behavior with VOLSNAP. Their recommendation is to lower I/O load by moving snapshots to a separate disk. We're in the process of doing so, however if this is expected behavior it seems like poor design to have VOLSNAP blow away all snapshots vs. abandoning the snap in progress during a period of high I/O. Seems like conflicting information as Bikash references

"The EventId 25 from volsnap deleting all the snapshots is not an expected behaviour."

We've noted this most frequently occurs when we are making backups and leveraging the Shadow copy components. Our backups are scheduled during off hours when there should little to no I/O other than the backups themselves. We have been able to manually snapshot after this event occurs and during work hours complete a full backup with no issues. Even with DFSR in full swing and taking two additional snapshots during that period. So the problem really seems to be when VSS should be trying to remove the oldest snapshot.

I e-mailed Bikash to inquire about any updates (Thanks for the reply Bikash!). June 1st he explained that he was no longer part of this project and but said he'd notify the correct folks. Haven't heard from anyone yet. I'll post if I get a response.

We've had success using the FilesNotToSnapshot registry key (which I think is only supported in 2008):

 

http://msdn.microsoft.com/en-us/library/bb891959%28v=vs.85%29.aspx#filesnottosnapshot

 

I found that the drive which held our full backups was actually being modified while the backup to tape was running, therefore causing the VSS snapshot to grow in size while it was running.

By excluding all the files and folders except for those actually being backed up, I was able to get a good full backup off to tape, and the actual snapshot size at the end of the backup (as reported by vssadmin list shadowstorage) was minimal, confirming that the snapshot was no longer growing.

The only problem with this kind of solution is that it effectively makes the exclusions invisible to anything which uses a VSS snapshot, so you may have to keep changing the exclusions depending on what you're backing up.

 

In any case, this solution is working for us for the time being - longer term we'll be moving everything else off that drive so that we don't need to worry about the snapshot growing significantly during the backup.

 

Chris

 

 

I am glad that i found this thread, i experienced the exact same issue a few days ago and the USB drive target was erased completely, we lost all our shadow copy backups, I posted a thread about it but I'll use this one from now on, here is the thread i made (no solution shared either): http://social.technet.microsoft.com/Forums/en-US/windowsbackup/thread/e20e2a35-5fbe-4e10-a44b-5220f2beba9e

The server the backup was running from was on 2008 R2 (not SP1) and we had two USB 1.5TB drive weekly rotated. Only one drive got erased because we were lucky enough to catch the issue in time, we are keeping the second drive unplugged until the issue gets resolved.

 

So is there any solution out there? I really love the built in backup but this is MAJOR problem, please advise !

 

ps: For the record, the event ID i got before the drive got erased are:

Event ID 2013: The T: disk is at or near capacity.  You may need to delete some files.

Event ID 25: The shadow copies of volume T: 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.

Drive T: is the one you are backing up, is that correct?

What is it used for? The reason shadow copies need to grow during a backup is that files are changing after the initial snapshot was taken. If files are being changed on T: while the backup is running, the snapshot will grow accordingly.

Chris.

 

^ T:\ external 1.5TB USB2 drive is used for backup correct.

 

That T:\ drive is EXCLUSIVELY used for that, no other process is accessing that drive except BITLOCKER for the encryption

 

Let me know if you need more details for troubleshooting, thanks

• Edited by Kilimats Monday, November 21, 2011 10:09 AM

Sorry, to clarify - is T: the source or the destination for the backup?

One thing to look at while the backup is running is 'vssadmin list shadowstorage' which will show you the current shadow copies held on the drive and how big they are. If you see the snapshot on this drive growing consistently during the backup, you'll know that something on the drive is changing while the backup us running.

yes, T:\ is the target for the bare metal recovery backup that runs on a daily basis

 

I ran that command twice while the backup was running (about half way through) a minute of each other, let me know what you think

 

 

Shadow Copy Storage association

   For volume: (T:)\\?\Volume{1ed0a48a-291a-11e0-80f0-f4ce46b58d81}\

   Shadow Copy Storage volume: (T:)\\?\Volume{1ed0a48a-291a-11e0-80f0-f4ce46b58d

81}\

   Used Shadow Copy Storage space: 110.199 GB (7%)

   Allocated Shadow Copy Storage space: 112.204 GB (8%)

   Maximum Shadow Copy Storage space: UNBOUNDED (1229552655%)

 

a minute later...

 

Shadow Copy Storage association

   For volume: (T:)\\?\Volume{1ed0a48a-291a-11e0-80f0-f4ce46b58d81}\

   Shadow Copy Storage volume: (T:)\\?\Volume{1ed0a48a-291a-11e0-80f0-f4ce46b58d

81}\

   Used Shadow Copy Storage space: 110.228 GB (7%)

   Allocated Shadow Copy Storage space: 112.204 GB (8%)

   Maximum Shadow Copy Storage space: UNBOUNDED (1229552655%)

 

Interesting,

Have you explicitly enabled Shadow Copies on T:? Check out the status of shadow copies for T: in Disk Management.

Looks to me like shadow copies are enabled on the drive and the backup itself is causing the growth (since the VSS service is trying to keep a copy of the files as they are replaced by the backup job).

Chris.

 

Not sure what to look for under disk management, I just went to the properties window of T:\ under the shadow copy tab and i see it shows as disabled in the NEXT RUN TIME column

 

We only enabled it on C:\ of the HyperV host and C:\ + D:\ of the file server VM running on that host.

Sorry, I'm not familiar with Windows Backup. A quick Google would suggest that it creates a VSS snapshot on both the source and destination.

Not sure if there's a way of stopping it doing that on the destination, but looking a the size of the shadow copy storage area, that's possibly the reason for your problems. Perhaps the shadow copy is not growing quickly enough due to I/O pressure.

 

Chris.

I'm no guru with VSS but to my understanding, the built in backup use VOLUME shadow copy to store incremental backups. The shadow copy tab is about FILE shadow copy for versioning, different stuff i think. Here is a good explanation: http://www.wbadmin.info/articles/how-does-windows-server-2008-backup-work.html

How do i escalate this a year and a half old issue to Microsoft ?

• Edited by Kilimats Monday, November 21, 2011 11:40 AM

Bump, is the best way of escalation to call them directly about it and mention this thread or maybe a MOD could forward it to them directly ?

I'm having this same issue as well.  It's happening on a file server during nightly backups.  We've been consolidating, so there are several drives on this server with varying capacity that all reside on a fibrechannel SAN.  For me, this error seems strongly correlated with drive size.  It happens regularly on the biggest of the drives (1950GB), and once a week or so on the next largest drive (793GB).  Server is running Win 2003 32bit - latest SP and patch level.  There doesn't seem to be any correlation with free space, as I have another drive (558GB) with far less percentage free space as the 793GB one that holds roughly the same types of files that never produces this error.

I completely agree that Microsoft needs to do something about this.  We'll be rebuilding this server soon, and I'm going to have to consider going with a product that supports snapshots reliably - RHEL with btrfs or Solaris with zfs, probably.

happened again today, has this issue been addressed by a hotfix yet ?

bump, i possibly found a solution, I adjusted the shadow copy setting on the external backup drive from NO LIMIT to a limit of 10GB under the max capacity, maybe doing this will avoid the problem, time will tell, Ill try to follow up once i've confirmed it works or not

Exactly, I had this same problem a year ago, and only managed to solve by changing the "no limit" to limit any higher than necessary. This solves the problem. Sincerely, Rodrigo Antunes.

I have similar problem.

Platform: Windows Server 2008 standard R2 with 4 hard drives.

Volumes:

Volume Type       Format     Label                      Size       Free   Free
    C: Fixed      NTFS       System                 68.36 GB   26.37 GB  38.6%
    D: Fixed      NTFS       DB                    164.49 GB  161.73 GB  98.3%
    E: Fixed      NTFS       Backup                931.51 GB  375.09 GB  40.3%
    F: Fixed      NTFS       Data                 1862.98 GB 1508.33 GB  81.0%

In windows server backup I have schedule to run backup every day. It is full server backup (without E of course) with exclusions for some directories. Backup destination is E usb drive.

Also I have Shadow Copies for F (Data) drive with limit 200000MB.

The event ID 25 is about deleting volume shadow copies for E drive. After that I don't have older backups.

Someone could tell me what is all about?

Thanks in advance.

^ read the posts above yours...

Coul'd you please point me exactly what I should analize in this thread? Becouse it is not obvious what you have on mind. Thanks.

^ you need to set a limit on the shadow copy size by going to the drive properties and setting the size limit under the shadow copy, dont set the limit too close to the drive max capacity, give a few hundred MB i'd say, i can't believe Microsoft didnt document this anywhere....

Just experienced the same problem. Major disaster for us.

Hyper-V 2008 R2 backing up 26 Virtual Machines to DELL MD3200, 5TB disk.

Had over 100 copies in history. WSB has been, for months, happily managing the deletion of oldest backups to make room on the drive.

Last night received volsnap info event 33, followed by volsnap error event 25 The shadow copies of volume G: 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.

Other than WSB, there was no other IO on the target.

I now have a single backup of my VMs. I can't really describe how bad a situation this has but us in . . .

Justin

set a limit on the shadow copy size as described above

If only it was documented in windows and a warning would be shown if it wasnt set....

Has any one tried applying this fix

http://support.microsoft.com/kb/833167

That hot fix is for Win2003

• Edited by Robert Ebers Wednesday, October 10, 2012 8:43 PM

Hi Guys

We're now experiencing this error also. Has there been any update?

set a limit on the shadow copy size as described above

If only it was documented in windows and a warning would be shown if it wasnt set....

Few month later, My backup disk ran out of space and delete the entire partition once again so this fix does not work afterall, back to the drawing board.....

Bikash,

I'm wondering if you are still around. You mentioned you would update this thread when some useful information became available. That was two years ago. Has Microsoft addressed this problem at all? If so, could you please update this thread for the many users that have come across this issue. I'm encountering the same problem that many have had, and when I find threads such as these, with the possibility of finding an answer, only to find that we are being left to our own demise; it tends to make us lose confidence in Microsoft.

Please let us know what's going on with this. There are still users/companies that have Windows Server 2003 running.

Leo Marquie

I have a Windows Small Business Server 2008 machine being backed up using the Windows Server Backup utility.  The backups are being made to two external USB attached 1TB drives.  Each drive is rotated out weekly, meaning that one drive is attached one week, then the other drive is swapped in the following week, ad infinitum for the best part of a year.  Two backups were being made each day to the attached drive, one at 12pm and one at 9pm.

About two weeks ago it appears that one of the two drives reached capacity and began shedding the oldest backups, as confirmed by the VOLSNAP Event ID: 33 entries in the System Event log.  On the second day, however, ALL shadow copies on the attached backup driver (volume) were deleted, as confirmed by a single VOLSNAP Event ID: 25.  (See below for both Event ID message contents.)  Unfortuneately, neither events were noted until the drive was swapped out with the other drive and some how the problem was propagated to the second drive, resulting in the deletion of all shadow copies on the second drive, too. 

The end result... BOTH drives lost ALL previous backups leaving only the most recent full backup and no clue as to why it happened or how to prevent it from happening again.  Virtually no older backup file versions could be recovered.

I was under the impression that, by design, the WSB utility would only start deleting the oldest backups (on a full drive) in order to make room for the newer backups.  Granted, had I been keeping attention, I would have actually swapped out the full drives before the actually got full, so that NO data was deleted.

If I'm to continue using the Windows Server Backup utility, I need to know what happened and how to absolutely prevent it from happening again.  I never expected to loose BOTH backups at the same time, and due to budget restraints, two rotating backup drives seemed a logical solution.

Here is text from the two VOLSNAP Event ID messages found in the System Log:

Event ID: 25
Source:  volsnap
Level: Error
Description:  The shadow copies of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} 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.

Event ID: 33
Source: volsnap
Level: Information
Description: The oldest shadow copy of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} was deleted to keep disk space usage for shadow copies of volume \\?\Volume{93896cfc-d904-11dd-8cb5-001ec9ef572e} below the user defined limit.


NOTE:  Though I'm not sure if this has any bearing on the situation, the server is configured to make two snapshots a day of two volumes on the server, however, when I looked at the Shadow Copy settings I couldn't quite be sure if the VSS wasn't somehow also making snapshots on the two external drives, even though I haven't specified VSS to do so.  None show up on the two replacement drives I'm now using, so I'd say not.


Information on how to prevent this from happening again would greatly be appreciated.  (I'll be making sure no backup drive gets even close to being full from now on, that's for sure!)


Thanks,



Joseph.

This question was originally asked over 2 years ago. Is there any answer that Microsoft would be willing to provide for those of us that are struggling to find the answers?

I've tried to fix a similar problem with Microsoft Support.

During normal Windows 2008 R2 file server server operation (writing files to the NTFS volume) Event 25 appears sporadicly and all snapshots are lost.
There is only the "Microsoft Software Shodow Copy provioder 1.0" active, the System ist only used as file server for backups, ist has a 40 TByte RAID Volume with a sequential read/write performace of 950 GByte per Second. Cluster size of the NTFS volume is 16k and the MinDiffAreaFileSize was set to the maximum recommended valzue of 3000 MByte.

Unfortunately, Microsoft has no intention to fix that problem, because Microsoft does not want to enter into competition with vendors of professional storage systems. After some time Microsoft will tell the customers, that the product ist out of mainstream support. Probably also applies to Windows Server 2012.

Martin,

Thanks for posting this response. I wish Microsoft support could keep up on these threads. 

I've been trying to resolve this issue, and I'd followed one set of fixes that told me to edit the registry value to accommodate a larger VSS size, now I'm getting an event error of 20 telling me that the COM+ database may be corrupt. The other possibility is that the setup may have not installed properly. I wasn't here when it was installed, so I can't even verify it's success. 

Good luck to all that have been having these problems. I'm still trying to figure them out on my end when normal operations allow.

I've tried to fix a similar problem with Microsoft Support.

During normal Windows 2008 R2 file server server operation (writing files to the NTFS volume) Event 25 appears sporadicly and all snapshots are lost.
There is only the "Microsoft Software Shodow Copy provioder 1.0" active, the System ist only used as file server for backups, ist has a 40 TByte RAID Volume with a sequential read/write performace of 950 GByte per Second. Cluster size of the NTFS volume is 16k and the MinDiffAreaFileSize was set to the maximum recommended valzue of 3000 MByte.

Unfortunately, Microsoft has no intention to fix that problem, because Microsoft does not want to enter into competition with vendors of professional storage systems. After some time Microsoft will tell the customers, that the product ist out of mainstream support. Probably also applies to Windows Server 2012.

I have a similar problem on a Windows 7 laptop system.  VSS has already corrupted my HDD a couple of times costing me untold hours (actually days) of work in restoring backups, recovering data and reinstalling applications.  I already tried increasing the VSS storage (from 10GB to 48GB) and increasing MinDiffAreaFileSize to the recommended 5% of restore point storage allocated.  This seemed to help for a couple of days and then the problem recurred.  I had high hopes of fixing the problem by reformatting the main partition to use 16K, as suggested in this KB article, but your experience above has dashed my hopes.  In fact, I'm not even sure that the above-mentioned KB is relevant.

This appears to be a fairly common problem, going back for MORE THAN 6 YEARS!  This KB article refers to a hotfix for Server 2003, but if the problem was already fixed in 2003 SP1, why is it still occurring in later OSs like Windows 7 and Server 2008?  Has it been fixed in any of the newer OSs, e.g. Windows 8?

Some articles blame 3d party VSS writers for this behaviour, and suggest:

vssadmin list writers

to identify them.  On my system, this yields a list of 11, but no clue as to which are (not) from Microsoft.

How can I make this distinction?

What good is a backup service, which is not only unreliable, but even corrupts HD storage?

The easiest solution would seem to be to turn off VSS, but when I look at the services on my laptop, it isn't running anyway?!  How can this be?

This KB article suggests using a different HDD (not physically possible with my laptop) or at least another volume for either the VSS storage or the pagefile.  Can anyone suggest which of these options would be better and why?

Is there some other workaround for this?

P.S. To answer my own question about whether to move VSS storage or pagefile, MS has made the decision for me, by crippling vssadmin under Windows 7.  See this article.

• Edited by rsbrux Monday, June 24, 2013 6:42 AM added information

I have a Windows Server 2008 R2 SP1 on Dell Server PE R210 with two 2TB drives using RAID 1 on an SAS 6/iR Adapter. The drives are about half full. It is used as a file server for a 50 person network and also has two hyper-v's. One hyper is a Barracuda Spam and Virus Filter and the other is another 2008 R2 server running one specific application. The server is stable, except that from time to time I do have trouble with opening the WSB console. It will work fine for months then all of a sudden take hours. Disk Management also will run into similar problems around the same time. I attributed this to possibly problems with the USB backup drive or corruption in the WSB catalogs. One time deleting and restoring the catalogs from the backup disk fixed the WSB console issues. Recently I have been having problems opening WSB and disk management again. I rebooted the server and I noticed that WSB opened quickly but my backups were not accessible anymore from Recover..., only the one it did previously. I tried the restore catalog function but that didn't work. I dug deeper and ran vssadmin list shadows and there was only one entry. There were about 100 copies\backups previously. I noticed the event 25 volsnap and wound up here searching for an answer. I expect to be able to go back to any point in time in the last few months and be able to pull up a missing file. WSB sure gives the impression it should do that. Inexplicably, all the backup copies appear to be gone. I understand overwiting the oldest copy to make room, which I am familiar with. In fact I was getting ready to replace this drive with another as it was almost full. It had about 150 GB left on a 2TB USB drive. It still says 150GB free, even though the shadow copies appear to be gone. The vhd from the backup is around 800GB. This leads me to believe that they might still be there since it didn't seem to free up space, or at least not in proportion to what it should have if it deleted all the copies. I should be looking at a TB or so free, if the shadow copies were truly deleted from the disk. Are they corrupted, so they appear missing, but still take up space? I don't know. Any help would be appreciated. Definetly going to be moving away from WSB after this. I had my issues with it before, but was always able to make it work. This is just inexcusable and I'm very pissed as a loyal Microsoft customer that their product takes liberty to just delete files when things get a little hairy.

• Edited by jghjhjj Friday, August 30, 2013 7:03 PM

Still broken on a fully patch server 2012

Got VolSnap 25 event trying to restore VSS previous version of a 1.2TB directory on 2TB disk with 50GB free on 2003 Server Standard.

No previous version tab in the properties anymore :(

Can confirm this same issue on Windows Server 2012 as well.

Same  Problem here Server is a Storage Server 2012 Cluster (HP EasyStore 5530)

Fully Patched. 

• Edited by Johannes Michel Monday, February 24, 2014 9:58 AM

I think this problem is related to memory consumption problems. When you are using slow drive (such as USB one) Windows cashes disk writes using system RAM. The root of the problem is: there is no default limit of memory Windows x64 can use as cache. So every time Windows writes large data to relatively slow drive, you may see something like

• Available memory is almost exhausted.
• The system file cache consumes most of the physical RAM.

So when you write your backup data, and the VSS needs some more memory and asks system for more, it may get an error, and delete all the snapshots.

http://support.microsoft.com/kb/976618/en-us

Maybe this tool will help "Microsoft Windows Dynamic Cache Service"

Or maybe setting LowMemoryThreshold will be helpfull.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

LowMemoryThreshold                (REG_DWORD) This value is in Mbytes

• Edited by Mikhail Krasnobaev Sunday, March 02, 2014 4:07 AM

I was able to find a way to make error 25 and 27 happen at will.  I created a dedicated dump file instead of using the pagefile.sys for system dump files.  You create this dedicated dump file by adding entries to HKLM\SYSTEM\CurrentControlSet\Control\CrashControl.  I did this so that I can run without a pagefile on my SSD and still be able to acquire dump files in case of a system crash.  I moved the dedicated dump file to d:\ and my boot time increased by 3 minutes and all volsnaps on d: were removed by an error 25 followed by 2 volsnap error 27s.  I moved the dedicated dump file to drive e:\ and the next reboot did the same to drive e:.  An extra 3 minutes to boot and an error 25 followed by 2 error 27s.  When I moved the dedicated dump file to e: I reduced the amount of disk space for the file from system controlled (17GB with 16GB of RAM) to 7GB.  The volsnaps were still deleted due to error 25/27.  It appears that the volsnaps may be deleted due to large pagefile.sys or DedicatedDumpFile.sys activity on the disk making the volsnap grow in size during boot.  I have .5GB free on d: and 1TB free on e:.  I would not expect vss to be running during boot, but apparently it is.  I am far from being an expert on VSS.  Let me know if this helps anyone to at least duplicate the problem or possibly help resolve it.  I am not going to try this on my c: drive.

The volsnap error 25 occurs immediately during boot.  Then there is no activity until the volsnap error 27s about 2 1/2 minutes later.  No activity in any other Windows Event logs either.  Disk activity is constant during this 2 and 1/2 minutes even if there is only 1 volsnap stored on the drive.

I have the same Problem with Server 2012 Standard and Windows Backup.

Backing up the C: System and D: Data drive to an internal 3 TB SATA - HD, there were appr. 1.4 TB used on
the backup drive. It works great for over 10 weeks now. There were over 50 backups available when I controlled last time. Today only 2 backups are there, since 2 nights ago there was the volsnap error 25.

Would be really great to get a reason why this happens...

thomban

It seems that changing the "Maximum Shadow Copy Storage Space" value on the volume with the volsnap 25 error from "UNBOUNDED" to a value e.g. 80% of the volume size could resolve the issue:

vssadmin resize shadowstorage /for=Volume_Letter: /on=Volume_Letter: /maxsize=80%

Check out:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/edcfbc44-5171-4fb5-9e0f-b5404364401c/event-id-25-volsnap

for refe