06-30-2014 09:54 AM
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)
Solved! Go to Solution.
07-02-2014 06:54 PM
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.
06-30-2014 10:31 AM
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..
06-30-2014 10:47 AM
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
06-30-2014 10:55 AM
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.
06-30-2014 10:59 AM
Hi sri vani,
Yes, saw that too and done that but to no help.
Sorry, I should've mentioned what we did.
06-30-2014 11:14 PM
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.
07-01-2014 10:13 PM
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).
07-02-2014 06:54 PM
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.
07-02-2014 07:26 PM
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:
07-16-2014 12:37 AM
Just a quick update: upgrading the clients to the same NBU level as the Master/Media server fixed the issue. Thanks everybody!
07-16-2014 01:25 AM
Thanks for the update...