Fbackup over LAN GB network

[Sebbe]

Hi everyone,

I try to make a fbackup over a lan GB network.
The tape is a SDLT and the backup is very slow.
When the backup is local, it's very fast.
Both Gb card are configured with autonegotiation.
Here is my config file :
blocksperrecord 512
records 64
checkpointfreq 1024
readerprocesses 6
maxretries 3
retrylimit 5000000
maxvoluses 2000
filesperfsm 2000

Thank's for your help,
Seb

[Paula J Frazer-Campbell]

HI

Check / monitor your network during a backup.

Paula

[Michael Tully]

Given that the network layer is shared, you will be completing against other traffic. SDLT drives expect to be streaming with data all the time, if they don't, then expect it to wind back slightly whilst waiting for data. This could and would explain why the backups are slow. As metioned by Paula, monitor the network, but I'm sure that the performance will not greatly improve.

Have you checked your network switch is set to auto-negotiate? Your better off turning off auto-negotiate and have it hard-coded that way, on both servers and the switch.

[Bill Hassell · Accepted solution]

Actually, GigEther cards and switches *require* autonegotiation and it always works. It is 100BaseT that is so buggy due to dual standards and timing. Your fbackup parameters are OK. The real issue is the actual data rate provided by the two boxes. Although bits will move at Gb rates, actual throughput can be VERY low because the CPU and/or I/I card and backplane aer incapable of running at full speed. An example would be old K-class boxes where Gb LAN cards are provided for 'connectivity' which means that messages will flow onto the LAN but don't expect 50 meg/sec data rates.

As mentioned, SDLT is a streamer and like all streamers (DDS, DLT, Ultrium, etc) these drives must be kept busy and a LAN backup may never attain the speed needed to stream the drives. Streamers operate at full speed, or when they run out of data, waste several seconds (read: zero data recorded) stopping, backing up, resync and and start recording again. Depending on often this occurs, your backup throughput could be imapacted 100:1 to 1000: slower.

You could set jumbo frames (MTU=9000) on the LAN cards BUT the LAN cards *and* the switch(es) must all support jumbo frames too. And look in dmesg for any gigabit card messages. Set the MTU in the /etc/rc.config.d/hpgelanconf file. Check this link for cautions about end-to-end support for jumbo frames: http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x6a6fdfe5920fd5118fef0090279cd0f9,00.html

[Steven E. Protter]

Bill confirms my suspicions about 1000 BaseT. The switch and card must be auto negotiate.

You might want to monitor your network from the switch and the HP box during a transfer.

I'm attaching a script that will monitor the network, have the switch admin watch the switch.

SEP

[Sebbe]

Thank's for all your responses,

one other is that I use brbackup too for my backups and with that tool, it's ok, my backup takes about 2 hours to complete.
That's why I think that my problem is due to fbackup.
I'll monitor my network during fbackup to be sure.

Thank's

[Bernhard Mueller]

Seb,

brbackup uses dd (by default) on the system side, which provides better throughput than fbackup. You can configure brbackup to use cpio instead of dd, and I think it is not unlikely that you might experience the same network issue with brbackup then.

So I believe this also supports Bill's opinion regarding the CPU and backplane issue.

Regards,
Bernhard

[Sebbe]

Thank's for your responses,

I'll try to use dd with fbackup this week-end :

fbackup -i /files -f - | remsh remotehost dd ibs=64k obs=32k of=DEVICE_PATH

Seb

[Tony Horton]

Was having the same problem (Gig card in one machine 100BT in the other). FTP to/from either machine would get 10MB/s transfer rate on files of reasonable size (over 500MB) so I knew it wasn't the network.

Monitoring in Glance, network was showing max incomming data at 2400KB/s..... MRTG also showed around 24Mb/s.... I was running with recommended blocksperreccord (256)

I am now running with the following config

blocksperrecord 8192
records 16
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

and the incomming speed on the machine with the tape drive (the one with 100Mb card) is now fluctuating between about 3,500KB/s and 7,500KB/s and averaging 5100KB/s. Note this is with an Ultrium 215 drive not DLT but I think it demonstrates that the problem is more with the way fbackup interacts with rmt over the network than with the network itself.

Regards,

Tony.

[Bill Hassell]

FTP is highly efficient in transferring data, much better than any other bundled tool. HP's fbackup was designed in the mid-80's to handle reel-to-reel tapes and the current config defaults are still set for those (very slow) devices. A major reqrite occurred in the early 90's to handle DDS drives but not much more has been done since then other than to recognize a few new tape drives. Using a large blocksperrecord will help collect much larger chunks of data. If fbackup allowed more reader processes (6 max) then throughput might be higher, especially with lots of small files. The rmt protocol is not very efficient at all which is why these very expensive tape drives should use a commercial backup product like Omniback rather than a free backup tool. fbackup works well over the network with DDS drives up to DDS-4 and early DLT drives, but SDLT/Ultrium, etc are way beyond the original design for fbackup remote tape.