Low processing rate via direct san access

[lsolty]

Hello everybody,

I have read some interesting posting about using the direct san access mode. It is said to be the fastest way of creating backups. We bought some new hardware including a equallogic ps6100 storage device and changed the setup of the veeam proxy to backup directly through san. I am very disappointed with the processing rate, as it is nearly the same like before, when we were using the network transport mode.

The setup:

Veeam Backup & Replication 6.5 is installed on a physical Server (HP ProLiant 180G6) with plenty of local disk space. The OS is Windows Server 2003 x64.

The Backup Proxy runs on the very same machine. The transport mode is manually set to DIRECT SAN ACCESS with no fall back to network transport mode (just to be sure that the right transport mode is beeing used).

The Backup repository is the server's local disk space.

I have two GB NICs in the server, the first one connected to our local LAN, the second one connected to our SAN. The connection to the SAN is configured with the Microsoft iSCSI Initiator.

When performing a full backup of a 30GB VM (running on an ESXi 5.1 Server, the DATASTORE is in the SAN on shared storage), the processing rate does not exceed 20 MB/s. I have read about and seen screenshots of far better performance values, so I am wondering, what goes wrong here.





By the way, the bottleneck has always been the target with 99%, but the target server has plenty of CPU power and sufficient RAM, much local disk space and there is nothing else running there...

Any ideas?

Thank You in advance!

[Helqasem]

Hi,

Direct-SAN seems to be working well at the front end.

What's the disk configuration on the server? How many disks, size etc?
How many CPUs and how much RAM does your server have?

What does disk activity look like in performance monitor during backup?

[chrisdearden]

That local disk bottleneck isnt about space , its about performance. For example , if that was an SSD , I would expect it to run a lot faster , but if its a consumer grade Sata disk already shared by the OS , then I would be less suprised.

[foggy]

Yes, bottleneck target indicates that the job is waiting for the target storage to write the data most of the time, which results in overall low processing performance. Most likely the reason in the local disks. Could you perform test backup to some other storage to see if that is the case?

[Cokovic]

Which controller do you use in your HP server? Do you have a battery cache or flash cache installed? With Array Configuration Utility you can check your controlles specs from within the Windows OS.

Performance of local disks on HP servers highly depend on the controller and if it has a battery backed write cache (BBWC) or flashed backed write cache (FBWC) installed. If not HP servers disable by default write cache on local disks and then the performance is terrible. You can override it in the controller configuration so caching is actived even with no BBWC or FBWC installed (but it's not recommended as you are going to damage your data if there is a power outage).

[lsolty]

Hello everybody,

thanks for Your hints and answers.

I have solved the problem by reinstalling the OS from the scratch following by a new installation of the Veeam Backup & Replication (I did not import any pervious settings of Veeam B&R). However, instead of Windows Server 2003 I installed Windows Server 2012. I have not changed anything on the hardware. The result is an overall good performance (8x faster as before). Something must have been very buggy in the previous Windows 2003 installation, maybe the NIC driver or whatsoever. Anyway, I am now very satisfied with the performance and the very very fast backups.

[foggy]

Glad you've solved it and are getting high speeds now. Thanks for the update!