SDLT tape unit very slow

[Alan Casey]

Hi,

I have attached a Compaq SDLT 110/220 Drive to my A500 HP-UX 11i v1 server.
Backing up 100G takes approx 12 hours.
I think this is excessive, I'm just backing up using fbackup and our old DLT tape unit (which is now broken) was taking about as long.
Any ideas on how I can speed this up?

[Devender Khatana]

Hi,

Have you tried cleaning?

Even DLT should not have taken that much time for this data. Is data in use while being backup up?

Have to tried some other backup command with same hardware to verify the throughput?

How is the utilization of the server when backup is going on?

HTH,
Devender

[Muthukumar_5]

Refer from this:

http://www2.itrc.hp.com/service/james/search.do?searchtext=SDLT+tape+unit+very+slow&x=6&y=4&searchcriteria=anyword&searchtype=SEARCH_FORUMS&rn=25&presort=rank

--
Muthu

[Alan Casey]

We tried cleaning it recently, and the files are not open.
The server has a large Oracle database on it, but we shut this down for the backup.

[Arunvijai_4]

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=975352

-Arun

[Eric Antunes · Accepted solution]

Hi Alan,

Are you using SAM? If not, try it since SAM uses fbackup and in a faster way than using fbackup directly (because of some configuration files)...

Best Regards,

Eric Antunes

[Pete Randall]

Alan,

I suspect that fbackup simply cannot feed the data fast enough to keep the drive "streaming". The modern tape drives are designed to "stream" the data onto the tape very quickly. If the drive doesn't get enough data, it has to stop the high speed forward motion of the tape, rewind it, find where it left off and then try to resume from there. This constant stopping, rewinding, and resuming not only slows down the transfer, it is probably what contributed to the demise of your previous drive.

In order to fully utilize your drive, you would need to use a more sophisticated backup package that sends multiple streams of data to the drive in order to keep it fed. With fbackup, I would think you might to better off writing to a DAT drive. If you've got one around, I would definitely give it a try.


Pete

[Steve Lewis]

I am inclined to agree with Pete.
Your A class may not be able to supply the fbackup processes with data at the required rate. This may be caused by slow disks, fragmented files or not enough cpu to drive multiple fbackup processes at once.

I can stream to an LTO2 with fbackup, but I have 15krpm disks and at least 4 cpus at 750 Mhz, the point it you need to look at the whole system end-to-end, from source through cpu, fbackup config file, interface card speed, to the tape drive.

Another possible reason may be plugging the tape drive into the same SCSI bus as the disk - that is not recommended.

Another possibility is to check the SCSI RATE in the BCH menus. It can be set to things like FAST and ULTRA, you would need to verify you got the right one - I think ULTRA is a safe bet for SDLT.

HP have a useful tape testing utility you can download which will give you more information.

[Alan Casey]

thanks guys, I'm satisfied now that the combination of H/W fbackup and SDLT is not optimal.
Using SAM has actually speeded it up so thanks for that Eric :)

[Bill Hassell]

As mentioned, modern tape drives are extremely fast and are approaching raw disk speeds. When you are backing up thousands of small files, the overhead in opening and closing these files will tend to slow the data speed. All modern tape drives are streamers, that is, they are not designed to start-stop rapidly and must always be running to meet their throiughput specs. If the computer cannot keep up, the tape drive stops, backs up and restarts which loses several seconds of throughput.

To maximize the throughput, fbackup has a config file to improve performance. fbackup's defaults are NOT compatible with modern tape drives, they were designed for reel-to-reel magtapes. So change your fbackup command to use a config file (-c option), something like this:

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

For SAM, edit the file: /usr/sam/config/br/fbackup_config with the above values and retry the backup. That should improve the backup speed considerably.

[Alan Casey]

Thanks for that Bill
The config file shaved approx 30% off the backup time