DLT4000 drive and backup question

[Coy Trosclair]

Group, I have 4 large files (total about 40gb) that's taking roughly 17 hours to back these files up.

I have a DLT4000 with two drives on the same SCSI chain:

tape 1 0/4/0/0.4.0 stape CLAIMED DEVICE Quantum DLT4000
/dev/rmt/1m /dev/rmt/1mn /dev/rmt/c13t4d0BEST /dev/rmt/c13t4d0BESTn
/dev/rmt/1mb /dev/rmt/1mnb /dev/rmt/c13t4d0BESTb /dev/rmt/c13t4d0BESTnb
tape 2 0/4/0/0.5.0 stape CLAIMED DEVICE Quantum DLT4000
/dev/rmt/2m /dev/rmt/2mn /dev/rmt/c13t5d0BEST /dev/rmt/c13t5d0BESTn
/dev/rmt/2mb /dev/rmt/2mnb /dev/rmt/c13t5d0BESTb /dev/rmt/c13t5d0BESTnb


I'm only using one drive to back these files up, but even so shouldn't I be seeing faster backup times than this (roughly 2gb an hour).

Two questions:

1) anything you can think of that might be slowing these backups down?
2) I'm thinking of breaking the backup of these two files over two drives and running them at the same time, although I don't think this is the long-term solution.

Any help is much appreciated.

[Pete Randall]

What are you using to back these files up?

Can you spread them over two SCSI channels?


Pete

[Bryan D. Quinn]

Hello,

Is there anything else on this scsi channel?

-Bryan

[Coy Trosclair]

Here is the scsi chain:
ext_bus 13 0/4/0/0 c720 CLAIMED INTERFACE SCSI C875 Fast Wide Differential
target 7 0/4/0/0.3 tgt CLAIMED DEVICE
unknown -1 0/4/0/0.3.0 UNCLAIMED UNKNOWN HP C1194F
target 8 0/4/0/0.4 tgt CLAIMED DEVICE
tape 1 0/4/0/0.4.0 stape CLAIMED DEVICE Quantum DLT4000
target 9 0/4/0/0.5 tgt CLAIMED DEVICE
tape 2 0/4/0/0.5.0 stape CLAIMED DEVICE Quantum DLT4000
target 10 0/4/0/0.7 tgt CLAIMED DEVICE
ctl 9 0/4/0/0.7.0 sctl CLAIMED DEVICE Initiator


We're using omniback.

[Pete Randall]

Omniback is usually pretty good for throughput and the DLT4000 is rated at 5.4GB/hour, so you certainly ought to be getting better performance. Perhaps check for lates Omniback and DLT patches? If you could split the backup between the two drives *AND* separate the drives on different channels you would be much better off.


Pete

[Tim D Fulford]

Is hardware compression turned on. This generally speed things up (roughly in the ratio of compression achieved)?

2GB an hour is only 0.6 MB/s Very low. The SCSI you are on should do something like 10MB/s. I do not know how fast DLT4000 writes to tape but I'd guess at 2MB/s+.

Have you tried to remove one DLT device? loked in the syslog for SCSI resets, scsi chain length... etc

Tim

[Leif Halvarsson_2]

Hi,
A DLT4000 drive should reach about 10GB/h backup performance if using hardware compression and 2-1 compression ratio and with no compression at all about 5GB/h.

Do you get the same performance with any of the drives ?
What backup software are you using ?

[Enrico P.]

Hi,
is the tape library directly connect to server that you backup o you backup it via network?
In the second case may be normal the long time specially if there is a high network traffic.

Enrico.

[Leif Halvarsson_2]

Sorry,
I did not noticed that you use OmniBack. Is software compression enabled ? If so, disable it and use hardware compression. Software compression is very cpu-intensive.

[Coy Trosclair]

Just noticed that we do have compression enabled within omniback, and these files are already gzipped, so that's probably part of the problem. I'll disable compression and see if that helps.

[Trevor Roddam_1]

Hello Coy.

From your "ioscan" it would seem that you have a 4/48 tape library connected.
The robotics are the unclaimed device.
You will need to follow the installation guide to rebuilt your kernel with the correct drivers for it to work.

As to your issue with the speed.
Seeing that you have FW/Diff SCSI I would recommend having only one DLT4000 per SCSI chain as HP highly recommend only having one device per SCSI card. This is due to perfomance of the tape device.

Tape perfomance dropps off significantly when there is more than one device per SCSI channel.
Try turning one of the tape drives off or un-plugging it and running a test again.
You should see over 5.4GB per hour, probably around 8GB/hr.
This is assuming there are no issues retrieving the data from disk.

To test the data retieval from disk do a back up to /dev/null . Also make sure OmniBack is not the culprit here. Try "tar" or "cpio" to tape. I have found that retrieving the data from disk is more than half the issue.

OmniBack can be at fault if it can't write data to is data files quick enough. Not normally an issue though. Only apparent with very large numbers of very small files.

SW compression will kill the backup, especially of "zipped" files.

Hope this helps.
Trevor.