topic Re: Remote Fbackup Performance issue in Operating System - HP-UX

Remote Fbackup Performance issue

AHMED ABDOU — Sat, 13 Jul 2002 13:44:08 GMT

Hi,

We have two HP UX Servers, K200 and N4000
K2000 is having HP UX 10.20 and N4000 HP UX 11.0. We have configured DLT4000 on K200 locally and trying to take backup remotely from N4000 for their 40 GB file system . Hard ware compression is enabled on DLT.

The problem is remote backup is taking almost 4 days for backup. Our LAN is 100 Mbps and we have tested ftp, it is pretty fast. Installed Patch bundle is Dec'2000.

Pls. advise
1. How can I impove remote fbackup performance?
2. Loading latest SAM Patch bundle will help in reducing time for backup or not? If yes, Specify the patch .

Thanks

NAVID HUSSAIN

Re: Remote Fbackup Performance issue

Leif Halvarsson_2 — Sat, 13 Jul 2002 14:16:46 GMT

Hi

Backing up 40GB data to a DLT4000 should take about 5h so there must be something wrong. Have you tested a local backup on the K200 and which performance do you get ?

Re: Remote Fbackup Performance issue

PIYUSH D. PATEL — Sat, 13 Jul 2002 14:19:12 GMT

Hi,

One thing to check is that you may not actually be running 100FD. Auto-negotiate is not always reliable and one or both of the boxes may not be configured properly. I would set to 100FD on both the servers and the switches to eliminate that possibility.

You can also compress the data before sending it over the network

Piyush

Re: Remote Fbackup Performance issue

PIYUSH D. PATEL — Sat, 13 Jul 2002 14:21:52 GMT

Hi,

One more thing can be done :

Create file called config.backup

blocksperrecord 256
records 32
checkpointfreq 4096
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 100
filesperfsm 800

use that with fbackup
#fbackup -c config.backup -g -0v -f server:

This may definitely reduce the time taken.

Piyush

Re: Remote Fbackup Performance issue

Bill Hassell — Sat, 13 Jul 2002 14:26:36 GMT

Several things:

Use lanadmin -x to display the speed and duplex of your network card. It is very common for 100BaseT cards to fail autonegotiation. lanadmin will also report stats--if you have collisions (which is impossible on a full duplex connection), then the setting is wrong. ftp is 'pretty fast' should mean that a 100 megabyte file will transfer in about 2 minutes or a data rate of about 750-900 Kbytes/sec. If your data rate is far below that speed, then you have a LAN mismatch. You'll need to lock your LAN card *and* the remote switch (don't use hubs at 100 Mbit) to 100Mbit full-duplex, no-autonegotiation. Here's a quick way to test:

prealloc my100megfile 100000000
ftp someserver
...transfer the file...

Then look at ftp's report about the data rate.

If you do have full speed on the LAN, then the problem is keeping the DLT streaming. If the DLT is connected to a SCSI card with disks connected, you'll never have good performance. The tape drive needs massive amounts of data with no interruptions or it will fail to stream. Once it drops out of streaming mode, it must back up, and restart the current record once enough data has been received. This can take 2-5 seconds. If this happen 100,000 times during the backup, then the tape will be repositioning (and not writing to the tape) for about 40-60 hours.

Similarly, if the data rate is inadequate across the network to keep the DLT busy, you'll have the same problem. Some DLT drives have stats stored internally about repositioning and average data throughput. Check with the manual to see how too read these stats.

Dec 2000 is really old. The current patch bundle is Jun 2002. It's doubtful that the patch bundle will improve the speed but you'll save hours of troubleshooting known and fixed problems by keeping up on patches.