Slow backup of DLT 2/20

[Victor_83]

I have a DLT drive 2/20 running on a HP L 3000
server (HP-UX OS). I have been backing up data using Omniback and had no problem.

Recently my backup time seems to be getting
longer. Sometimes normal , sometimes longer than normal ( by 10 minutes, 20 minutes, seomtimes by hours). The same tape I used a month ago with normal backup time , overshot
by 4 hours.

Please help.

Thank you.

[Michael Schulte zur Sur]

Hi,

what else is going on on the machine at that time? Do you have problems writing to tape?

greetings,

Michael

[David Ruska]

Can you install HP Library & Tape Tools (www.hp.com/support/tapetools), and run the read/write test on a tape that has a slow backup? Then before the tape is unloaded, generate a support ticket (support tool -> save ticket to file). I'd like to look at the drive error rate statistics.

Poor write error rate will dramatically reduce performance.

[David Ruska]

You can also run the "DLT Acceptance test" on a "good" tape and see what it reports (it checks error rate).

[Gerson Irias]

Another thing that you can do is verify that the tape drive is not asking for a cleaning tape. We have a similar problem and by cleaning the tape drive we were able to resolve the issue.

[David Woodroffe]

I had a similar problem recently with a 2/20 DLT8000 library. Not only did backup times keep getting longer,when using a particular drive, eventually it just started marking any tapes used by omniback as bad. The elapsed time was more than 10 days between noticing backup times incresed and final drive failure. The issue was also masked by the fact that two drives were being used. The tape drive was replaced and all returned to normal. I understand that that the "slowing" down of backup times for a known dataset, is an known sign of pending drive failure.

[Victor_83]

My Omniback is working fine. The problem is that while on most occasions the backup runs at estimated time, on some occasions the backup time overshoots. This happens 2 / 3 times a month , increasing by this month. The tapes are not to blame since the previous month , one particular tape would be OK, then in next month the time overshoots.

[David Ruska]

It may be a particular tape and drive combination that is having problems.

There is a 'media.log' file in omniback that collects the write error counters. This will show recovered (i.e. corrected) errors and the total bytes processes for each tape use.

You can use this to calculate a write error rate. If you take 1,000,000*(errors_corrected/total_bytes_processes), it will give you an error rate measured in errors per MB. You want this number to be less then 0.7, otherwise you are having measurable performance loss.