Video Screencast Help

Differential backup fails , full backup successful

Created: 02 Jul 2012 | 6 comments
NBU client linux 2.4 NBU
Media server OS windows 2008 , NBU version
backup failure error code 84 , only for 4 mount points u1 u2 u3 u4. It fails after 11 hrs approx n shows 32KB and throughput as zero
backup happeneing onn disk , datadomain
It is happening on 1 client only
Differential backup failing full backup is successful
It use only 1 media server

Comments 6 CommentsJump to latest comment

Mark_Solutions's picture

sounds like the client is struggling during the read of the file system to establish which files have changed for the incremental backup

If nothing else upgrade it to 6.5.6 ( if the client supports it)

Set up bpbkar and bpcd logging on the client and bpbrm on the Media Server to see where it goes wrong - but it sounds like it may have hit its stumbling block well before the 11 hour mark so check the client for errors during that period

Hope this helps

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Marianne's picture

In addition to Mark's excellent post (Hi Mark!) one more log, please:

bptm log on media server.

Please rename logs to reflect process name (e.g. bpbkar.txt) and post logs as attachments.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

RonCaplinger's picture

There is a time limit on the Data Domain mount that can cause status 84's; older versions of the DDOS code had it at 60 minutes (I think), newer versions of 3 hours, and that can be adjusted by your EMC/Data Domain tech support folks.  I don't think they ever got around to makeing it user-configurable.

EDIT: Found my notes, the parameter is "OST_ABANDON_TIMEOUT= X (where X is the pause time in seconds)". 

If your DDOS version is less than 5.1.x, you should upgrade that first.

If your incrementals are really taking 11 hours before NBU is ready to write data, it would be advisable to break that file system up somehow.  One of the ways we had to get around this was to create multiple policies to do full backups on different parts of that file system on different days and incrementals the rest of the time.

If that's not possible, and are using a recent DDOS version, check with EMC support to have them increase the timeout for you.  It requires them to enter SE mode on the Data Domain in question and adjust the value manually.

rookie11's picture

Hi Ron 

OST_ABANDON_TIMEOUT=  is set as 9 hrs

DD os is at latest OS patch

RonCaplinger's picture

Your timeout is set to 9 hours, but your backup runs for 11 hours before it tries to write something.  Since the DD abandoned the mount at 9 hours, you get a status 84 "media write error" because NBU can't write the data.

If you can set the abandon to 12 hours, I'll bet that job will complete.  The downside of setting the abandon timeout so long is that a failed backup will likely tie up an available stream to the Data Domain until that timeout occurs, potentially leaving you with fewer streams to use for actual data.  If your DD can support, say, 30 streams, and you somehow have a backup stream failure that doesn't notify the DD that it actually failed, you could only have 29 data streams for the next 12 hours.

Marianne's picture

Please post all text in job details as well as logs requested earlier.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links