Highlighted

sts_close_handle failed: 2060019 error occurred on network socket

**** Moved to new discussion from https://www-secure.symantec.com/connect/forums/client-backups-status-87-83-5020-appliance?page=0 ****

I am also getting this error

9/06/2013 9:19:53 AM - Critical bptm(pid=8352) sts_close_handle failed: 2060019 error occurred on network socket     
9/06/2013 9:19:53 AM - Critical bptm(pid=8352) cannot write image to disk, media close failed with status 2060019

Did you get this resolved? Im using Windows 2008R2 7.5.0.5 Master/media and a Windows 2008R2 7.5.0.5 Client. This is its first backup and server is about 1.5TB backed up via Lan.

Simon

2 Solutions

Accepted Solutions
Highlighted
Accepted Solution!

Ah if that is the case you

Ah if that is the case you may want to try increasing your client read timeouts and see if it gives you enough time to complete the backup.

 

If you have any other questions please let me know.

Thanks

View solution in original post

Highlighted
Accepted Solution!

Do you have the \program

Do you have the \program files\veritas\netbackup\db\config\DPS_PROXYDEFAULTRECVTMO file in place - if so what setting does it have?

If not please create this on your Master / Media Servers and add a value of 800 into the file

This helps keep the disk pool up and happy at very busy times when the Master could believe it has problems

I always use this setting for any de-dupe or enterprise disk setups (but none of the other DPS_ file though)

Hope this helps

View solution in original post

11 Replies
Highlighted

What type of storage unit is

What type of storage unit is it going to ? What is the exit status ?

I know I have seen '2060019' before.

Doing a quick search I found :

http://www.symantec.com/docs/TECH126154

https://www-secure.symantec.com/connect/forums/client-backups-status-87-83-5020-appliance

 

Highlighted

The Windows 2008R2 has a MSDP

The Windows 2008R2 has a MSDP pool which is currently being used by other machines without issue.

There is 12TB free on the dedupe pool.

 

11/06/2013 10:51:13 PM - Info bpbrm(pid=9316) starting bpbkar32 on client         
11/06/2013 10:51:13 PM - connected; connect time: 00:00:02
11/06/2013 10:51:21 PM - Info bpbkar32(pid=4444) Backup started           
11/06/2013 10:51:21 PM - Info bptm(pid=8784) start            
11/06/2013 10:51:21 PM - Info bptm(pid=8784) using 262144 data buffer size        
11/06/2013 10:51:21 PM - Info bptm(pid=8784) setting receive network buffer to 1049600 bytes      
11/06/2013 10:51:21 PM - Info bptm(pid=8784) using 30 data buffers         
11/06/2013 10:51:21 PM - Info MasterServer(pid=8784) Using OpenStorage client direct to backup from client SERVER to MasterServer
11/06/2013 10:51:26 PM - begin writing
11/06/2013 10:51:46 PM - Info bpbkar32(pid=4444) change journal enabled for <D:\AppsData>        
11/06/2013 10:56:20 PM - Info bpbkar32(pid=4444) NOT using change journal data for <D:\AppsData>: no previous track log  
11/06/2013 10:57:15 PM - Info bpbkar32(pid=4444) change journal enabled for <E:\CorpData>        
11/06/2013 10:57:24 PM - Info bpbkar32(pid=4444) NOT using change journal data for <E:\CorpData>: no previous track log  
12/06/2013 2:58:58 AM - Info bpbkar32(pid=4444) change journal enabled for <D:\UserData>        
12/06/2013 3:03:32 AM - Info bpbkar32(pid=4444) NOT using change journal data for <D:\UserData>: no previous track log  
12/06/2013 7:39:08 AM - Info bpbkar32(pid=4444) accelerator sent 1094142767104 bytes out of 1091479222272 bytes to server, optimization 0.0%
12/06/2013 7:39:08 AM - Info bpbkar32(pid=4444) bpbkar waited 263358 times for empty buffer, delayed 290100 times.   
12/06/2013 7:39:08 AM - Critical bptm(pid=8784) sts_close_handle failed: 2060019 error occurred on network socket     
12/06/2013 7:39:08 AM - Critical bptm(pid=8784) cannot write image to disk, media close failed with status 2060019  
12/06/2013 7:39:08 AM - Info SERVER(pid=8784) StorageServer=PureDiskSmiley FrustratedERVER; Report=PDDO Stats for (MasterServer): scanned: 1065942210 KB, CR sent: 2334601 KB, CR sent over FC: 0 KB, dedup: 99.8%, cache hits: 0 (0.0%)
12/06/2013 7:39:08 AM - Critical bptm(pid=8784) sts_close_server failed: error 2060005 object is busy, cannot be closed   
12/06/2013 7:39:18 AM - Info bpbkar32(pid=4444) done. status: 87: media close error       
12/06/2013 7:39:18 AM - end writing; write time: 08:47:52
media close error(87)

