Hello -
I am demo-ing Veeam Backup right now. I don't have the option of granting direct access to my SAN during the test, but somewhere down the line we will probably do this. For now, I am testing the options I can, i.e. vStorage API using the Virtual Appliance, Network, and the Legacy Network option.
Here is the problem - so far, I have not gotten speeds over 12MB/s, and this was only briefly. Rather, I am seeing approx. 6MB/s, regardless of the option I choose. I had hoped that backing up using the Virtual Appliance mode DIRECTLY to the VM running Veeam would be faster, but I am not seeing this.
Where do people usually backup to? The Virtual Machine running Veeam? Somewhere else? There doesn't seem to be a huge difference between backing up to the Veeam Server and backing up to a remote file share.
In the "vStorage API in Virtual Applicance mode" thread (http://www.veeam.com/forums/viewtopic.php?f=2&t=1859) I see that some people are getting processing speeds as high as 79 MB/s. What am I missing?
Our environment is Virtual Infrastructure 3.5.x on (3) Dell Pe2950s w\ Dual Quad Core Xeons and 64GB of ram. They are connected to a NetApp FAS270 iSCSI SAN. The Veeam Server is a VM w\ 4 vCPU and 4GB of RAM, and the CPU usage is never over 55 percent or so.
Thanks!
Tim
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Mar 08, 2010 8:38 pm
- Full Name: Tim Lazarus
- Contact:
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Backup Storage Location & Performance Issues
Hello Tim,
You will get higher speed if you upgrade your Virtual Infrastructure 3.5, as VMware CBT is only available for vSphere hosts. Also you may try to set the compression value to the highest level, it will reduce the amount data which is being transmitted to the destination storage.
You will get higher speed if you upgrade your Virtual Infrastructure 3.5, as VMware CBT is only available for vSphere hosts. Also you may try to set the compression value to the highest level, it will reduce the amount data which is being transmitted to the destination storage.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Backup Storage Location & Performance Issues
Definitely this speed is way too slow, even for VI 3.5.
Tim, can you try vStorage API "Network" option, and see how the speed compares to the "Virtual Appliance" mode? Also, try to backup to another target (for example, locally to your Veeam Backup VM - just for a test).
These tests should help to nail down the bottleneck.
Tim, can you try vStorage API "Network" option, and see how the speed compares to the "Virtual Appliance" mode? Also, try to backup to another target (for example, locally to your Veeam Backup VM - just for a test).
These tests should help to nail down the bottleneck.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Mar 08, 2010 8:38 pm
- Full Name: Tim Lazarus
- Contact:
Re: Backup Storage Location & Performance Issues
Gostev\Vitaliy -
Thanks for the suggestions. I am actually working with support now, but it looks like it may be a read speed issue. I am not seeing much in the way of a difference between using vStorage Network and vStorage VM mode. Given that both a full backup and an incremental backup of a powered off virtual machine (so no changes between backups) takes about the same time, it doesn't appear to be a write issue.
Thanks for the suggestions. I am actually working with support now, but it looks like it may be a read speed issue. I am not seeing much in the way of a difference between using vStorage Network and vStorage VM mode. Given that both a full backup and an incremental backup of a powered off virtual machine (so no changes between backups) takes about the same time, it doesn't appear to be a write issue.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Backup Storage Location & Performance Issues
Yep, totally agree with this conclusion.
Who is online
Users browsing this forum: Google [Bot] and 66 guests