cancel
Showing results for 
Search instead for 
Did you mean: 

Status code 87 After Upgrade to 7.6.0.2

Hi Team,

We really need your help regarding this issue. When the scheduled jobs kicked off, they go to Incomplete status, and then fail after the 3rd try, status code 87. The recent change to the setup was an upgrade from 7.5.0.6 to 7.6.0.2 of the Master server, which is the media server too.

Details of the error:

6/30/2014 9:01:52 PM - Info bpbkar32(pid=3796) accelerator sent 49664 bytes out of 477716186112 bytes to server, optimization 100.0%

6/30/2014 9:01:52 PM - Info bpbkar32(pid=3796) bpbkar waited 0 times for empty buffer, delayed 0 times.  

6/30/2014 9:11:49 PM - Critical bptm(pid=8024) sts_close_handle failed: 2060017 system call failed      

6/30/2014 9:11:49 PM - Critical bptm(pid=8024) cannot write image to disk, media close failed with status 2060017 

6/30/2014 9:11:49 PM - Info Master/MediaServerFQDN(pid=8024) StorageServer=PureDisk:Master/MediaServerFQDN; Report=PDDO Stats for (Master/MediaServerFQDN:( scanned: 51202217 KB, CR sent: 1464 KB, CR sent over FC: 0 KB, dedup: 100.0%, cache hits: 0 (0.0%)

6/30/2014 9:11:49 PM - Critical bptm(pid=8024) sts_close_server failed: error 2060005 object is busy, cannot be closed  

6/30/2014 9:11:52 PM - Info bpbkar32(pid=3796) done. status: 87: media close error      

6/30/2014 9:11:52 PM - end writing; write time: 0:10:33

media close error(87)

1 Solution

Accepted Solutions
Accepted Solution!

I have upgraded two sites so

I have upgraded two sites so far 7.5.0.6 to 7.6.0.2. First one was a Master with 2 Media servers where the MSDP was on a media server and we did not see error 87 at all.

The next site is a single Master/Media with MDSP and after upgrading to 7.6.0.2 we have 4 servers (out of 30) with error 87's. These were the ones with the largest backup sets (File/Print/Home drives) .

I reran the backups initially to see if they would finish correctly which all four didnt. All our servers are set to "Prefer to use client-side deduplication". I didnt set to backup direct to media server as some of these clients are also on slow WAN links.

After upgrading the client version from 7.5.0.6 to 7.6.0.2 all the backups reran without error. This seems to be the simple fix to get them working again. As it doesnt require a reboot I was able to do it in business hours.

View solution in original post

10 Replies

Critical bptm(pid=8024)

Critical bptm(pid=8024) sts_close_server failed: error 2060005 object is busy, cannot be closed  

by any chance did you look into below tech note

http://www.symantec.com/business/support/index?page=content&id=TECH168898

even the end status code is different in the T/N , it shows the same error  that you got..

I see a related  TN for same

I see a related  TN for same 87

Critical bptm (pid=5186) sts_close_handle failed: 2060017 system call failed

please have a look at it

http://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=&id=TECH206337

Hi Nagalla, Thank you for

Hi Nagalla,

Thank you for your reply. No, I haven't seen that TN, and I'm not sure if that will be an appropriate thing to do for our case since we have more than enough space.

Hi sri vani, Yes, saw that

Hi sri vani,

Yes, saw that too and done that but to no help.

Sorry, I should've mentioned what we did.

I am curious about the

I am curious about the upgrade to 7.6.

Did you confirm that MSDP conversion completed successfully after 7.6.0.1 installation before patching to 7.6.0.2?

Conversion process is logged in <storage_path>\log\convert.
Please check this log to confirm that all is good.
 

Hi Marianne, Yes, we have

Hi Marianne,

Yes, we have confirmed that MSDP conversion had successfully completed first before installing 7.6.0.2. There was a window that showed the conversion process, and we also ran a command as per the upgrade guide to check that conversion is finished.

As an update: We tried to disable client-side dedup, have the dedup process back to the media server, ran backups - completed successfully (but painfully slow remote offices backups). With that, we are considering two options:

1. Upgrade all the clients (which we intend to do once we have secured necessary approvals) to same NBU level as the master server, then turn on client-side dedup again.

For this one, is there any documentation stating that client-side dedup is not supported on NBU client software lower than the master server?

2. Remove MSDP, put it back again, and then re-import (as per HOWTO88966).

Accepted Solution!

I have upgraded two sites so

I have upgraded two sites so far 7.5.0.6 to 7.6.0.2. First one was a Master with 2 Media servers where the MSDP was on a media server and we did not see error 87 at all.

The next site is a single Master/Media with MDSP and after upgrading to 7.6.0.2 we have 4 servers (out of 30) with error 87's. These were the ones with the largest backup sets (File/Print/Home drives) .

I reran the backups initially to see if they would finish correctly which all four didnt. All our servers are set to "Prefer to use client-side deduplication". I didnt set to backup direct to media server as some of these clients are also on slow WAN links.

After upgrading the client version from 7.5.0.6 to 7.6.0.2 all the backups reran without error. This seems to be the simple fix to get them working again. As it doesnt require a reboot I was able to do it in business hours.

View solution in original post

Hi S Williamson, Thank you

Hi S Williamson,

Thank you for sharing your experience. At least we have a spark of hope now that this issue will be over when we upgrade the clients.

Just to share a bit more for others who might check this post:

  • All our customer's remote clients are all file & print servers, only 1 client has 500GB dataset (the smallest) the rest are several TBs.
  • All the policies backing them up are set with client-side dedup + accelerator. 
  • For now, we disabled client-side dedup, left the accelerator on - backup runs fine (but takes forever).

Just a quick update:

Just a quick update: upgrading the clients to the same NBU level as the Master/Media server fixed the issue. Thanks everybody!

Thanks for the update...

Thanks for the update...