Single block storage for 2 veeam proxy?

[nokogerra]

Hello there.
There is a storage Thecus 8810 (unified) which is planned as backup repository for veeam B&R (going to protect vSphere 6.0). We have an ability to make lan-free proxy (never did it before), but as far as I know I won`t be able to make rollback restore with this type of proxy (I guess there are some more restrictions with lan-free proxies). So we want to try 2 proxies:

1. lan-free, which will be connected to the production storage via iSCSI 10G with 4 paths and to the thecus with 1 path (this storage has only one 10g interface). This proxy will be used for such tasks as backups and full restores.
2. network proxy, which is going to be used for rollback restores and flr (I guess). Since rollback takes usually much less time than full restore, it will be OK that this proxy will contact with vSphere via 1G vmkernel interfaces.

Well, since Thecus has only one 10G interface and there will be no MPIO for backup repository, we decided not to carry about block level access from 2 hosts to single LUN and try to use SMB and NFS. However the copy speed was awful, it was about 150 mbps. Then we tried block access (iSCSI) and get about 350 mbps (stuck with disks speed and RAID penalty).

So iSCSI is preffered, but whats with the file system? NTFS and ReFS are not clustered FS, so we are concerned about NTFS and backup consistency. We don`t want to check backups maniacally everyday with SureBackup.

I guess there is a method which assumes making MS cluster of two these proxies and make CSVFS to use it as repository (specify C:\ClusterStorage\Volume as repo), but I really don`t know how B&R will react to this.

Can anyone share some thoughts about this situation?

[foggy]

Correct, incremental restore cannot be performed using direct SAN mode (all the direct SAN mode limitations are outlined in this user guide section). However, you can have a virtual proxy utilizing hotadd just for this type of restore, which will be faster than network. Built-in integrity and health checks ensure data consistency, however, periodic backups verification is still recommended to check their recoverability (you can have it less frequent).

[nokogerra]

Thanks for your reply.
I`ve read few articles about virtual proxy but still can`t get how it works. Will try it may be.

[EugeneK]

Think of it as a VM, running within the source or target vShpere environment.
During the tasks assigned to it, after the processed VM snapshot it taken for backup purposes, the Proxy HotAdd VM mounts to itself now read-only VMDK files for processing of their data (CBT, ideally). Once processed some bits of data, deduplicated/compressed etc, it sends this data over to the backup repository or replication destination, depending on the task/job assigned. Upon all data processing finished for a VMDK, it "unmounts" this disk from itself, releasing it for snapshot removal at the final stage of the VM processing.
Since Proxy VM is a VM, it allows to process up to 60 VMDKs concurrently, provided you allocate sufficient vCPU resources and tasks limit per Proxy is set to allow so;
The added benefit is an ability to send backup traffic not through the management stack of vmkernel to the target repository/environment, but also have an option to choose alternative network (for example, ESXi MGMT network is limited to 1G NICs, while you happen to have 10Gbps NIC you may want to leverage for backup traffic in this case).

[nokogerra]

Well fine, lets imagine I will use "hot-add proxy" for incremental restore purposes. But it will still use the same backup repository, i.e. the same LUN with NTFS as the las-free proxy. So NTFS corruption chance will still be high as if I use network proxy instead of "hot-add proxy". In case of incremental restore I don`t really care about speed, I`m just worry that 2 hosts will have block level access to the same LUN with NOT clustered FS.

[EugeneK]

The data integrity concerns are real, when it comes to the data stored on a backup repository, regardless of the storage type. However, it's not any different than the concerns around the regular server having NTFS/ReFS/Linux-FS etc; in fact, due to the internal code checks done for the processed data for backups are prone to less of those risks, than any average server with the same filesystem.

If the risk of having backup stored on NTFS/ReFS even with these checks done already is still concerning and to be addressed, it might make sense to follow 3-2-1 rule and have 3 copies of data, on two media types, one off-site.
Backup Copy Jobs to the secondary location with their own set of checks on top of already done ones and ideally - a different type of media (certainly physically different set of media) allows to mitigate the said risks.

Other than that, I got to say Veeam engine does a really good job on ensuring the data processed is validated and healthy; finding the balance between extra costs of extra storage and resources is what might help with the decisions to be made here.

[EugeneK]

In regards to the specifics of having two hosts accessing the same LUN: systems like proxy wouldn't be accessing the target repo as iSCSI device; instead, the proxy would establish a data mover connection between proxy and repo services, the data from proxy sent to repo for storing, then repo is the only thing touching the actual blocks of data.

[ddrrdd]

Why do you want 2 proxy server ?
The network proxy can be the lan-free server with the veeam automatic fall back to lan when lan-free fail.
The lower perf of your network proxy can easily be absorbed on your high perf lan-free server no ?
With this configuration, all your veeam repository access will be iSCSI to an exclusive LUN > no corruption.