cancel
Showing results for 
Search instead for 
Did you mean: 

Slow backup w/ Backup Exec 2010 R2 + VMware Agent

brevidwa
Level 3

I recently built a new backup server to replace two older, poorly implemented backup servers. We decided to take advantage of the VMware option in Backup Exec as most (75%) of our servers are virtual. The new backup server is a Dell PowerEdge 2950 with 4GB running Windows Server 2008 R2 and Backup Exec 2010 R2. For disk staging, we're using a Dell MD3000 with a RAID10 array comprised of twelve 15,000RPM SAS disks. The array is attached directly to the server to a Dell SAS 5/E adapter.

Here's my problem: backing up VMware guests is extremely slow. No, it's shockingly slow, like 5MB/min (83KB/sec). That rate is consistent, as though there is some sort of "cap" in place. The test backup was performed on a virtual machine located in our new virtual infrastructure (vSphere 4.1). The same virtual machine was backed up with vRanger and the transfer was fluctuated between 2500 - 3000MB/min, which is what I was expecting from Backup Exec. Our virtual machines are stored on Equallogic iSCSI SAN arrays. The connection between the virtual infrastructure and the backup server is 1Gb ethernet.

To complicate matters further, backing up a virtual machine on our old VMware infrastructure achieves a much better rate, approximately 800MB/min. Still, this is much slower than I anticipated. If anyone has any suggestions, I would be grateful.

1 ACCEPTED SOLUTION

Accepted Solutions

teiva-boy
Level 6

Go to a command prompt

Go into diskpart type in "automount disable"  Then enter

Then type in "automount scrub"  Then enter

Now provision the LUN so that BackupExec can see the VMFS volume.  

In Windows you should now see in the disk manager a new disk, perhaps as an "unknown volume."

NEVER NEVER do anything with that volume.  Dont name it, format, write a signature, or you'll lose the entire VMFS volume.

 

Try the SAN transport again.

View solution in original post

19 REPLIES 19

teiva-boy
Level 6

What transport is BackupExec using for the backup?  

 

brevidwa
Level 3

First in the priority list is "SAN - Use the SAN to move virtual data."

teiva-boy
Level 6

Can you verify that is the actual transport being used?  One way to do that is watch the traffic over those links if you have that ability.  Another way would be to uncheck all the other transports, so it's SAN or nothing.  There may also be the job monitors which contain possibly whats happening in real-time.

I've setup SAN based backups in BE a dozen times, and each time it works and I get fantastic performance (depending on the SAN of course).

 

tbuchholz
Level 2

Hello,

we have the same problem with the vm backup on backup exec 2010 r2. Our backup runs with 2-3 mb/s over the 1gb iscsi san! tansport mode for vmware agent is san only.
We have test the same backup with veeam backup 5.0. there we have data transfer with 106 mb/s.

storage: a netapp fas2050 with fibrechannel disks.
backup server: hp dl380g7, 4gb ram, 2x300 gb sas, 6x 500gb sata for backup to disk
library: hp msl4048 lto3

brevidwa
Level 3

When I uncheck everything except SAN, the backup job fails with the following error:

"The job failed with the following error: Unable to open a disk of the virtual machine."

When only NBD is checked, the transfer rate is 5MB/min. What could cause the SAN transport to not work correctly? Sorry, I'm not really a network guy nor a VMware expert (I do backups and file/print).

tbuchholz
Level 2

hello.

 

your problem is, that the backup server must attached to the san and must present the vmware luns. but be careful. you must first deactivate the automount of the diskpart.

then your san backup will run.

brevidwa
Level 3

Thanks. Is there a document that explains how to accomplish this?

teiva-boy
Level 6

Go to a command prompt

Go into diskpart type in "automount disable"  Then enter

Then type in "automount scrub"  Then enter

Now provision the LUN so that BackupExec can see the VMFS volume.  

In Windows you should now see in the disk manager a new disk, perhaps as an "unknown volume."

NEVER NEVER do anything with that volume.  Dont name it, format, write a signature, or you'll lose the entire VMFS volume.

 

Try the SAN transport again.

brevidwa
Level 3

Excellent, thank you. That clarifies things quite a bit. Pardon my ignorance on the subject, but do I use Windows iSCSI Initiator to connect to the SAN or is there a better way?

teiva-boy
Level 6

The MS initiator or Dell/EQL one is fine.  

The trick for you to get real performance out of the array is to use MPIO, and to schedule multiple backups to write to disk concurrently to take advantage of the extra Gb links and the capabilities of MPIO.  

tbuchholz
Level 2

hello, we have opened a case for this problem with symantec and there are unfortunately no progress. the support said us that we should not use the san option, but virtual machines in a network via iscsi we must use nbd! after switching to nbd, we have come to a throughput of 15 MB / sec. So not so great.


 So we have made ​​ourselves to the further analysis. we have installed in our test center a hp ml580 g3 with w2k8r2 and backup exec 2010r2 sp1. the vmware luns see the server from a NetApp FAS3020 iscsi 1GB lan.
here we become a throughput of 85MB/s option san!
so why is the problem on our productive system?

as the final test is veaam backup 5.0 installed on the productive backup server and started a backup with san option. Here we arrive at a throughput of 116mb / s with option san! over 1GB! iscsi! only why we have on the same server with backup exec only 3mb / s?

I am really desperate.

are grateful for each tip.

jteeuw
Level 2
Thanx for the info! But how do i provision the LUN to backup exec? --------------------------------------------------------------------------------- Go to a cocmmond prompt Go Go to a command prompt Go into diskpart type in "automount disable" Then enter Then type in "automount scrub" Then enter Now provision the LUN so that BackupExec can see the VMFS volume. In Windows you should now see in the disk manager a new disk, perhaps as an "unknown volume." NEVER NEVER do anything with that volume. Dont name it, format, write a signature, or you'll lose the entire VMFS volume. Try the SAN transport again.

teiva-boy
Level 6

Talk to your storage admin, SAN admin, or call your SAN vendor for assistance

jteeuw
Level 2

Thanks for the answer,

I have several iscsi connection made with MS initiator to our storage that hold the vmware files.

But how do I tell backp-exec to connect to the storage? 

teiva-boy
Level 6

You don't.  WIndows needs to see the disks as I mentioned in the steps, but nothing needs to be done in BackupExec at all with those volumes.  Again, let me repeat, you never do anything to the volumes other than what I mentioned in the steps above.

From there the vStorage API's that are installed as part of BackupExec and the AVVI option take all the guess work out of it for you.

jteeuw
Level 2
Tanks for the awnsers, When i make a backup and only select SAN transport i get the following error : V-79-57344-38277 - Unable to open a disk of the virtual machine. VixDiskLib_Open() reported the error: You do not have access rights to this file V-79-57344-38277 - Unable to open a disk of the virtual machine. VixDiskLib_Open() reported the error: You do not have access rights to this file The backup exec server ha admin rights on the vsphere environment.

Dariel_Cruz
Level 3

am still not getting good enough speeds after using the SAN transport, i was getting 500MB/min with NBD to B2D folder then I get about 800MB/min with the SAN and B2D folder, then I tried SAN to tape and i get 4.5GB/min how? and why? it does not matter if I use GRT either, I opened up ticket with symantec now, lets see if they can figure it out. 

Dariel_Cruz
Level 3

this is not the solution to the original post this is a how to for the SAN option, I dont think this should be marked as a solution sorry.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

That sounnds like you have finally configured your SAN correctly but now have a write speed issue with the disk array that owns your Backup-to-disk target. Almost certainly you need to look at optimizing the disk access whcih is not really a Backup Exec issue.