Video Screencast Help

How does NetBackup choose which active tape to use

Created: 22 Nov 2010 • Updated: 28 Oct 2013 | 15 comments
This issue has been solved. See solution.

NetBackup 6.5.5, RHEL4.7.

I'm trying to figure out how NetBackup will choose which tape to write to.  I've looked at article HOWTO32854 (About selecting media in robots on UNIX/Linux), and the section in the admin guide II "About selecting media in robots on UNIX/Linux" (both the same content, it appears), but they appear to be incomplete to me.  Specifically I'm looking to find out which of several active, unmounted tapes currently in the robot get chosen.

The docs say that first a mounted tape is looked for, then the media catalog is checked - but all it says is that if a suitable volume is found, it is used.  What if several suitable volumes are found?  Now does NBU decide?  It doesn't appear to be least recently used, nor numeric order.

What I see is that I have 5-7 active tapes is a specific volume pool at a certain retention level.  A backup starts, calling for the pool and retention level matching the active tapes, and NBU seems to be shunning certain media.  One of the tapes has been sitting idle for a month, while other tapes get written to and new tapes are brought into the pool (the new tapes are for images spanning media, so I understand whey new tapes are brought in instead of using active tapes). 

Can anyone offer any insight?


Comments 15 CommentsJump to latest comment

Andy Welburn's picture

But, the tape that appears to be getting "shunned" - is it frozen or suspended?

Is it the correct retention period? (probably, looking at your post)

Has it expired (NOT the data, the physical expiry)?

Is it the correct density? (again probably ok as already written to!)

Could you poost the output from bpmedialist (sorry can't remember exact syntax as haven't got resources available at the mo, but it probably involves -media media_id and -U !)

Marianne's picture

Do you have different media servers? If so, have you enabled media sharing?

Media sharing is not enabled by default. Once a tape is 'assigned' to a media server, only that media server can append to it. So, when media is evaluated to be appended to, NBU will first of all look for suitable media that currently belongs (assigned) to the particular media server.

When the documentation says "NetBackup searches the media catalog ...." it still uses old terminology from pre 6.x days when each media server had its own media catalog (mediaDB). Although all of these mediaDB's have been moved to the EMM database, media ownership is still kept separate for each media server, unless you enable media sharing.

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

bills's picture

Andy - the tape is not frozen or suspended, is the right retention, density, etc.  The volume expiry is not set.  There should be no reason not to use the tape.

root@mnemosyne:/usr/openv/netbackup/logs/bptm# bpmedialist -m LT0142
Server Host =

 id     rl  images   allocated        last updated      density  kbytes restores
           vimages   expiration       last read         <------- STATUS ------->
LT0142   8      2   10/25/2010 08:40  10/25/2010 08:44   hcart    14524384     0
                2   10/25/2011 08:44        N/A       

root@mnemosyne:/usr/openv/netbackup/logs/bptm# vmquery -m LT0142
media ID:              LT0142
media type:            1/2" cartridge tape (6)
barcode:               LT0142
media description:     Added by Media Manager
volume pool:           NetBackup (1)
robot type:            TLD - Tape Library DLT (8)
robot number:          2
robot slot:            211
robot control host:
volume group:          000_00002_TLD
vault name:            ---
vault sent date:       ---
vault return date:     ---
vault slot:            ---
vault session id:      ---
vault container id:    -
created:               Fri 25 Jun 2010 05:01:15 PM MDT
assigned:              Mon 25 Oct 2010 08:40:45 AM MDT
last mounted:          Mon 25 Oct 2010 08:37:17 AM MDT
first mount:           Mon 05 Jul 2010 09:53:46 PM MDT
expiration date:       ---
number of mounts:      29
max mounts allowed:    ---
status:                0x0

Marianne - I only have the one media server, but you bring up a good point!


Marianne's picture

How many robots in this environment?

How many Storage Units?

STU in policy config?

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

bills's picture

Three robots and  three storage units.  Relevant policies/schedules point to the storage unit in question, which is robot #2.  All the active tapes I've mentioned are in the same pool, the same retention, the same robot.  The pool is the generic NetBackup pool, so many different policies use it.

