Slow Backup Speed

[sebastian]

Hello,

my case ID is 01855049.

since we got Veeam we have poor Backup speed at our environment. The Bottleneck has been always pointed at our Source (SAN Storage).
We got slow write speeds (around 50MB/s) when we backup VMs from the DELL SAN. What could be the misconfiguration in our environment?
Is it right, that we need a FC card in our QNAP for fast speed when backup VMs from the 3PAR?

Our environment:
-vCenter
-14 ESXi Hosts
-2x HP 3PAR 8200 active/active (Datastore for SQL and DAG Cluster) 16GbE FC
-2x DELL Equallogic PS6510 active/active (Datastore for all other virtual maschines) 10GbE iSCSI
-1x QNAP TS-EC2480U with a 10GbE network card, 14x8TB configured as RAID 5

We have arount 130 VMs in our vCenter.
On every ESXi Host a Backup Proxy is installed (Windows 7, 4 Cores, 8GB RAM and an Connection to the iSCSI network)

Backup Server:
-16 Cores
-48GB RAM
-10GbE network card for iSCSI network
-FC cardfor 3PAR connection

Best regards

Sebastian

[foggy]

Hello Sebastian, what transport mode is being effectively utilized to retrieve VM data from the source storage? You can check that by opening the job statistics, selecting the VM in the list and looking for the proxy selection record - there will be a transport mode tag at the end ([san]. [hotadd], etc.). Is source reported as bottleneck for both your storages (3PAR and Dell)?

[Vitaliy S.]

Is it right, that we need a FC card in our QNAP for fast speed when backup VMs from the 3PAR?

No, since bottleneck is reported as source now, then upgrading connection to your repository will not help.

[sebastian]

VMs which are stored at the DELL SAN, there is mostly "san" and sometimes "hotadd" mentioned.
VMs which are stored at the 3PAR SAN, there is mode storage snapshot mentioned. In my opinion, this is correct.

The bottleneck "source" is reported at both storages.

@Vitaliy

Ok, this sounds right. Especially when the bottleneck pointed at "source" there would be no benefit if the QNAP had an FC connection.

[foggy]

Everything seems to be configured correctly in terms of source data retrieval. Bottleneck source means that your production storage cannot provide data any faster.

[Vitaliy S.]

One thing that might improve the performance is the update of firmware/drivers for the given datastores. Also our support team should have a utility that tests vStorage API data retrieval performance, might be worth trying.

[sebastian]

Everything seems to be configured correctly in terms of source data retrieval. Bottleneck source means that your production storage cannot provide data any faster.

But isn´t ~50-100MB/s write speed a little slow for such a big DELL SAN?

So i will wait for an info from the support team for testing the vStorage API.

The 3PAR is up-to-date and the DELL SAN will updated in the next days.

[foggy]

Are you referring to the read speed probably? Anyway, 100MB/s is pretty good.

[sebastian]

Well, here´s a screenshot from a Active Full Backup from our Fileserver, i think the speed isn´t quite good. The Fileserver is located at the DELL SAN.

[foggy]

Do you observe similar picture for all processed VMs?

[sebastian]

Yes, most of them, but not all. The VMs on the 3PAR have more read speed, from 60 to 375MB/s.

I´ve got another question relating to the Backup repository. What is the best way to add the QNAP NAS. iSCSI-LUN, CIFS, NFS?

[Vitaliy S.]

It's generally recommended to use iSCSI, please look through existing topics with a similar question > search.php?keywords=qnap+iscsi&fid%5B0%5D=2

[NightBird]

I often don't understand customers
Great San storage, crapy backup repository storage (qnap)... To be or not to be...

[skrause]

I think you might want to look at going with something other than RAID5 with 8TB disks. Just thinking about doing a rebuild on that size disk gives me the willies.

[DaveWatkins]

This likely won't help, but why do you have a Veeam Proxy on every ESXi host? If you have shared storage then you only need enough proxies to be able to keep up the speed your repo can handle