backup failing with status 84 and drives went down as well

[manish331]

Hi,

I just configure Netbackup cluster master server  with three media servers and total 16 drives.

OS is Linux 6.2, Netbackup version 7.5.

WhiI testing backup of media and maser server, i am facing two issues.

1. All backups goto Tape drives are failing with EC-84. In between few streans completing.

I tired with multi streaming or without mulit streaming. but rersult is same.

03/26/2014 14:30:33 - positioning 000006 to file 17
03/26/2014 14:31:50 - Error bptm (pid=27701) cannot write image to media id 000006, drive index 4, Device or resource busy
03/26/2014 14:31:50 - Error bpbrm (pid=27699) from client NBU-n2: ERR - Cannot write to STDOUT. Errno = 104: Connection reset by peer
03/26/2014 14:31:50 - positioned 000006; position time: 0:01:17
03/26/2014 14:31:50 - begin writing
03/26/2014 14:31:51 - Info bptm (pid=27701) EXITING with status 84 <----------
03/26/2014 14:31:51 - Info bpbkar (pid=13569) done. status: 84: media write error
03/26/2014 14:31:51 - end writing; write time: 0:00:01
media write error  (84)

2. Tape drives went down frequently.

I reconfigure drives 3-4 time with device configuration wizar or with command line. But result is same.

We are useing Data domain with same domain  as well. But i am not seeing any backup issue there.

[Will_Restore]

Device or resource busy

Sounds like something wrong at the OS level.  Check messages file and dmesg output for clues.

[manish331]

drives configuratio n is like :

I configured 5 drives with each media server and 1 drive configure  among cluster nodes.

[manish331]

Also intailly it is backup jobs failing with error 2009. So reconfigure drives.

03/23/2014 10:07:04 - Error nbjm (pid=40115) NBU status: 2009, EMM status: All compatible drive paths are down, but media is available
All compatible drive paths are down but media is available  (2009)

[mph999]

Device was busy, odd, as this happens after the tape was positioned ... Maybe something outside NBU affecting this, not sure based on what we know so far, but wr's idea is good.

bpbrm log pid 27699 would be interesting to see ...  it might not hold the complete story, but you have to start somewhere, in fact, please attach both the bpbrm and th bptm log for a failed backup (pref at verbose 5)

This could all be irrelevant, as it apppears to recover and start to write, but only for 1 second - bptm log will show more details.

[manish331]

buffer setting resolve issue.

[Marianne]

Really? 

And how exactly did you figure that out? 

Did you enable bptm log? 

Did it show that buffer size was bigger than the size supported by tape driver and/or OS?

[manish331]

no, i just half buffer size.

[mph999]

I'm a bit surprised as well.  What was the original buffer size ?

If the buffer size is above a certain size, you can get failures, but 'modern' hardware can cope with 262144 (a common value that usually works for most perople) or even 524288.

What I'm trying to get to, is that failures due to buffer size are less common these days which is why we're a bit surprised.

M