topic Re: fbackup very very slow in Operating System - HP-UX

fbackup very very slow

patrick coutinho — Sun, 25 Apr 2004 14:28:03 GMT

Hi,

We have an rp7410 with 4 cpu's and 12 GB memory and 20 gb swap. we are backing up a lun which is 102 gb in size and is on an EVA 5000 with 1 gb HBA.

This backup is taking far too long. Index is activated. this backup is going on for 8 hours now. total no. of files to be backed up is 678,000 and there is a deep directory structure. Please help.

Thanks in advance,

Rgds

Pat

Re: fbackup very very slow

A. Clay Stephenson — Sun, 25 Apr 2004 15:52:13 GMT

Well, without knowing what you are backing up to, it's rather difficult to be helpful. If you are backing up to an AIT or DLT device then you should increase readerprocesses to 6 (the maximum), increase blocksperrecord and records.

You could also be trying to backup files which are being updated so that retries are attempted. In that case, reduce maxretries.

You might consider loading the Trial version of DataProtector for better performance.

Re: fbackup very very slow

Steven E. Protter — Sun, 25 Apr 2004 20:15:26 GMT

This could be almost anything. It could be bad termination, bad scsi cable, even a fault wwith the or the drive itself.

It could be a problem with the fiber card or LUN as well. You might want to check with SAN administration to see if there are issues there.

Lets start with the ioscan command and look for problems. The number of files or depth of the directory structure should not be that big a problem. I've backed up bigger and deeper with Ultrium drives. I've done it in substantially less time than 8 hours too.

SEP

Re: fbackup very very slow

Bill Hassell — Sun, 25 Apr 2004 21:10:18 GMT

DO NOT run fbackup without a config file. The defaults are designed for (very old) 1/2" reel-to-reel tape drives. Use this file with -c option:

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

This should significantly reduce the backup time. Make sure your tape drive is NOT connected to the same interface as your disks.

Re: fbackup very very slow

patrick coutinho — Mon, 26 Apr 2004 01:50:25 GMT

Thanks very much guys,

We are using DLT IV with compression thru sam. The backup is COLD. Thanks Bill. I will try out the config file. What does filesperfsm mean ? We have tried this backup twice now and had to kill it because of the slowness. How long in your estimation should a 102 GB backup take with the tape drive locally connected. Its a DLT 8000 drive.

Thanks once again,

Patrick

N.B. Points allocated.

Re: fbackup very very slow

A. Clay Stephenson — Mon, 26 Apr 2004 09:18:17 GMT

filespersm is the number of file between fast search marks. A smaller numer allows faster restores of individual files at the expense of a little overhead.

The main criteria for getting good performance out of a DLT is to keep the drive streaming. Is the drive writing almost continuously or does it write for a second or two then pause and write again briefly. If the drive is stopping and starting the throughput is greatly reduced from nominal.
Realistic throughputs for this drive are about 40-50 GB/hr although the specifications are much higher. If this is copper SCSI, the DLT drive must be on a dedicated bus.

Typical schemes for backing up large amounts of data use some sort of snapshotting or mirror spliting. The snapshots take only a few seconds. You can then restart the application and back up at leisure using the snapshots. You then don't really care how long the backups take.

Re: fbackup very very slow

A. Clay Stephenson — Mon, 26 Apr 2004 09:26:29 GMT

One final point, all of the fbackup config file paramaters are discussed rather well in the fbackup man page. Man fbackup for a full description.

Re: fbackup very very slow

patrick coutinho — Mon, 26 Apr 2004 09:37:03 GMT

Thanks a lot Clay,

We have solved out problem out here. For everyone's benefit what we have done is

- Use a SDLT drive which is located on our Legato backup solution. This drive is connected via fibre to our EVA and thru to the host via HBA. And after using Bill's config file, a test backup just flew past. 64,000 file totalling upto approx 3 GB completed in "verbose" fbackup mode in just 306 seconds.

Thanks everyone.

Rgds

Pat

Re: fbackup very very slow

Bill Hassell — Mon, 26 Apr 2004 18:24:24 GMT

filespersm is a highspeed search mechanism. For DDS drives, this is a special marker that can be seen while running the tape about 100x normal speed. Think of it as a big freeway sign. fbackup's index knows how many setmarks must be passed before a particular file will be close. So a file at the end of the tape takes just a few minutes to restore. On DLT and Ultrium drives, setmarks do not exist so tape marks (aka, file separators) are used for the same task.

As mentioned, high performance taoe drives must be kept busy or they will reposition, causing several seconds in lost time (and extra wear on the drive). If you can't keep the tape drive busy, performance will drop to 1/50th to 1/500th normal speed depending on how slow the data arrives. fbackup maximizes back speeds by queueing up several reader processes to open files ahead of the tape, then dumping the data into a shared memory area where it is written to the tape. filespersm is essentially overhead so setting it to 1 will cause 678,000 setmarks to be written and since each setmark occupies a space where megs of data could be written, the overhead will cause the tape to not reach maximum capacity by a significant amount. Set filespersm to 20000 and now the overhead will be very low but recovering a file will jump to a dozen or two minutes because the index can only get to a 20,000 file block.

Re: fbackup very very slow

patrick coutinho — Thu, 29 Apr 2004 08:00:50 GMT

Thanks a lot Bill. Sorry for the delay in replying. Just got caught up in work.

Rgds

Pat