backup performance

[huguley]

I have been looking at the backup performance and it does not make much sense to me.

 

I have retrospect server running on a p3 933.

 

Some of the clients are on fast ethernet and others are on a gigabit network. Some of the

clients on the gigabit network are not much faster than the ones on fast ethernet. All of the

computers are at least a 933. The fastest client runs at around 200 Megs/minute on the gigabit

network but some are around 100 Megs/minute. And on the fast ethernet some clients run at

close to 200 megs/minute.

 

Why is there such a difference in the speed? it runs at night so there is no activity on either the

machine or the network.

 

Would a faster machine to run retrospect on up the throughput? I do use software compression

so I am thinking that it would make it faster for sure but I am not sure how much it would help.

 

Is there a way to make the clients do the compression? That would up the throughput most of

all I would think.

[paleolith]

How fast are the clients? How fast can they do normal file transfers? Pushing data this fast requires significant CPU power. If they are slower than the backup server, then they may be the bottleneck. It sounds like all the backups are CPU limited and that you are not saturating either Ethernet.

 

Edward

[huguley]

Nope definitly not saturating either ethernet.

 

I did a quick test with ftp and it did not seem to matter whether it was over the Gbit or the 100

ethernet. In either case ftp ran at around 11000 KB/s which if my math is right that is ~600 MB/minute.

 

If I do a windows file copy over the 100 ether I get 156MB in 25 seconds ~375 MB/min.

The same file over the Gbit went in 5-9 seconds depending on the machine. ~1872 MB/min.

 

Just for comparison if I do a secure ftp over the 100 ether I get 3000 KB/s ~200 MB/min.

 

My machine on the 100 ether is a P4 1.6Ghz. The machines on the Gbit ether are around a P3 1Ghz. though they do have SCSI rather than my IDE and are running 2k server or linux.

Retrospect reports my machine at ~200 MB/min so its speed seems closer to secure ftp than

plain old ftp. And no I do not have it encrypting the network link.

 

It did occur to me to check the speed of the local disk on the backup server and it only runs at ~275 MB/min so it does indeed look like it is the backup server that is the bottleneck. I will try installing retrospect on one of our new 2.8 Ghz Zeons and see what happens.

 

I was hoping the new 6.5 version of retrospect would solve the problem by allowing it to backup several clients at once but it does not work that way. It looks like it can only do multiple clients if they go to different backup sets. The 6.5 retrospect is pretty nice though it lets you do other stuff while it is backing up or restoring.

 

[huguley]

I installed retrospect on a 2.8 Ghz Xeon and ran it from there and it did not change much so

it is not the CPU.

 

I did notice though that it actually peaks at close to 400 MB/min when it is doing larger files but

it drops to around 15 MB/min when it does lots of smaller files. So when it does you IE cache

directory it slows down quite a bit.

 

It must just be how retrospect does things. If you can do it then not backing up the smaller files

would up your throughput. But it seems as though there is not much more that can be done to

speed it up.

[ssevenup]

I have a trouble ticket with our network operations because of a massive glaring performance discrepency among our buildings. The network hardware is all similar and the routes in question are also, yet I get 2 to 5 times the performance if I relocate my server from it's normal location to another building. I can push packets at wire speed using a tool like iperf, but Retrospect server crawls in one subnet and flys in the other. The location of the client seems to have nothing to do with it. It has everyone totally baffled. I am seeing upwards of 500 - 600 MB/min in one subnet backing up some pretty mediocre hardware with 100base-T switched connections. It definitely looks like it's NOT a client issue. Retrospect (6.5.319) just seems to "favor" one subnet over the other. We have a mixture of Foundry and Cisco switches. I need some serious troubleshooting help from Dantz or I fear we will never figure this out. The network group has thrown up their hands because there seems to be no identifiable cause. I wonder if there is a "debug" version of the client or a "logger". Obviously we have looked for collisions, CRC errors and the like but found nothing. It's as if Retrospect throttles the connection on one subnet and not on the other.

 

--MM

[natew]

Hi

 

Retrospect does not throttle the network connections, it just runs as fast as it can and calls it good. Are you accesing the different subnets via a different NIC? As a test have you tried backing up that subnet with another machine? (you can use a file backup set for this rather than disconnecting your backup hardware)

 

The most likely cause here is a factor outside of Retrospect so we should at least approach it from that angle.

 

Nate

[gkowalsky6]

ssevenup said:"debug" version of the client or a "logger"...

 

Multiserver 5.x-6.0.x: Hitting Ctrl-P-P (fast P twice while holding Ctrl) will bring a "hidden" prefs, where one can select logging level for different parts of Retrospect. I'm afraid that what's in the client/network logs can make sense to the Dantz developers - I did not see any resemblance with packet-analyzer tools I know.

 

However, HTH