Forum Discussion

S_Williamson's avatar
S_Williamson
Level 6
12 years ago

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

7.5
Backing Up
Backup and Recovery
NetBackup
Troubleshooting
Windows Server (2003-2008)
  • Brook_Humphrey's avatar
    Brook_Humphrey
    12 years ago

    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

  • Mark_Solutions's avatar
    Mark_Solutions
    12 years ago

    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

11 Replies

Sort By
  • S_Williamson's avatar
    S_Williamson
    Level 6
    12 years ago

    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

     

  • Dyneshia's avatar
    Dyneshia
    Level 6
    12 years ago

    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

     

  • S_Williamson's avatar
    S_Williamson
    Level 6
    12 years ago

    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=PureDisk:SERVER; 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)

  • S_Williamson's avatar
    S_Williamson
    Level 6
    12 years ago

    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
     

  • S_Williamson's avatar
    S_Williamson
    Level 6
    12 years ago

    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.

     

  • Brook_Humphrey's avatar
    Brook_Humphrey
    Level 4
    12 years ago

    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

  • Mark_Solutions's avatar
    Mark_Solutions
    Level 6
    12 years ago

    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

  • S_Williamson's avatar
    S_Williamson
    Level 6
    12 years ago

    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 :)

  • Mark_Solutions's avatar
    Mark_Solutions
    Level 6
    12 years ago

    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