Change from direct SAN to network speeds up backup.

[readie]

I have setup direct SAN access for my backups, expecting that it should be the fastest.

I noticed one night that a particular Exchange 2010 server had failed direct SAN and failed over the Network, and the backup took about one quarter of the time it had been taking! From 3 and a half hours, to under one hour.

This particular server had always been reporting hundreds of 'Map Disk Region' while backup up, so perhaps this was slowing down the direct SAN??

I changed all my backup proxies to network (rather than automatic) and this server is still taking under an hour, though all the other backups are taking roughly the same time as they were before.

Is it worth my changing the other servers back to automatic selection . . . which is difficult, as the setting is per Proxy, rather than per job . . . or just leave them on on network. We have got a 10GB network between the production and backup infrastructure.

Thanks for any suggestions. In one sense, 'if it ain't broke, don't fix it' tempts me to leave well alone, as it is all working fine.

Bob

[foggy]

Bob, I'm not surprised that backup using network mode on 10GB Ethernet flies, it actually should. What are the bottleneck stats for your job both for direct SAN and network modes and what performance do you get for both of them?

Regarding "map disk region" errors, those are typical for direct SAN in some circumstances, though I'm not sure whether they could affect performance.

[dellock6]

The effect should be minimal, and not impacting performances. The fragmentation is at the vmdk level, so whoever reads it (Veeam directly via DirectSAN or the ESXi for other methods) gets the fragmentation impact. DirectSAN has also to get the lease of the blocks from VMFS, but I don't feel this operation is reducing performances.
As usual, the best maintenance activity to do is to run a storage vmotion so to remove the fragmentation of that disk. This helps regardless of the backup method that is used.