Transfer speed issue

anything I don't mind

anything I don't mind

anything I don't mind

Permabanned
Joined
28 Dec 2009
Posts
13,052
Location
london
At one site we have a physical backup server with backup exec on it. It has a gigabit nic. All servers on the network seem to be able to transfer to this machine at relatively fast rate 15mbyte a second etc. But when copying from one specific vmhost it goes at 5mbyte a second. I have done some transfer tests and it is not a disk transfer problem as copying between disks on the array goes at full speed. Even copying between guests on the same vmhost. I even tried copying from one guest on the problem host to another guest on another host and the transfer speed was ok. It is just copying too the physical backup server from this vmhost that is very slow.

The host has two gigabit nic assigned to the vmnetwork that is in use by three guests, one of the guests is not used and the other is used for monitoring and is not heavily used.

Any idea how i can troubleshoot this problem? it kind of looks like a vmhost/nic issue, the vmhost is running esx 3 which does not help. Do you think a reboot of the host might solve the issue, any tips might help thanks
 
15 mbyte a second is pretty slow to be honest for backup.

Are you backing up straight to tape?
What version of Backup Exec and virtual server software are you using?
How are the virtual machines stored on local disks, SAN etc?
Is the backup machine and vm host on the same switch? Same subnet etc?

Kimbie
 
I have narrowed the problem down to the system44 network throughput to certain servers.

Has to be switching issue at this point. vmhost80 has the data i want copied to backup on system 44

vmhost80 -> vmhost26 - 30mbyte sec
vmhost80 -> system44 - 5mbyte sec
vmhost26 -> system44 - 5mbyte sec
clientpc -> system44 - 11mbyte sec (100mbit client limit)

All disks are operating at full speed as i have done several copies between guests on the same array and on the same disks etc.

My tests are just from disk to disk but backup is going to tape lto5 tape capable of 160mbyte second. I have done tests on the tape and that is fine.

I have plugged in the second nic in system44 and made sure it is on a good gigabit cable and i have tried plugging it in to different swtiches. the vmhost80 has two nic and they both go in to a different switch. I tried putting the system44 nic in to the same switch thinking it was an issue between switches. but no luck.

I haev a theory that it may be a routing issue on the switches and it is sending the data to our datacenter over a 100mbit link and sending it back. But traceroutes only come up with one hop from system44 to every server i tried.
 
Last edited:
We had a problem which we fixed by forcing BackupExec on the job setup to use a specific network card and IP range as it was trying to backup the VM through the virtual centre rather than directly from the SAN
 
Thanks ill take a look at that but it does appear to be an issue with the backup system itself as i can't even copy directly to the disks on the backup server from various servers. I just tried copying from another physical machine with internal disks to backup server and have the same slow performance. This is a realy odd one imo.

I copy from the backup server to another physical server through the network at 50mbyte a second, but copying the other way is 5mbyte second.
 
Even stranger.

On system44 if i open system91 which is another physical server and copy from system91 to system44 it goes at 50mbyte second.

But if log in to system91 and copy to system44 it is restricted to 5mbyte second. Never seen anything like this before.
 
Sounds like it could be a SMB issue, we see that here with some machines, it can be quicker to push the data rather than pull it.
 
Updated the nic drivers and it fixed the slow transfers across the network but only slightly increased the backup to tape speed. Think it maybe a problem of the array that the dms file store is sitting on, it does not have a fast throughput for small files.
 
You must log in or register to reply here.
Back
Top Bottom