drive up but not taking backup.

Run robtest command and query the drives in your library(s) and confirm what vmoprcmd is seeing first.

Then maybe have a look at how the drive config for SCSI Reserve is placed.

tpconfig -dl will show you the setting

If no backup is running then my troubleshoot for a drive with tape in drive is Reset Drive.
Last resort is 'vmoprcmd -crawlreleasebyname ...' command

Why do all the drives show mounted tapes?
Are the tapes being dismounted and returned to their proper slot when backups finish?
Doesn't look like it.

hI SIR,

SEE RECENT vmoprcmd -d ds output.many of the drive are  up & these don't have any media              [   shown in robtest & physical checking of  drive ]. 
see below drive are up but not taking any media for backup:-5,7,11,13,15,21
I have already  run crawlreleaseby name comamnd for theese drivesbut problem is same.

root@ggnbkp24 # bash
root@ggnbkp24 # vmoprcmd -d ds

                                  DRIVE STATUS

Drv Type   Control  User      Label  RecMID  ExtMID  Ready   Wr.Enbl.  ReqId
  0 hcart    TLD               Yes   DW0019  DW0019   Yes     Yes        0
  1 hcart    TLD               Yes   DW1042  DW1042   Yes     Yes        0
  2 hcart    TLD               Yes   DW1084  DW1084   Yes     Yes        0
  3 hcart    TLD               Yes   DW1466  DW1466   Yes     Yes        0
  4 hcart    TLD               Yes   DW1042  DW1042   Yes     Yes        0
  5 hcart    TLD                -                     No       -         0
  6 hcart    TLD               Yes   DW1695  DW1695   Yes     Yes        0
  7 hcart    TLD                -                     No       -         0
  8 hcart    TLD               Yes   DW1781  DW1781   Yes     Yes        0
  9 hcart    TLD               Yes   DW0014  DW0014   Yes     Yes        0
 10 hcart    TLD               Yes   DW0121  DW0121   Yes     Yes        0
 11 hcart    TLD                -                     No       -         0
 12 hcart    TLD               Yes   DW1729  DW1729   Yes     Yes        0
 13 hcart    TLD                -                     No       -         0
 14 hcart    TLD               Yes   DW1329  DW1329   Yes     Yes        0
 15 hcart    TLD                -                     No       -         0
 16 hcart    TLD               Yes   DW0475  DW0475   Yes     Yes        0
 17 hcart    TLD                -                     No       -         0
 18 hcart    TLD               Yes   DW1691  DW1691   Yes     Yes        0
 19 hcart    TLD               Yes   DW1928  DW1928   Yes     Yes        0
 20 hcart    TLD               Yes   DW0010  DW0010   Yes     Yes        0
 21 hcart    TLD                -                     No       -         0
 22 hcart    TLD                -                     No       -         0
 23 hcart    TLD               Yes   DW0742  DW0742   Yes     Yes        0
root@ggnbkp24 #

with regd

gaurav

Have you try using reseting the drives with vmoprcmd -reset command? Im sure this is a kind of bug between the drive assignment from the Media Server to the FT Media Server, remeber that always the FT Medias will give priority to the SAN clients and if there is no Drive available for the SAN Client the backup will go through the IP Network, but still that client haves priority. Try disableling the SAN Clients and see how that runs, this is only to isolate the posibility that the SAN Client is related with the issue.

Please let us know.
best regards.

Also remember that for SAN Client or FT Medias there is a special service under the EMM DB who controls all the FC Transports, maybe checkin the VxUL logs on the master for Originator 199 and see for any hanged process that is holding your drives to be release.

If you realy shure that this is reservation issue check if you use SPC-3 (your library should support it):
http://seer.entsupport.symantec.com/docs/314787.htm
In this http://seer.entsupport.symantec.com/docs/images/31... you should select SCSI persis. reserv.
But if you using SAN-client check if you using  6.5.4 version  (SAN client on it is more stable and will be better on 6.5.5)

Hi Gaurav,
It is possible that you have 'orphaned' resource allocation for these drives. Compare vmdareq  & vmoprcmd -d  output with nbrbutil -dump output. Save nbrbutil output to a file and look for MDS allocations. If any of the drives that are not in use have an MDS allocation, release the allocation with 'nbrbutil -releaseMDS <allocation#>'.
Also confirm Storage Unit configuration - how many drives per STU? What is MPX level for each drive?
What does Job Details tab display wrt reason for queued jobs?

i agree with Marianne, 'nbrbutil -releaseMDS <allocation#>' should work or else  in a final go use nbrbutil -resetAll

resrart the Robot/drive
restart library
see this command also tpconfig -d and then try to take backup

Hi Gaurav,

Please restart the services of NBU on all master and media servers.
Thanks
Pawan

Gaurav,
  On the drives that are not taking backups run the mt command and check the status. I have come across this problem quite a few times and the only thing that worked for me is to recreate the drives from scratch. [backup tpautoconf -t, scan -tape, sgscan tape outputs]

mt -f drive-path status
EX:
# mt -f /dev/rmt/20cbn status
/dev/rmt/20cbn: no tape loaded or drive offline

If you get write protected or reserved and also if vmoprcmd status goes into PEND-ACS then it is SCSI reservation conflict. [vmoprcmd -crawlrelease does help in some situations]

THe fix that worked for me is to rescan drives from scratch.

rm /dev/rmt/*
devfsadm -Cc tape -v [ or cfgadm to force configure hba that is connecting to tape drives].
then do sg.build & sg.install stuff.
tpautoconf -a

Try ot on media server first.

 Hi,

Please, see this document:

http://seer.entsupport.symantec.com/docs/325265.htm

It helped me to solve a similar problem...

[]'s