Same here.

Client added to new NetBackup environment. Client was previously running NBU client version 4.5, now upgrade to version 6.0 MP6.

Backup selection contains the standard Windows 2003 directive entries.
Consisting of all_local_drives and the shadow copy components. The first one exits with a code 0. Shadow copy components backup fails with a code 71.

I've enabled full client logging todo some troubleshooting. The bpbkar log show some information:

bpbkar logfile contents:

12:08:44.737: [3596.3972] <2> tar_backup::V_SetupProcessContinue: TAR - CONTINUE BACKUP received12:08:44.737: [3596.3972] <2> tar_backup::V_SetupFileDirectives: TAR - backup filename = Shadow Copy Components:\12:08:44.737: [3596.3772] <4> tar_base::V_KeepaliveThread: INF - The Keepalive thread is active. Keepalive interval 60 Seconds12:08:44.799: [3596.3972] <2> ov_log::V_GlobalLog: INF - BEDS_Init() Enter InitFlags:0x012:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: C:12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Microsoft Terminal Services12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Microsoft Windows Network12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Web Client Network12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Oracle12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: ihcds0112:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: INF - DumpDleInfo() DLE Device Name: Shadow—Copy–Components12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: ERR - BEDS_AttachToDLE():FS_AttachToDLE() DeviceName:'Shadow˜Copy™Components' BackupReason:0x1 Failed! (0xE000FEC5:A failure occurred accessing the Volume Snapshot Service interface.)12:08:44.831: [3596.3972] <4> dos_backup::V_VerifyFileList: INF - unable to determine UBS type for:Shadow Copy Components:12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: ERR - BEDS_AttachToDLE():FS_AttachToDLE() DeviceName:'Shadow?Copy?Components' BackupReason:0x800 Failed! (0xE000FEC5:A failure occurred accessing the Volume Snapshot Service interface.)12:08:44.831: [3596.3972] <4> backup_create: INF - NetBackup Temp Directory: 'C:\Program Files\VERITAS\\NetBackup\Temp'12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - ================================================================================12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - job tracking estimate: start12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: ERR - BEDS_AttachToDLE():FS_AttachToDLE() DeviceName:'Shadow?Copy?Components' BackupReason:0x400 Failed! (0xE000FEC5:A failure occurred accessing the Volume Snapshot Service interface.)12:08:44.831: [3596.3972] <2> tar_base::V_vTarMsgW: TRV - object not found for file system backup: Shadow Copy Components:12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - job tracking estimate: stop12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -     job tracking time: 0 secs12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - ================================================================================12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - ================================================================================12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - Job Tracking Estimates12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - --------------------------------------------------------------------------------12:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -           Files: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -         Folders: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -      Bytes Data: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -  Gigabytes Data: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF -     Bytes Image: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - Gigabytes Image: 012:08:44.831: [3596.3972] <4> tar_backup::V_DetermineEstimate: INF - ================================================================================12:08:44.831: [3596.3972] <2> ov_log::V_GlobalLog: ERR - BEDS_AttachToDLE():FS_AttachToDLE() DeviceName:'Shadow?Copy?Components' BackupReason:0x2 Failed! (0xE000FEC2:A failure occurred accessing the SnapShot handle.)12:08:44.831: [3596.3972] <2> tar_base::V_vTarMsgW: TRV - object not found for file system backup: Shadow Copy Components:

Service Pack on Win2003 Clients?

Is Volume Shadow Copy Service running on Client?

Is VSP or VSS set up for Client on NetBackup in Open File Backup?

NetBackup version?

I have an issue open with Symantec and Microsoft on this problem. VSSADMIN list writers shows some of the writers in "waiting for completion" state. Symantec says this is the problem. Microsoft contends that "waiting for completion" state is not a problem. Whether the writer is "stable" or "waiting for completion" should not matter according to Microsoft. There is an update for volume shadow copy service. I have not decided yet whether to install it.

Is this a cluster environment? if it is normaly when we try to backup the clustered drives on the node that doesnt have the volumes this fail with 71's is just a common thing

Hi Omar, unfortunately this Server ist not clustered, so the disk that is backed up is always available. The backup was fine and changed from one day to the other to failing.

Try to follow this and see if you get something.

http://seer.entsupport.symantec.com/docs/278505.htm

regards

upgrade the service pack on the client end ,and see if are able to do ...

Any updates on this issue? Has anyone been able to find a resolution besides upgrading to SP1?

I have window 2003 servers with sp2 and I still get the shadow copy errors.

I was going to try this...

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

Any update on this issue, I am also geting status code 71 for windows 2003  (vmware) Shadow Copy component  backup.

Googled "Shadow Copy Components" and it seems to occur with every backup product from every vendor so it must be a Windows issue.  Review the MS Knowlegebase links and try ntbackup and once you get that working then Netbackup will probably work too.

We are having the same issue. In our case, it had been working fine then stopped all of the sudden in early March.

I've tried several Microsoft technet articles with no luck.

We are now going to target some security patches that were installed about the same time the functionality stopped.

If anyone has any updates I'd be happy to hear them.

-> delete the following files:

<install_path>\NetBackup\db\images\<client name>\streams
<install_path>\NetBackup\db\images\<client name>\streams.lck

-> Run bpmount command on the client to see if it is trying to backup the CD ROM device.

-> Check the state of vsswriters :
vssadmin list writers

-> Try to backup only the Shadow_copy_components in the policy to isolate the problem.

Hope this helps

Just wondering if anyone else noticed if the Shadow Copy problems are exclusive (or at least predominant) on SQL servers.  We had this problem before and could not find a permanent resolution (we' tried the Microsoft VSS patches, but the problem would resuface in a day or two after we applied them). 

We finally just ignored the Shadow Copy Components and specified each individual drive to back up in the policies.  Pain in the backside, but we had fewer failures show up in the backup reports.

Yes, our problem is on SQL servers. Win2k3 with SQL 2k5.

Did anybody ever find out a resolution to this problem?

Thanks,

Hi guys,

It may be a lot simpler than you all think. When we get a 71 error here, it is usually directly linked to the client_name value in the configuration.

For NetBackup is quite case sensitive, although it says windows media server is not, my experience begs to differ.

You need to check four things:

1) the value of the `hostname` command run from a cmd prompt or from a shell prompt (OS dependent) 
2) the value used for the client name during installation (located using bp.conf Client_Name on Unix, Backup Archive and Restore on windows)
3) the value used in DNS or in the 'hosts' file on the master/media server you backup to
4) the case of the server name in the policy used to backup the server

Now, I know what you are thinking, this cant be all it is, but give it a try.

The `hostname` value needs to be the same as the value used in the hosts file on the master server or in DNS, same case etc.
The policy server name value needs to the same as the Client_Name value

Let me know if this does not fix is.

Also you could try to create the bypass errors in the configuration.

bpclient -client client_name -update -WFOB_FIM 1
(This command ^ is used to force VSS usage)
bpclient -client client_name -update -WFOB_error 1
(This command ^ is used to make it pass this error, which is a none error)

Hope this helps.