Forum Discussion

kybeer's avatar
kybeer
Level 5
11 years ago
Solved

error 87: media close error / accelerator / full backup

Hi

On one specifc Accelerator-enabled (Standard) Policy I get:

Critical bptm(pid=11100) sts_close_handle failed: 2060017 system call failed       
Error bptm(pid=11100) cannot write image to disk, media close failed with status 2060017 

Starting two weeks ago the Full backup schedule always get that error. The Differential Incremental schedule always work fine. The error occures after the backup data transer is completed. No changes were made prior to that, configuration or version upgrade.

I don't have any storage issues on the RAID-level, and all other Policies (about 30) work fine.

Netbackup server is 7.5.0.5 on Win2008R2. Client with the issue is CentOS6, v. 7.5.0.6

any ideas?

cheers

johan

 

7.5
Backing Up
Backup and Recovery
Error messages
NetBackup
Troubleshooting
Windows Server (2003-2008)
  • Marianne's avatar
    Marianne
    11 years ago

    Probably best to log a Support call.

    Symantec Support will probably need level 5 bptm and bpdm logs as well as other MSDP logs.

    I found references to corrupt images that were related to disk full condition on the MSDP volume. I do not see any reference here.
    Other TNs described bugs in older NBU and PureDisk versions.

    Otherwise, expire the problematic backup image and take another full backup.

    PS:
    Was the problematic image duplicated to tape or other storage?
    Was the duplication successful?
    Have a look at output of:
    bpimagelist -backupid 11111111111111111111_1400389801 -L

8 Replies

Sort By
  • kybeer's avatar
    kybeer
    Level 5
    11 years ago

    No, I don't think it does. Everything is in the same LAN, no firewalls (hardware or software) between server and client, and the backup for this Policy is usually fast; 5-20 minutes.

    The job accually says a correct amount of "current KB written" and "Current files written". But the jobs ends with

    Critical bptm(pid=3384) sts_close_handle failed: 2060017 system call failed       
    Error bptm(pid=3384) cannot write image to disk, media close failed with status 2060017  
    Info bptm(pid=3384) EXITING with status 87 <----------

  • Marianne's avatar
    Marianne
    Level 6
    11 years ago

    Please show us all text in Details tab.

    Is the master server also the dedupe media server? 
    Do you have bptm log enabled on media server?

    Any kind of dedupe performance tuning done?

    Please see tuning suggested by Mark in this discussion (where the post marked as Solution is not making any sense): https://www-secure.symantec.com/connect/forums/netbackup-client-side-deduplication-backups-fail-error-87  
    Or maybe changing worker threads to 128 solved the issue - the OP didn't say!

  • kybeer's avatar
    kybeer
    Level 5
    11 years ago

    Hi,

    Yes, the master and media server is the same machine.

    Yes, I have three log files in log\bptm. 051814_00001.log should be for the correct date. I'm cheking for the matching time, and image-file (1400389801). One suspicious entry I find is (I have replaced the hostnames with 11111...):

     

    07:13:29.415 [3384.9808] <16> 67413:bptm:3384:11111111111111111111: [ERROR] PDVFS: pdvfs_fcache_flushfile: file 11111111111111111111_1400389801_C1_F1.img now marked CORRUPT

    Please see bptm.log

     

    Maybe I need to do a new complete full backup of this policy?

     

    The only tuning is the recommended setup steps from Symantec when installing MSDP.

    The worker thread is 64 atm

    Please see details.log for Job log.

     

  • Marianne's avatar
    Marianne
    Level 6
    11 years ago

    Probably best to log a Support call.

    Symantec Support will probably need level 5 bptm and bpdm logs as well as other MSDP logs.

    I found references to corrupt images that were related to disk full condition on the MSDP volume. I do not see any reference here.
    Other TNs described bugs in older NBU and PureDisk versions.

    Otherwise, expire the problematic backup image and take another full backup.

    PS:
    Was the problematic image duplicated to tape or other storage?
    Was the duplication successful?
    Have a look at output of:
    bpimagelist -backupid 11111111111111111111_1400389801 -L

  • kybeer's avatar
    kybeer
    Level 5
    11 years ago

    Yes, logging a case is probably the best idea.

    No, the problematic image was not duplicated, I can't see it under "Catalog / Duplicate". The latest succesful image of that shedule was duplicated succesfully though.

    The fastest way might be to expire the full backup and run a new? That would start from scratch I guess? I assume that force rescan won't help in this case.

  • kybeer's avatar
    kybeer
    Level 5
    11 years ago

    I expired the working full backup of the affected policy and ran a new full backup. It worked fine. After that I could run both incr and full "accelerator" again (that 2nd full accelerator backup was giving me error 87 before).

    To me it feels like a bug, that the full backup image got corrupted, since the other jobs were working, no full disks and no RAID issues.

  • Marianne's avatar
    Marianne
    Level 6
    11 years ago

    You will only know if you log a call with Symantec Support and allow them to investigate.

    With the corrupt image expired, you will never know....