This post is more than 5 years old
6 Posts
0
21799
Inconsistent Shadow Copy with System Writer
Hey guys,
I'm having a problem with one Windows 2012 R2 client running on VMware, backing up with Networker 8.2.3. I'm hoping you guys will be able to straighten me out, I'm about ready to format the server and start over. Here's the facts and what I've done so far.
1) Windows server backup is successful doing a full bare metal backup, therefore I don't believe VSS is the culprit.
2) Networker reports error:
5388:save: Failure status of writer System Writer - VSS_WS_FAILED_AT_PREPARE_SNAPSHOT
VSS OTHER: ERROR: VSS failed to process snapshot: The shadow-copy set only contains only a subset of the
volumes needed to correctly backup the selected components of the writer. (VSS error 0x800423f0)
90108:save: Unable to save the SYSTEM STATE save sets: cannot create the snapshot.
86024:save: Error occured while saving disaster recovery save sets.
3) After resetting all VSS Writers, rebooting, and performing backup, SYSTEM WRITER reports error:
Writer name: 'System Writer'
Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Instance Id: {b0094e31-feec-4dec-b372-1d517c14c44b}
State: [8] Failed
Last error: Inconsistent shadow copy
4) No other writers are in error after a Networker backup
5) VSSTRACE reports error during Networker backup
[14:38:33.513 P:03F0 T:044C WRTWRTIC(2600) WRITER] Writer System Writer exposing state<8> failure<0x800423f0>
6) Windows 2012 R2 client is fully patched
7) I've tried assigning a drive letter to the system partition on this machine, that did not fix the problem.
8) I tried VSSADMIN DELETE SHADOWS /ALL. This did not fix the issue.
9) I removed the Networker client, deleted all associated directories, and re-installed. This did not fix the issue.
Does anyone have any ideas on what else I can try to resolve this issue before I re-install Windows? I've been through about 200 tech articles and EMC user technical questions in this community.
Any help would be appreciated.
Thanks
Joel
R_Friberg
34 Posts
2
April 16th, 2018 05:00
Hi Joel,
I usually try this when VSS is giving me a headache.
Start diskshadow and log to file:
diskshadow /l logfile.txt
from diskshadow run the commands:
set verbose on
list writers
exit
Then use a text editor and look into the logfile.txt file. Under the section of the offending VSS writer you will most probably find a line saying that there is a file or path it cannot find. Try to correct and that and rerun your backup.
bingo.1
2.4K Posts
0
April 16th, 2018 05:00
The message reads as if the system is incapable to get access of all the volumes which it needs for a full system backup.
Although Windows 2012 is not explicitely mentioned, I think this article could be helpful:
support.microsoft.com/en-us/help/2457458/windows-backup-fails-when-you-back-up-data-from-the-root-folder-of-a-m
https://support.microsoft.com/en-us/help/2457458/windows-backup-fails-when-you-back-up-data-from-the-root-folder-of-a-m
Joel_Kraft
6 Posts
0
April 16th, 2018 08:00
Hey bingo,
Unfortunately, there is no hotfix available for 2012. I'm assuming they incorporated this fix into 2012 as the hotfix was published in 2011.
Thanks anyway
Joel
Joel_Kraft
6 Posts
0
April 16th, 2018 13:00
Hey R.Friberg,
I think I'm heading in the right direction thanks to your help.. but I'm not exactly sure where to go from here. The path that is missing is a directory on a remote server. I'm not sure why the system writer would think it is local to the machine I'm trying to back up. Have you seen anything like this before?
I attempted to add an exception to the system writer by modifying the registry to skip this path as described here BMR + Critical Volumes + Workaround, but that didn't work.
Thanks
Joel
+ Component "System Writer:\Win32 Services Files"
- Name: Win32 Services Files
- Logical path:
- Full path: \Win32 Services Files
- Caption: Win32 Services Files
- Type: VSS_CT_FILEGROUP [2]
- Is selectable: TRUE
- Is top level: TRUE
- Notify on backup complete: FALSE
- Paths affected by this component:
- \\fileserver\ras30
- c:\program files (x86)\bit9\parity agent
- c:\program files (x86)\common files\microsoft shared\phone tools\corecon\11.0\bin
- c:\program files\emc networker\nsr\bin
- c:\windows\carbonblack
- c:\windows\syswow64
- Volumes affected by this component:
- \\?\Volume{aefd7eeb-1ca5-11e6-80b4-806e6f6e6963}\
- \\FILESERVER\RAS30\ [Does not exist]
- Component Dependencies:
R_Friberg
34 Posts
1
April 17th, 2018 04:00
Hi Joel,
Now that you know the path, you can most probably find out which service it is that is using the remote file share. If memory serves me right you can run msinfo32.exe and go to services and you should see the path that each service is pointing to. Otherwise you can use the registry to find out which service is using the path.
I usually just force the application owner of such a service to do a reinstall of their application and require them to have it installed locally on the server and not a network share.
Regards
Rickard
Joel_Kraft
6 Posts
0
April 17th, 2018 12:00
Awesome, awesome Rickard, thanks for your help!
Joel