I have a couple of Windows 2003 servers backing up through 1GB line to my Windows 2008R2 networker server with Networker 22.214.171.124 installed. Backups are running to LTO5 tape drive. Both 2003 servers are VM and have C,D,E,F and Z drives. I noticed backup on D and Z drives are very slow, I'm getting on average around 6-7 MB/s when the other drives are streaming with ~20 MB/s. D has many small files and maybe causing the slowness but Z drives have 10-12 DBF oracle DB with 2GB on each file. When Z drive running alone, it only backup with speed 4-6 MB/s. But when I start another group with other Windows 2008 client in there, the Z drive will start to pick up the speed itself, sometime getting up to 20-30 MB/s. You can see the picture attached. I already hardcoded network switch to Full instead of Auto-Negotiate
I try manually copy one of the DBF file with 2GB size and the rate is very good with ~30MB/s. I'm not sure what is going on here.
The most obvious issue is that a slow data rate (depending on the file size) causes the average data rate to decrease.
If you have a single stream to a fast tape drive this will lead to more repositioning cycles which will make this situation even worse. LTO5 scan stream with about 150..180MB/s. This is not achievable with a 1G network link.
If you provide multiple streams, you interleave them in such a way that another stream can 'fill the gap' and keep the tape streaming while the slow one cannot send data. Unfortunately, you spread your single stream data which will reduce the restore time later.
To verify the max speed your client could deliver,use the 'bigasm' test. See the 'Performance Tuning Guide' for details.
The best method to avoid repositioning is to use backup to disk. Well - this is not exactly true. If you think abstractly, even a hard disk has 'repositioning cycles' but these are just a fraction compared to those on tape drives.
To verify the effect of B2D, may I suggest that you run such tests. Temporary license codes can be found in the latest Licensing Guides.
BSD is not possible at the moment since we do not have the capacity to do that.
What baffles me is this not on daily basis.. today the backup will finish in 2 hours and the next day it will drag until 8-10 hours with the same size of backup. I have checked there is nothing happening on network,client or server side during the long hour backup.
So if the environment is fine in principle, another item must be kicking in which is not under your control ... like a firewall or similar. But only you know your environment.
You can look at below points too,
When you are facing slow backup look at processor usage, disk usage, iops and memory utilization on client. High utilization by some other process might cause slow backups.
Also look at the number of backup sessions running on the NetWorker server. Try to divert this client backup to separate pool and dedicate one device to this pool.