ARCServe 12 slow backup throughput

[Noyzyboy]

Hi all,

Would appreciate your combined thoughts and comments on this, I'm sure it can't be limited just to ARCServe

We have a customer running ESX 3.5 with VC2.5 running on IBM HS21 blades. They have an IBM BladeCentre with Nortel 1GB ethernet switches connected with 4 trunked ports to a Cisco stack. The VMs are stored on an EMC CX500 on a number of different arrays. The backup infrastructure is a brand new IBM x3500 running Server 2003 and ARCServe 12 using the D2D2T option.

They are currently experiening backup throughput issues.

If they back up a VM stored on the above infrastructure they only get about 600-800MB/min throughput during the D2D section (from the VM to the disks on the ARCServe server.

If they back up a physical server they get throughputs of up to 3GB/min during the D2D section.

The D2T section runs at about 6-7GB/min which shows that the disk subsystem on the backup server is not the bottleneck and that the LTO4 is humming...

We believe the bottleneck maybe the networking on the ESX Servers. Do you have any suggestions as to the best way of determining if this is the case and also any suggestions as to how to resolve the issue or at least speed things up a little. Multiplexing the D2D backup jobs makes the job run a little faster but the performance for each individual machine is still slow. Are there any changes in the VM hardware that can be made. Each machine uses the "flexible" NIC adapter and each ESX Server has a single virtual switch which has port groups for the VMKernel, the LAN, and VMotion on it as the Blades only have two physical NICs, both NICs are teamed in the virtual switch and hard set for 1000/full. VMotion is VERY rarely used, less than once a month. Yes, I know you are supposed to run VMotion on a separate network but with a Blade with 2 NICs what can you do...

The issue might be caused by the EMC not being able to cope with the throughput but I doubt it, still possible though.

Please let me know if you need anymore information.

Hope you can help,

Richard

[dinny]

Hiya,

Are they running file level or full VM backups?

Lots of people (myself included) seem to find file level backups run far slower than full vm backups.

Interesting thread I read in the last few days (somewhere on vmtn) suggested that defragging the disk in file/dir order using jkdefrag made a big difference..

Dinny

[dinny]

Just found the link:

http://communities.vmware.com/message/962560

Dinny

[Noyzyboy]

Sorry, I tried to get all the details but you always miss something

These are file level backups using an ARCServe agent inside the VM (all VMs are Server 2003). I have to admit I suspect the issues to be at the virtual switch layer. I have a cll logged with VMware Tech Support, will post back here if we get any resolution.

Cheers,

Rich

[Noyzyboy]

Thanks for the links. I'll test that out over the next couple of days.

Cheers,

Rich

[smurfman]

Hi

I came across this post, and while it is one year old, I was wondering what yoy found out with support concerning your ArcServ3 12 File Level Backup.

I am experiencing almost the exact same issues that you were seeing in your post.

I am running ArcServe v12.5, and up until last week I was getting around 3.5GB/min from my VM doing a file level backup using the ArcServe agent, and something all of a sudden has killed it. All last week I was back down to 1.5GB/min and today it was at 600MB/min

I have rebooted everything, double checked my Physical Switch, moved the VM from one ESX to the other

When I noticed the issue, it was shortly after installing Diskeeper 2009 Enterprise in my VM to keep the files inside the vmfs clean, I thought that was the issue, but was not.

Was hoping you could share what might have resolved your issue.

Thanks

J

[Santiti]

Hi,

I have this problem, solution??? Please...Help!!!!!

[BradDHancock]

All of a sudden my backups went from 4gb/min to 130mb/min with a RAW or File level backups in Vshpere 4.1 with a SAN. Using VDDK with Arcserve 15

Any solution for this issue? Not all the vm in the backup are running slow, but it's consistently the same vm's.