Highlighted

Here is the end of the bptm

Here is the end of the bptm log for PID 8784

07:39:07.810 [8784.9324] <2> send_MDS_msg: KBYTES_WRITTEN 0 {5D116E9A-2DAB-446D-B9AA-88B7F9DFBF0B} 4150 1 4360 3094
07:39:07.810 [8784.9324] <2> JobInst::sendIrmMsg: returning
07:39:07.810 [8784.9324] <4> stop_job_data_timer: end throughput timer (1065897678 31593931 33737)
07:39:08.044 [8784.9324] <16> 3094:bptm:8784:MasterServer: [ERROR][proxy_close_image_v7]STSException is caught in proxy_close_image_v7:
sts errno: 2060019
error message: fail to close image
07:39:08.044 [8784.9324] <32> bp_sts_close_target_image: sts_close_handle failed: 2060019
07:39:08.059 [8784.9324] <32> i_bp_sts_close_target_image: cannot write image to disk, media close failed with status 2060019
07:39:08.059 [8784.9324] <2> signal_parent: set bpbrm media ready event (pid = 9316)
07:39:08.106 [8784.9324] <4> report_dedup_stats: StorageServer=PureDisk:MasterServer; Report=PDDO Stats for (MasterServer): scanned: 1065942210 KB, CR sent: 2334601 KB, CR sent over FC: 0 KB, dedup: 99.8%, cache hits: 0 (0.0%)
07:39:08.106 [8784.9324] <2> job_monitoring_exex: ACK disconnect
07:39:08.106 [8784.9324] <2> job_disconnect: Disconnected
07:39:08.106 [8784.9324] <2> job_connect: SO_KEEPALIVE set on socket 840 for client MasterServer
07:39:08.106 [8784.9324] <2> logconnections: BPJOBD CONNECT FROM xx.xx.xx.xx.57920 TO xx.xx.xx.xx.13723 fd = 840
07:39:08.106 [8784.9324] <2> job_authenticate_connection: ignoring VxSS authentication check for now...
07:39:08.106 [8784.9324] <2> job_connect: Connected to the host MasterServer contype 53 jobid <3094> socket <840>
07:39:08.106 [8784.9324] <2> job_connect: Connected on port 57920
07:39:08.122 [8784.9324] <2> job_monitoring_exex: ACK disconnect
07:39:08.122 [8784.9324] <2> job_disconnect: Disconnected
07:39:08.122 [8784.9324] <32> bp_sts_close_target_server: sts_close_server failed: error 2060005
07:39:08.137 [8784.9324] <2> ConnectionCache::connectAndCache: Acquiring new connection for host MasterServer, query type 161
07:39:08.137 [8784.9324] <2> logconnections: BPDBM CONNECT FROM xx.xx.xx.xx.57921 TO xx.xx.xx.xx.13721 fd = 1416
07:39:08.137 [8784.9324] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:871] Ignoring VxSS authentication 2 0x2
07:39:08.215 [8784.9324] <2> db_end: Need to collect reply
07:39:14.689 [8784.9324] <2> send_MDS_msg: MEDIA_DONE 0 -1370659220 0 @aaaac 0 0 {5D116E9A-2DAB-446D-B9AA-88B7F9DFBF0B}
07:39:14.689 [8784.9324] <2> packageBptmResourceDoneMsg: msg (MEDIA_DONE 0 -1370659220 0 @aaaac 0 0 {5D116E9A-2DAB-446D-B9AA-88B7F9DFBF0B})
07:39:14.689 [8784.9324] <2> packageBptmResourceDoneMsg: keyword MEDIA_DONE version 0 jobid -1370659220 copyNum 0 mediaId @aaaac mediaKey 0 unloadDelay 0 allocId {5D116E9A-2DAB-446D-B9AA-88B7F9DFBF0B}
07:39:14.689 [8784.9324] <2> packageBptmResourceDoneMsg: returns 0
07:39:14.689 [8784.9324] <2> JobInst::sendIrmMsg: returning
07:39:14.689 [8784.9324] <2> mm_terminate: EXITING with status 87
07:39:14.689 [8784.9324] <2> bp_sts_close_server: STS session not initialized
07:39:14.689 [8784.9324] <2> cleanup: Detached from BPBRM shared memory
 

