Ultrium Tape Library 2/60 slow

[Sanjiv Sharma_1]

Hi,

I have a N-Class/HP-UX 11.00/OB-2 ver.3.50/ Ultrium Lib 6/60. I have another rp8400 & L3000 which are connected to the Library through a FC switch in the same network.

I have been taking the filesystem backup of rp8400 and L3000 on Ultrium Library through OB2. Earlier 75 GB filesystem use to take 1:30 min. But now for the last 1 week 95 GB data is taking about 4 hr.

Sometime the media also gets stuck in the drives. 2 times in the last 1 week.

I have cleaned both the drives with the cleaning cartridge twice in the last 3 days.

What could be the cause?

Thanks,
Raje.

[Michael Tully · Accepted solution]

Hi,

First we need to eliminate the causes of tapes getting stuck in drives.

On all HPUX boxes, you need to implement the following changes.

In OmniBack change the Busy Drive Handling option, so that when stop, abort, etc the tape is ejected and returned to it's slot.
Devices & Media --> Select Library --> Right click on mouse --> properties --> Control --> Change to 'Eject Medium' from Abort (default)

Add to your system kernel 'st_ats_enabled' parameter to be '0'

Disable EMS monitoring for SCSI tapes.
See the attached document.

Check out the latest SCSI patches.

Do not clean the drives, unless the drive displays the cleaning light.

Do any of the backups run at the same time?

HTH
Michael

[Sanjiv Sharma_1]

Hi Michael,

Thanks for your reply.

I have changed the Drive from Abort to Eject Media and also disabled the EMS monitoring of the SCSI tape.

I couldn't modify the "st_ats_enabled" to 0 as it requires reboot. I will try to do it ASAP.

From where can I get the latest SCSI patches.

Sometime the backup overlaps when the previous backup takes more time than usual.

There was no problem till last week, then how this problem has arised even when there is no h/w and s/w changes done.

Thanks,
Raje.

[Michael Tully]

Hi Raje,

Each backup device that is used in a tape library situation must have a lock file that is used. Each logical device must have that same name that same name associated so that a new backup for that physical drive can't start until the previous backup has completed. I am quite sure that these lock files are described in the manuals. If you need further with this let us know.

Regards
Michael

[Ted Ellis_2]

We have also had intermittent problems with our SureStore library failing with tapes stuck in drives. We recently upgraded drive and library firmware and have not had the problem since. I know of others having the problems as well. The issue is appears to be the Gen 1 Ultrium drives and the firmware. We had the problem at least once every 2 weeks. It has been 3 weeks since the firmware upgrade and all is well.

[Michael Tully]

Raje/Ted,

The problem with tapes getting stuck in drives in not just LTO/Ultrium, but also with DLT's and has been a problem for well over a year.

As long as these guidelines are followed, the problems should go away.

SCSI patches
Disable EMS monitoring
Appropriate kernel parameters
OmniBack Procedures/Locking
Up to date firmware

HTH
Michael

[Sanjiv Sharma_1]

Hi All,

Thanks for all your replies.

Last 1 day the media didn't stuck. I need to observe it for 1 week.

Now the main concern is the backup time being high. The filesystem backup time is nearly 2 times or more the previous backups.

What needs to be checked for this?

Thanks,
Raje.

[Michael Tully]

Hi Raje,

Check this document, it may relevant to your situation.

http://openview.hp.com/sso/ecare/getsupportdoc?docid=OV-EN002579

HTH
Michael

[Raul Gonzalez Limon]

Hi all,

Just one anotation. We have a Ultrium 2/20 connected by FC to a N4000-75. We backup aprox. 500 Gb each night. When we reboot this machine we get about 20 Mb/sec for each drive but in one week this time comes progresively to 10 Mb/sec. Have you rebooted it since you have the Ultrium?

Kind regards,

Raul Gonzalez

[David Ruska]

Just a minor clarification:

> Disable EMS monitoring for SCSI tapes.
> See the attached document.

In this document, it says:

>> 7) Rename the dm_stape binary (optional; makes sure dm_stape will not run at all)

This is not recommended, because it prevents LOGTOOL from decoding SCSI errors from tape drives. (This step was erroneously listed in an older HP SAN backup application note - sorry).

So, don't rename dm_stape - it is also used as a logtool decoder tool.