Andy Welburn's picture

- that's what I thought  it was supposed to be. It says the following in the Admin Guide (but I think it is actually referring to which unassigned tape it picks):

"...If more than one volume qualifies, NetBackup chooses the volume that was least recently used..."

The only thing I can think of is if your backups using this volume pool go 24/7 (unlikely?) - I've also found that NB will not continue a backup on partially full media, rather assign a new one to the volume pool & use that as you originally stated.

Maybe consider using the setting "maximum number of partially full media" or just let that particular media retire gracefully & hope it doesn't get replaced with another that doesn't want to be written to!

bills's picture

Andy - I agree with you on "least recently used" - I think that it is referring to unassigned media.

I've though about tweaking the "max partially full" option, but wanted to see if I could get a grasp on how NBU was working before playing around with it.  The pool isn't in use 24/7, but during our backup window there would be several policies running that would use it - so I'm worried that reducing the number of partially full tapes allowed would impact the backups - queue them waiting for resources.

Also, you are right about selecting new media when spanning tapes - I found this somewhere with the rationalization that if you are spanning tapes, you're writing a big data set, so it makes the assumption that you'll fill up the next whole tape as well.  Not sure if I completely agree with the logic, but it is a behaviour that I've tracked in this case.


Andy Welburn's picture

The only reason I mentioned the 24/7 was on the off-chance that if this was the case your partially full media might not get the opportunity to be utilised, but it looks like that probably isn't the case.

We had the annoying case where we always had one too many partial tapes due to the backups spanning tapes "issue" - they would get used eventually, but another would always take it's place! We just ended up removing the 'extra' one until it expired - it wasn't an issue in & of itself, just annoying, or is that just the OCD in me!

Can't explain why you should have one (or two or more) partially full that never get filled - stumped!

bills's picture

Maybe a little OCD - but come on, that's what makes us good admins...

In my case we send tapes offsite once they are full.  Having the tape sit around for a month not getting written to means it never goes offsite, which breaks what little DR endeavours we practice...

Andy Welburn's picture

Why only send them offsite when they're full? As you say, if it's sitting around on-site for any length of time.....but then again, maybe it's backed up again & lucky to be on a full tape?

Ours go offsite once per week irrespective, including associated catalog backup (if the oppos remember!).

bills's picture

For good or bad, we've never really addressed DR from a data point recovery standpoint in the event of a site incident (data center goes away, etc).  (Actually the bosses never really seem to be willing to address DR of any kind).  We send tapes offsite once they are full to minimize the cost of offsite storage as well as media.  The theory was that tapes, once written to, would fill up in a reasonably short amount of time and get offsite - but in this case, it is definitely possible that the data has been backed up again and gone offsite.

Zahid.Haseeb's picture

Hope the below post may help you

Any comment will be appreciated. Mark as Solution if your query is resolved
Thanks in Advance
Zahid Haseeb

bills's picture

Yes, this post is basically verbatim of HOWTO32854 (About selecting media in robots on UNIX/Linux), and the section in the admin guide II "About selecting media in robots on UNIX/Linux", both of which I referenced in my original post.  The data here seems to be incomplete, as it does not address how NBU chooses between several active tapes that meet the search criteria of pool, retention, density, etc.

bills's picture

In case anyone else is interested, it appears to be most recently assigned, based on the (extensive) tests that I had to run.  Symantec support, after talking with the engineers, could not provide details "as it can change without notice."

The problem I run into is that, in policies that use this tape pool, there are many large jobs which span media.  NBU will pull a fresh tape to continue a backup that is spanning media - I understand this.  When the large jobs finish, they always leave partially full media - with newer assign times than any other partially full media (like the one that has been sitting out there for 2 months now).  This pattern continues until, by some cosmic alignment, all the newer media are in use when another job kicks off, which will then use the "old" tape before assigning a new one.

I will post back if I find a way to circumvent this, though by the looks of it I'm the only once concerned.  Thanks all for your feedback.


Will Restore's picture

anybody remember 'the fickle finger of fate'?

Will Restore -- where there is a Will there is a way