Shadow copy failure - what fixed it?

[pshute]

For several days, one particular server was failed to back up, with this error:

Code: Select all

Processing serverxyz Error: VSSControl: -2147467259 Backup job failed. Cannot create a shadow copy of the volumes containing writer's data. VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].

I removed two forgotten snapshots from it, but it was still failing. I was able to create a snapshot, and remove it again, which I thought would mean Veeam could too.

Today I applied some Windows updates and rebooted it, and now it's backing up ok. I would not have thought either of those things could fix this. Could they? Or is it a coincidence, and something else changed?

[HannesK]

well, reboot can "fix" many things

for troubleshooting VSS, I can recommend https://www.veeam.com/kb1980

[foggy]

And as usual, feel free to contact our technical support directly if the issue shows up again - they will be able to assist in further troubleshooting.

[pshute]

It ran ok for a few days, then had the error again last night.

I ran the copy only mode test at https://www.veeam.com/kb1980, but it seemed to run ok, and I couldn't see any errors in the event logs from it. But I did notice a few of these in the system event log, at times that might correspond with backup attempts that failed:

Code: Select all

Type :		Error
Date :		15/10/2019
Time :		5:03:29 AM
Event :		41
Source :		volsnap
Category :	None
User :		N/A
Computer :	xyz
Description:
When preparing a new volume shadow copy for volume C:, the shadow copy storage on volume C: did not have sufficiently large contiguous blocks.  Consider deleting unnecessary files on the shadow copy storage volume or use a different shadow copy storage volume.

It's got more free space than it did before the problems started, but has never been defragmented. I've cleared a lot more space, and I'm running defrag. I'll see how it goes tonight.

[pshute]

Last night's backup worked ok. Can't be sure it's permanently fixed, but it looks like low disk space and fragmentation can cause this problem. Looks for event 41 in the affected machine's system event log.