Backup Speed-How to Increase?

[eeicai]

Hi All,

I have FULL backup of 12 clients but when 11 are done, the 12th (a 60GB) volume crawls - it takes over 24hrs to complete as it's writing at an average of 256KB/sec. How can I configure it so that when the other 11 clients are done it continues to write at 1MB+/sec and complete sooner?
It eventually succeeeds but man, takes time!
Thanks,
C

 

[605]

1. This could be a hardware problem but also could just be due to the fact that you deal with a large number of small files.

2. NW writes the file index at the server while you do the backup. To make sure that it can stream, you must have a network link that is fast enough to support the index updates.

3. If you write to a fast backup tape and you can not provide enough data in time, the media has to reposition all the time. In such case, it is better to collect the data on a file type device before you (automatically) stage it to tape.

 

[TDun]

It could be that it is running an incremental backup and this is taking an age to trawl the disk before it passes data back to the Networker server.
It could also be that the NIC card is not set to the same as the Networker server. TRy setting it the saem, stop the client server and restart it and then run an overnight.
Lastly, it could be that your tape drive needs multiple sessions to multi-stream the tape drive for efficiency.
When it is running slowly, how many save sets are listed as active?

 

[eeicai]

Thanks guys, just that any other client running on its own would write at an average 2-3MB/sec but this particular client at 200kb/sec.
I thought that maybe it was something to do with paralellism/priority in Networker?

 

[new2me]

What platform is the client on?

Check the NIC setting for that client and verify that's setting also matches your network switch.

 

[goony]

In general, I force the Ether speed/duplex on all of my clients - I don't rely on the Ether switch or the client to correctly auto-negotiate the speed. So, try making sure your client is at the highest speed (e.g. 100FDX) and restart it or bounce the network connection so that the switch can see its proper speed. If you can, get the Ether switch forced to the same speed so that there is NO auto-negotiation of speed/duplex occuring. Eliminate this possibility, don't leave this to chance.

Also - if you FTP a large binary file from a good client to the server and then FTP a similar file from your 'bad' client to the server, what kind of throughput (KB/sec, MB/sec) do you see? Are they vastly different or the same? This might help discover if it is a network issue or not.

If there is a way to look at the Ethernet error counters on your 'bad' client that might reveal what is going on - if (say) the Ether switch and the client NIC were not in agreement on speed/duplex that would result in a lot of errors and retransmissions. Check these counters before you force the NIC and Ether switch speeds, try another large file transfer and then check again afterwards the thruput and Ethernet error counters.

Finally: Your NIC manufacturer might have a utility to display your counters... check at their website.

 

[605]

BTW - just use bigasm to run a quick performance test.
- Create a dummy file "testfile" on the client.
- create a local directive file in the same directory:
.nsr on UNIX/Linux
nsr.dir on Windows
Content should be just 1 line:
bigasm -S100M : testfile
- backup this file

NW should create one file 100MB size and pipe it to the device. See what you can achieve.

For more details about bigasm, have a look at the performance tuning guide.