Highlighted

Just an update, I reduced the

Just an update, I reduced the amount of data backing up by 50% and it completed first time backup.

D:\AppsData was ok

E:\CorpData was ok

D:\UserData (currently removed)  around 700GB

once the SLP finishes I will look at re-adding it.

 

Highlighted
Accepted Solution!

Ah if that is the case you

Ah if that is the case you may want to try increasing your client read timeouts and see if it gives you enough time to complete the backup.

 

If you have any other questions please let me know.

Thanks

View solution in original post

Highlighted
Accepted Solution!

Do you have the \program

Do you have the \program files\veritas\netbackup\db\config\DPS_PROXYDEFAULTRECVTMO file in place - if so what setting does it have?

If not please create this on your Master / Media Servers and add a value of 800 into the file

This helps keep the disk pool up and happy at very busy times when the Master could believe it has problems

I always use this setting for any de-dupe or enterprise disk setups (but none of the other DPS_ file though)

Hope this helps

View solution in original post

Highlighted

Good catch Mark that is

Good catch Mark that is another possibility.

Highlighted

A Quick update. Removing the

A Quick update. Removing the Userdata from the backup I created a new policy with just the userdata in it and again the job has failed with error 87.

 

Brook: Currently its 300 so will increase to 600

Mark: No I dont have that file there. I run many netbackup servers and havent needed it this far but will create it now and see how it goes. I have been backing up this server during the day when nothing else has been backing up trying to get it working so I dont think the pool is very busy.

thanks for help Smiley Happy

Highlighted

OK - well worth having it in

OK - well worth having it in place anyway!

Another thing that can help is your storage unit fragment size. If this is a very large backup running on its own then the fragment size of the image could potentiall get very large.

It sometimes helps to have a smaller one (helps with restores, duplications and GRT as well) - this not only keeps it neat it forces regualr communication as each fragemnt gets closed off so can help with any timeout issues (likewise the checkpoint re-start option)

Hope this helps

Highlighted

As far as the client read

As far as the client read timeout. On some of my systems especially for large backups you have to allow the client time to walk the os and find all the files as well as sending the file list back to netbackup If you are using accelerator then it is like doing a full in this aspect. During this time if there is a large ammount of data with many files the client will time out talking to NBU.

In my cases I end up with client read timeouts of more like 3200 or 6400. Occasionally I have seen them as high as 10200 or maybe 11,200.

At any rate you should know if it takes longer for the backup ot fail.

 

Thanks

Thanks again for the

Thanks again for the suggestions. I did

1. Cleaned up 200GB of Data to reduce the size

2. Increased Time outs to 600/600

3. Created the touch file DPS_PROXYDEFAULTRECVTMO with the 800 value

and the backups are now working. I did all three at the same so not sure which exactly fixed it so I have marked a split solution. Thanks again for the help.

Best regards