Comprehensive data protection for all workloads
Post Reply
alyne
Novice
Posts: 3
Liked: never
Joined: Dec 07, 2009 2:44 pm
Full Name: Andy Lyne
Contact:

Backup Speeds using Storage API

Post by alyne »

Hi All

New user here evaluating Veeam. I have a problem with slow transfer speeds using the Storage API and hope someone can point me in the right direction on how to troubleshoot. Anyway here is my environment:

All Veeam Version 4 components are installed on a dedicated physical server with 3GB Ram, a 3.2 Ghz Xeon processor. One single RAID 5 set of 6 disks used for both the OS and also the backup target. (This is a test so although not ideal should be ok for testing purposes)

We run ESX3.5 with Update 4 connected to both a Clarion CX4-120 and CX300 fibre SAN's.

I have setup the necessary zoning and presented a test lun to the VEEAM backup server - admittedly the test lun is on the slower SAN but it's still a reasonable specification (I ran diskpart automount disable first on the VEEAM server before connecting the LUN's!)

We have chosen not to use VCB and began testing backups using the Storage API SAN Only option. Although all seems to be working well and the product seems easy to use, we are only getting transfer speeds of about 25-35MB/s at most (even after taking the initial full backup)
Ii understand it is likely to run faster on Vsphere 4 but am a little disapointed at the slow backup via the SAN.

Hopefully I am missing something here as I think its a great product but just need to get that speed up!

Thanks in advance
Andy L
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Speeds using Storage API

Post by Gostev »

Hi Andy, please do this:
- Check if CPU is not a bottleneck during backup on Veeam Backup server
- Try to backup to another storage (locally to Veeam Backup server hard drive, for instance)

If you cannot find any issues, I will give you a test tool which simply reads data from SAN and discards it without any processing, this way we will be able to understand where the bottleneck is.
alyne
Novice
Posts: 3
Liked: never
Joined: Dec 07, 2009 2:44 pm
Full Name: Andy Lyne
Contact:

Re: Backup Speeds using Storage API

Post by alyne »

Wow! thanks for such a quick reply Gostev. I have checked the processor on the Veeam Backup server during a backup, it is not even warming up so don't think that is the issue. (It is quite a powerful Proliant Xeon specification)

I am already backing up to the only local storage I have so without rebuilding the server and repartitioning it will be difficult to choose another target.

That test tool sounds a good option :)

Thanks again
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Speeds using Storage API

Post by Gostev »

OK, I will ask devs to build one. We had one for very early v4 beta testers, just need to update it now because it was not maintained since then.
alyne
Novice
Posts: 3
Liked: never
Joined: Dec 07, 2009 2:44 pm
Full Name: Andy Lyne
Contact:

Re: Backup Speeds using Storage API

Post by alyne »

Gostev wrote:OK, I will ask devs to build one. We had one for very early v4 beta testers, just need to update it now because it was not maintained since then.
Hi Gostev

The backups seem to be slightly faster now - about 50MB/s/ As we are planning to migrate to Vsphere in the next month or so, and the fact that the full backup would only need to be done once I don't think i need to investigate this further as once we are on Vsphere the block level tracking will kick in to substantially reduce synthetic backup time

All the best
Andy
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Speeds using Storage API

Post by Gostev »

Andy, sounds good - thank you!
antivir
Enthusiast
Posts: 63
Liked: never
Joined: Nov 04, 2009 2:39 pm
Full Name: Andrew
Contact:

Re: Backup Speeds using Storage API

Post by antivir »

Gostev wrote:Hi Andy, please do this:
- Check if CPU is not a bottleneck during backup on Veeam Backup server
- Try to backup to another storage (locally to Veeam Backup server hard drive, for instance)

If you cannot find any issues, I will give you a test tool which simply reads data from SAN and discards it without any processing, this way we will be able to understand where the bottleneck is.
Can I get that tool too?
Thank you.
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Speeds using Storage API

Post by Gostev »

Unfortunately it appears not to work well right now due to significant changes in the shared components since early beta. If devs have some free cycles, I will ask them to polish it.

If you have some performance issues, feel free to contact support.
DougBaer
Novice
Posts: 4
Liked: never
Joined: Dec 15, 2009 5:19 pm
Full Name: Doug Baer
Contact:

Re: Backup Speeds using Storage API

Post by DougBaer »

For whatever it is worth, 50 megaBYTES a second is not bad performance for local storage. Depending on how many disks you have in the local RAID and how much cache you have on your array controller. 100 MB/s sustained is pretty much the max I've seen from 15K drives... without any RAID overhead or competing workloads and 100% sequential read.

You can see here http://www.pcmall.com/p/HP-SAN-Hard-Dri ... dp.dhdedei that HP even says that their "3.0 Gb/s" SAN drives that go in most Proliants "offer data transfer rates of up to 3.0 Gb/s for short bursts. Sustained data transfer rates vary with drive speed, capacity and model but are typically 50 to 90 MB/s in sequential."

Hope that helps :)
Gostev
Chief Product Officer
Posts: 31814
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Speeds using Storage API

Post by Gostev »

Doug, this is interesting information indeed. Thanks for sharing!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 85 guests