cancel
Showing results for 
Search instead for 
Did you mean: 

Library issue with tapes not ejecting from a drive at the end of a job

Mj2
Level 2

I have a library issue with tapes not ejecting from a drive at the end of a job (successfull or not). The environment consists of, one robot and 2 drives (no other library's at this particular location). NBU will load tapes, but when a job's complete it doesn't seem to unload them. When the next job starts, the drives are brought off line because, (and I'm assuming here) the library's trying to load a tape and there's one already loaded.

From with in the library web interface if i move the tape from a drive to a slot and bring the drives on line in NBU, then everything run's as normal until......

Is there an idle time setting for tape drives to unload after X amount of unused time?

Other Suggestions?

8 REPLIES 8

Marianne
Level 6
Partner    VIP    Accredited Certified
This sounds like a device config mismatch.

Please show us output of these commands from cmd (....\volmgr\bin):
tpconfig -l
scan

If all checks out fine, please add VERBOSE entry in vm.conf ( in volmgr) and restart NBU Device Management service.
Next time you see the issue, check Event Viewer Application log.

RamNagalla
Moderator
Moderator
Partner    VIP    Certified

could you confirm if next job is trying to use the same drive with different media ID than the one already in Drive?

you can confirm this by looking into the next job details status and looking for allocated drive and tapes IDs.

it is possible that the netbackup is aware of the tape in drive and allocating the same Tape for next job  and drive went down for some other reason & it is also possible that netbackup is not aware that there is no tape in Drive and allocated another tape.

we need to make sure which one is true in your case..

Genericus
Moderator
Moderator
   VIP   

Q. Is there an idle time setting for tape drives to unload after X amount of unused time? 

A. YES 

BUT - this should not be your issue, because NetBackup is aware of this and would not try to load another tape, since the drive/media combination are still allocated.

Host properties - Master Server - Media - "Media unmount delay:" - default is 300 seconds. 

 

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

Genericus
Moderator
Moderator
   VIP   

If you are interested/VERY CAREFUL! - look at the output of "nbrbutil -dump"

You watch and see what NetBackup does with drive and media allocations, once the job is done, a process to unload the media is created.

This is something to be aware of in case of a crash - nbrbutil -dump can show you media still allocated that may need to be manually unloaded, and should be compared against your scan of the robots, to see what remains loaded.

If you run the command, and see this, and you have tapes loaded - you have issues!

# nbrbutil -dump

Allocation Requests
(AllocationRequestSeq )


Allocations
(AllocationSeq )

MDS allocations in EMM:

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

Marianne
Level 6
Partner    VIP    Accredited Certified
@Mj2

Have you seen attempts to help you?

@Mj2

What kind of tape & tape drives are you using ?

Have seen something similar with some of the early capacity tapes, where the problem was the tape was still rewinding when Netbackup send the unload command. Can probably be seen in your libary's logs if that is the case.

Pretty sure there was a setting or touch file that solved it, just can't remember exactly what. 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

Yea it's a Quantum i40 LTO4. I've been seeing some drive error's saying something about bad format on tape but i get the same error with new and previously mounted LTO4's, but the job would still run.

Just yesterday the picker died so i'm having the 2 (of a total of 2) drives and the system board replaced. I guess we'll see if it was a hardware issue.

more later......

Yea sorry i didnt see the updates so i didnt think anyone was responding. I've just seen them now.