Forum Discussion

Spud_2's avatar
Spud_2
Level 3
10 years ago

Status 2060019 and status 87 Killing same job

Got following errors in our details on a solaris backup. Im on an appliance, 5220. We are running 7.6.1.1. Link to 2060019 in error message is a cyclical redirect. I saw in other posts that this was a problem in the pre 7.5.0.4 world, but was supposed to be fixed in 7.5.0.5. Which is not our experience. Is there are work around for this? Anyone else seen it in the post 7.6.1.1 version?



​05/10/2015 00:56:17 - Critical bptm (pid=4960) Storage Server Error: (Storage server: PureDisk:servername) mtstrm_close_write_channel: Fatal error occured in Multi-Threaded Agent: Close Write Channel command failed: Cr_ErrnoException: Timed out after waiting 180s for the read threads to complete (cnt=1) V-454-96

05/10/2015 00:56:17 - Critical bptm (pid=4960) sts_close_handle failed: 2060019 error occurred on network socket


05/10/2015 00:56:17 - Critical bptm (pid=4960) sts_close_handle failed: 2060019 error occurred on network socket


05/10/2015 00:56:17 - Error bptm (pid=4960) cannot write image to disk, media close failed with status 2060019


05/10/2015 00:56:17 - Info bptm (pid=4960) EXITING with status 87 <----------

 

Thanks in advance.

 

 

Agents
Backup and Recovery
Configuring
Error messages
Features
Linux
NetBackup Appliance
Recovering
  • Spud_2's avatar
    Spud_2
    Level 3
    10 years ago

    I also can not kill the job from the java console.  Looks like we are heading to a reboot.

  • Marianne's avatar
    Marianne
    Level 6
    10 years ago
    See this TN : Status 87 and Status 40 on long running Client side deduplication jobs across a slow connection http://www.symantec.com/docs/TECH206337
  • D_Flood's avatar
    D_Flood
    Level 6
    10 years ago

    Since this is Solaris and not Windows it probably isn't the same issue but I've seen those exact error numbers for Windows boxes when the client is an older (but supported) version than the destination Media Server and the backup was configured to use client-side-dedup over the LAN (not WAN so link speed wasn't an issue).  I really saw this when I jumped my Media Server Appliances from 2.6.0.2 to 2.6.1.1 and the clients were still running 7.5.0.7.

    Disabling client-side-dedup always seemed to "fix" the errors but isn't a good option...

    As soon as I upgraded the client (I was lucky, none of the boxes were User Controlled boxes so the approval process was short) to the same version as the Media Server, backups with client-side-dedup enabled started working right again..

    It seems that the "backwards compatibility list" only applies when using basic backups, not any special features like client-side-dedup.