Forum Discussion

Somnia's avatar
Somnia
Level 3
14 years ago

"Awaiting resource **** No drives are available"

We have a two node NetBackup 7.0.1 cluster running on RedHat Linux Enterprise, two media servers on Windows 2008 R2 and a HP MSL8096 tape library.

Recently we're facing an issue where during a daily vault duplication two out of three drives on our MSL go down. This seems to be happening only during a vault duplication. Backups are fine and run without problems.

Message we're getting on one of the two active duplication jobs is "Awaiting resource STU-Mediaserver-Robot01 - No drives are available". The second duplication job doesn't seem to have a problem whatsoever.

Looking at the Storage Unit for STU-Mediaserver-Robot01, it's set to handle maximum of 3 concurrent write drives, 8 maximum streams per drive and multiplexing is enabled.

Logging on and checking the MSL console shows all drives to be active and functional.

I have a priority 2 case logged with Symantec Support as this is affecting other jobs but still waiting to receive an answer since yesterday.

Anyone here who can assist???

  • Thanks Marianne.

    After checking the history of the event logs on the media server we found two tapes causing most of the problems.

    Running the robot inventory yesterday on the admin console with 'Empty media access port prior to update' enabled, we didn't encounter this issue anymore. Looks again to be a tape handling issue by our 3rd party.

    This was initially a daily vault issue, as stated in my previous comments, but affected the server backups soon after I posted here.

     

    Thanks again!

  • The 1st thing we need to do is to determine the reason for the DOWN  drives.

    Add VERBOSE entry to vm.conf on all media servers:
    <install-path>\veritas\volmgr\vm.conf   (Windows)
    /usr/openv/volmgr/vm.conf (Linux/Unix)

    Restart NBU after adding the entry. Also create bptm log dir on all media servers.

    Next time a drive goes DOWN, check Event Viewer Application log on Windows servers and /var/log messages on Linux.

    Also check bptm log for errors.

  • Thanks Marianne.

    After checking the history of the event logs on the media server we found two tapes causing most of the problems.

    Running the robot inventory yesterday on the admin console with 'Empty media access port prior to update' enabled, we didn't encounter this issue anymore. Looks again to be a tape handling issue by our 3rd party.

    This was initially a daily vault issue, as stated in my previous comments, but affected the server backups soon after I posted here.

     

    Thanks again!