cancel
Showing results for 
Search instead for 
Did you mean: 

Basic Disk Staging to tape only puts 2 clients backups on the first tape and hangs with manual relocation

jmp242
Level 3

I have netbackup 7.5 on a EL6 server. I have a 15TB basic disk storage unit. I have two LTO4 drives connected. I'd like to move a set of monthlies from the storage unit to tape such that I could still restore from tape via NetBackup if needed. I tried to enable staging via the checkbox on the disk storage unit. I then put in a tape in one of my drives and kicked off a manual relocation to final destination. It worked fine for 2 netbackup clients, and then hung asking for intervention. I found out it wanted me to put a tape in the second tape drive. I think I fixed this by saying to only use one write device on the tapes.

 

The current issue is that it doesn't seem to be filling up the tapes - it's putting 100G from one client and say 50 from the next and then wanting a new tape. This is incredibly wasteful and we cannot use up tapes this way when they are 1.6TB tapes... Google searches and reading the docs have failed me so far...

 

What am I missing?

6 REPLIES 6

jmp242
Level 3

One piece of additional information - it seems like the tapes are set as HCART2 devices. We're currently trying them as HCART3 devices - but I'm not sure if this is a tape capacity / density mismatch issue...

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Please enable bptm log on media server doing duplication.

Please also double-check retention level on original backups - are they all the same or different?
NBU does not mix retention levels on media. This can be changed, but is NOT recommended (solves media usage in the short term but more headaches long term - all images need to expire before media can be re-used/overwritten).

Are you using Standalone drives or drives in a robot?

Changing densities will create more problems rather than solving anything.
Previously written media cannot be re-used.

mph999
Level 6
Employee Accredited

Further to Mariannes outstanding post ...

Desity, hcart, hcart2 etc ... is very very misleading,  NBU has no understanding of density at all, it doesn't even know when a tape is full.

The 'density' is only a 'label'  - an hcart2 tape can only go in an hcart2 drive etc ..  If I wanted, I could gie LTO5 drives the density of 4mm and they will still wok as LTO5 drives (and tapes).  You might as think of he density as red, green, blue ... a red tape will only be allowed in a red drive and so on.

The only requirement, is that he tape has the same density as the drive - it doesn't matter what that density is - it could be 'Micky Mouse' for all the difference it makes.

Are these tapes being marked as Full ?  Use bpmedialist -m <media id> to check.

If they are, you have a drive or firmware issue.  NBU would write to the same drive for ever, as mentioned, it has no abilty to understand tape capacity or mark a tape as full.

When a tape really is full, this causes the tape drive firmware to set a 'flag' in the tape drive driver.  When NBU trys to send more data, it is not allowed, and the tape driver passes the message the tape is full to NBU.  This is how NBU knows to load a new tape.

Therefore, tape capacity issues are outside of NBU.  There is nothing from the NBU side that can be done, it WILL be a faulty drive, driver or firmware issue.  

Note, this last section of my post only applies if the tapes are being marked full.

Martin

jmp242
Level 3

I'm seeing:

 

./bpmedialist -m A00004
Server Host = lnxnb7

id rl images allocated last updated density kbytes restores
vimages expiration last read <------- STATUS ------->
On Hold
--------------------------------------------------------------------------------
A00004 15 3 05/11/2012 11:08 05/11/2012 11:18 hcart2 81165792 0
3 INFINITY N/A
0

Not sure how to tell if it's marked as full from this.

Moreso, after changing to HCART3 it's duplicating far more data than as HCART2, albeit randomly - it will succeed for one job, fail 3, succeed a job, fail some more - and all failures are code 96... Which implies it ought to ask for a new tape (except the current tape *isn't* full, as it's later on adding more data to it in a later job...

 

This makes NO sense.

mph999
Level 6
Employee Accredited

That tape is not full - discount that part of my post ...

The density has no effect - if you see a change it is coindence, as you say - randomly.

Think we might need to look in the logs.  If (as Marianne suggested) you could get the bptm log from the media server and the details from the Activity monitor for the job (from details tab).

Thanks,

Martin

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Changing drive density will require new, unassigned hcart3 media. NBU will NOT append to hcart2 media if drive is hcart3. This is probably causing status 96.
Drive, media and Storage Unit densities MUST match.

Please also remember to tell us about original backup jobs - are they all the same retention level or different?

Can we assume that the master server is also the media server?
If that's the case, please ensure that both these log folders exist (in /usr/openv/netbackup/logs):
admin and bptm

This Technote is probably still valid for NBU 7.5 and explains how disk staging relocation (duplication to tape) is 'batched' into separate duplication jobs:

http://www.symantec.com/docs/TECH44719