SAN Mode in restore

[kanand72]

I'm using VBR 11 with a HPE Storeonce data appliance and HPE Primera storage. We have a VMWare environment
I have a physical WIN proxy which is configured with direct SAN access.
I am able to do VM backups with SAN mode using this physical proxy.
However, when I am trying to restore, SAN mode is not being used.
I have changed the disk mode to THICK Eager when restoring.
I did a rescan of the proxy under Managed Servers.
Still no luck. I read that for restore operations with SAN mode, " [For restore operations] A backup proxy must have write access to LUNs where VM disks are located. "

I have not done this .....Is this required ?

Thannx
Anand

[HannesK]

Hello,

I have not done this .....Is this required ?

to write something to somewhere, write permissions are needed, yes.

That means, the VMware volume / LUN is visible as "offline" in the Windows disk management.

I assume that you do backup from storage snapshot? Then there are probably no read / write permissions for the datastore because read permissions are created on demand for the storage snapshot only.

Best regards,
Hannes

[kanand72]

HI Hannes,
Yes, I exported the LUN to the proxy and it picked up SAN mode for restore job.
So thats taken care of.
My main issue why I wanted to use the SAN mode was that I was getting low speed in restore. I had done a restore with Hotadd mode and I was getting a restore speed of about 160 MBPS ..Even with the SAN mode, the speed was roughly same.

Where could the bottleneck be ? I'm sure this is a very generic question but any pointers on how to troubleshoot this would be great.

[HannesK]

Hello,

My main issue why I wanted to use the SAN mode was that I was getting low speed in restore.

HotAdd is faster in most cases over direct SAN restore. The bottleneck can be backup storage, the production storage (is it a mirrored peer persistence volume?) or network. That's something you need to investigate. Disk test tools (e.g. diskspd) and network performance test tools (e.g. iperf) can help.

160MByte/s for direct SAN for one disk sounds okay. In general, restore (also backup) benefits from parallel restores.

If you have a synchronous mirrored storage, I suggest to try restoring to a non-mirrored volume.

Best regards,
Hannes

[kanand72]

Why would HotAdd be faster over direct SAN ? I was under the impression that direct SAN would be faster than HotAdd since in HotAdd, traffic would probably be going over the vmware management vlan or the backup vlan ...
In our setup, we have provisioned 3GBPS for backup vlan and 1gbps for vmware management vlan. Whereas the SAN is over a 16G FC.
We are using HP Storeonce as a dedup backup repo.. Could that be the bottleneck ?
The storeonce also has a VTL interface.. Can I try to see of that increases the speed ?

[HannesK]

I was under the impression that direct SAN would be faster than HotAdd since in HotAdd

assuming there are no other bottlenecks, HotAdd is usually faster because it can do async IO. Vmware VDDK does not allow that for direct SAN restore. Veeam support can help you testing your SAN performance with vixdisklib. Sure, if the network is slow, then HotAdd would be slow

We are using HP Storeonce as a dedup backup repo.. Could that be the bottleneck ?

sure, inline deduplication appliances have bad restore performance. that's "by design". StoreOnce should only be used as backup copy target. The Veeam reference architecture recommends stupid block storage (e.g. HPE Apollo servers) as primary repository for fast restores.

The storeonce also has a VTL interface

I cannot imagine that. and it would remove the single file restore capability. you can test it by doing a backup copy job to something "fast" (local SSDs).

[kanand72]

sure, inline deduplication appliances have bad restore performance. that's "by design". StoreOnce should only be used as backup copy target

Thanx for the clarification..

Regards
Anand