Wild guess, but knowing you you have probably already had a look at this:
It also doesn't explain why it's working when you backup C:\.
Maybe you've discovered another bug?
Do you have a bpbkar log?
have you had any information about symantec ?
I have the same problem with a client in 6.5.4 and servers in 6.5.5
the backup stops when processing the directive Shadow Copy Components.
I am using 7.0.1 and DFSR and 2008 servers.
The change between 6.5.x and 7.0.x is that now the DFS drive data is going to try to backup inside the SCC job.
So it will be a big job and always a full.
I have drive E as a dfsr drive.
I do all local drives. E only gets a few meg.
SCC is huge - you need to make sure that it is using VSS (client attributes in master server properties). SCC does not do incrementals.
So if you get the SCC job to finish and you go look at it in the BAR you will see DFS and all your files that reside on your DFS drives.
My issue was that it took 2.5 days to backup the DFS drives in the one BIG SCC job.
So I turn dfs off (via bpstart_notify and bpend_notify) so the backup of the E drive gets those files ( and is able to do an incremental) and the SCC does all its other stuff but does not backup the files from the DFS drives.
We also faced lot of system state backup issues with respect to win 2008. In allmost all the cases we got it resolved .
We need to verify lot of things with respect to this , below are some of them which may help.
1. Verify the VSS writers in the client i.e.by typing vssadmin list writers in the command mode . All the writers should be stable , sometimes it will be in waiting for completion state . EVen that is also ok . If you found any failures in the writers then system state backup will fail.
2. Then run the system state backup from windows native backup. If its works fine here then definately it will work in Netbackup.
3. verify the shadow copy space give for C:\ drive . It should be atleast 1Gb space else the backup will fail. It is better to increase some 2 - 4 GB .
4. In the NetBackup side verify the timeout setting of the client , by default it will be 300 sec but for win-2k8 system state backup it is not sufficent . Increase this by 1600 or more .
5. In some of the SAP clustered servers you may face system state backup issue with passive nodes , even in Native windows backup also it won't work . This is because SAP servies are installed in cluster drives and that service will not be availabe in passive node. To resolve this issue you need to exclude some of the sap services from system writers.
Just an update......
This issue was resolved and the actual problem was with Equallogic VSS. When the servers were installed, the HIT kit used was old and the MPIO was not properly reqistered on the servers. Everytime the backup was attempted this error was generated:
Log Name: Application
Date: 2010/08/21 08:46:02 PM
Event ID: 4002
Task Category: VSS
Error 0x80070490 opening SNMP connection to \\.\PHYSICALDRIVE1(0-8a0906-ca190ec06-928000000414c47e).
Log Name: System
Date: 2010/08/21 08:46:02 PM
Event ID: 113
Task Category: None
iSCSI discovery via SendTargets failed with error code 0xefff0024 to target portal *10.20.1.50 0003260 EBDRV\L4SC&PCI_164F14E4&SUBSYS_112314E4&REV_00\5&8571ec8&0&30050300_0 .
We encounter the same problem using 7.01 (Master Solaris 10 Sparc, Media Solarisx86 AMD, Client W2k8R2), RC is 50, message text the same (ERR - Unable to backup System State or Shadow Copy. Please check the state of VSS and associated Writers.ERR - Unable to backup System State or Shadow Copy. Please check the state of VSS and associated Writers.ERR - Unable to backup System State or Shadow Copy. Please check the state of VSS and associated Writers.ERR - Unable to backup System State or Shadow Copy. Please check the state of VSS and associated Writers.INF - Estimate:-1 -1).
Not all the servers have that, on some the backup is o.k. - but not in ShadowCopyComponents, but normal files, some in ShadowCopyComponents, some in normal files and ShadowCopyComponents hangs.
The servers are all setup similarly and the policy are similar.
I'll try to address that at the next usergroup meeting in Munich
Conclusion from usergroup meeting: Everybody faces problems backing up DFS-R . . .
We changed the policies to flashbackup, seems to work.
Btw, there is also a problem restoring DFS backup from SCC due to the path. We always have to move the restored files manually, they never restore correctly - no matter if via "restore everything to . . ." or change "selected destination . . ."