-
- Service Provider
- Posts: 27
- Liked: 2 times
- Joined: May 10, 2010 2:16 am
- Full Name: Steven Vallarian
- Contact:
Decent speed - Lefthand SAN - but can it be better?
Using an HP DL380 with a single E5520 (Quad Core) processor, 6GB Ram, but i'm only using 4GB since I'm running 32-bit Server 2008.
Dedicated iSCSI network card to make a connection to the SAN
7 1TB local drives for staging backups
vSphere 4.0, no updates (yet)
Backing up 3x ESX hosts at the same time.
Each ESX host has about 16 VMs on them.
On the VM's I'm getting between 6MB-70MB/second. Using SAN mode with changed block tracking.
I've noticed on the larger VMs that are running SQL servers, I'm getting the lower processing rate, usually around 15MB/sec, but it drops to 6MB/sec quite a lot and it's blowing my backup window out.
Here's what I've tried so far (all forum suggestions)
Changed compression level from optimal to best
Disabled autotuning on the OS networking
Changing write cache on raid controller (but I changed it back after testing)
Copying files to/from the datastore went quickly, I was able to transfer a 300MB ISO in about a minute.
I"m using backup exec 12.5 to spool the veeam backup files to tape but only after veeam is finished running. I'm getting 56MB/sec writing to tape.
Does anyone have any ideas on what to try next? Or have I exceeded my hardware?
Dedicated iSCSI network card to make a connection to the SAN
7 1TB local drives for staging backups
vSphere 4.0, no updates (yet)
Backing up 3x ESX hosts at the same time.
Each ESX host has about 16 VMs on them.
On the VM's I'm getting between 6MB-70MB/second. Using SAN mode with changed block tracking.
I've noticed on the larger VMs that are running SQL servers, I'm getting the lower processing rate, usually around 15MB/sec, but it drops to 6MB/sec quite a lot and it's blowing my backup window out.
Here's what I've tried so far (all forum suggestions)
Changed compression level from optimal to best
Disabled autotuning on the OS networking
Changing write cache on raid controller (but I changed it back after testing)
Copying files to/from the datastore went quickly, I was able to transfer a 300MB ISO in about a minute.
I"m using backup exec 12.5 to spool the veeam backup files to tape but only after veeam is finished running. I'm getting 56MB/sec writing to tape.
Does anyone have any ideas on what to try next? Or have I exceeded my hardware?
-
- Chief Product Officer
- Posts: 31779
- Liked: 7279 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
Check out this thread, I explained why it is normal to have slower backup speed on Exchange and SQL servers. In the end it appeared hardware issue in that particular case anyway, but generally the points are made there are still valid.
Slow VM backup with SQL Server 2008 R2
Slow VM backup with SQL Server 2008 R2
-
- Veteran
- Posts: 387
- Liked: 97 times
- Joined: Mar 24, 2010 5:47 pm
- Full Name: Larry Walker
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
I have the lefthand san, my veeam server is not as strong as your. I backup a 500 gig SQL data base nightly.
The normal rate with change blocks is over 500 MB/s but more important is that the full rate is 60 mbs. To see if it is a transport issue ( iscsi ) you can clone the vm, leave it off and do a full backup. if the spped is still poor then the issue is not that it is a SQL server but the size of the data. I get 8 mb/s over my 100 mb WAN.
The Veeam server should be on the same IP network as the lefthand.
When my first put the lefthand in I had a switch issue, when I cloned large VMs from one SAN to the other my thoughput dropped to a crawl. The easy way to test is to use just one nic from each lefhand box if your though put go's up then that is where the issue is. I did it during the day and no one knew, just unplug on nic on each box. I had a hard time getting the round robin working right beteen the lefthand and the ESX 4 servers. On the lefthand forum I posted a word doc. After I got it working my though put shot way up on big jobs, small jobs stayed the same. Time to clone large VM's dropped 75 percent.
The normal rate with change blocks is over 500 MB/s but more important is that the full rate is 60 mbs. To see if it is a transport issue ( iscsi ) you can clone the vm, leave it off and do a full backup. if the spped is still poor then the issue is not that it is a SQL server but the size of the data. I get 8 mb/s over my 100 mb WAN.
The Veeam server should be on the same IP network as the lefthand.
When my first put the lefthand in I had a switch issue, when I cloned large VMs from one SAN to the other my thoughput dropped to a crawl. The easy way to test is to use just one nic from each lefhand box if your though put go's up then that is where the issue is. I did it during the day and no one knew, just unplug on nic on each box. I had a hard time getting the round robin working right beteen the lefthand and the ESX 4 servers. On the lefthand forum I posted a word doc. After I got it working my though put shot way up on big jobs, small jobs stayed the same. Time to clone large VM's dropped 75 percent.
-
- Veteran
- Posts: 387
- Liked: 97 times
- Joined: Mar 24, 2010 5:47 pm
- Full Name: Larry Walker
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
forgot to add that my backupexec rate is 2000 MB min. I have HP LTO 4 SAS drive.
-
- Enthusiast
- Posts: 33
- Liked: never
- Joined: Jun 09, 2010 11:16 pm
- Full Name: Brian Kellogg
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
I was seeing the same issue with some of my VMs. The problem is that you can't compare Veeam backup throughput to backup exec. We used Backup Exec prior to switching to Veeam as well. Backup Exec streams writes and then reads when it switches to verify mode. Veeam is constantly reading and writing so the heads on your backup target are constantly being moved in a non linear fashion thus reducing throughput. When monitoring a Veeam backup I saw around a 2 to 1 write to read ratio; at some points the ratio was 1 to 1.
I moved my backup target from an older NAS to a newer NAS and saw a 40% to 60% bump in throughput. The newer NAS is still a SATA array, but it is faster. I'm still not seeing incredible throughput, but it is acceptable. This was the resolution to my throughput problem at least.
I moved my backup target from an older NAS to a newer NAS and saw a 40% to 60% bump in throughput. The newer NAS is still a SATA array, but it is faster. I'm still not seeing incredible throughput, but it is acceptable. This was the resolution to my throughput problem at least.
-
- Chief Product Officer
- Posts: 31779
- Liked: 7279 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
Just wanted to point out that Veeam Backup v5 adds backup mode with "forward" increments, where full backup file is no longer rebuilt during each incremental backup pass. So those with slower backup storage, or looking for fastest backup performance and shortest backup window may prefer this mode instead. The drawback is that latest backup file is no longer full recovery file, which can be really convenient in some disk-based backup scenarios.
-
- Enthusiast
- Posts: 33
- Liked: never
- Joined: Jun 09, 2010 11:16 pm
- Full Name: Brian Kellogg
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
For us this is an awesome change as after Veeam finishes we copy the latest backup to another NAS. This would cut our backup window and offsite copy by a huge amount I believe. Thank you!
Would this adversely affect restore speeds?
Would this adversely affect restore speeds?
-
- Chief Product Officer
- Posts: 31779
- Liked: 7279 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Decent speed - Lefthand SAN - but can it be better?
No, there should not be any noticeable differences.
Who is online
Users browsing this forum: Bing [Bot], Semrush [Bot] and 83 guests