vsan backup to iscsi design considerations

[tntteam]

Hello there,

We are moving from standard infrastructure (ESXi with FC storage and dedicated physical Veeam server with FC direct acces, backing up to FC storage) to vSAN storage.

Our vsan is stretched cluster with PFFT=1 and SFFT=1 / erasure coding. So basicly every ESXi vsan node has access to a portion of data of each VM.

We are in the design phase for veeam. As we understood, we need to deploy veeam proxy appliance (1 per ESXi).

Our backup target is a iSCSI storage.

We have the following questions that may be some of you could help us about :

- Is that correct that the iSCSI backup target storage is connected to the main veeam server and only (aka not connected to veeam backup proxies)

- So it's correct to assume that data will flow like this :
vsan---(hot-add)--->Veeam backup proxy ; Veeam backup proxy ---(network IP)--->Veeam main server ; Veeam main server ---(iSCSI)---> iSCSI storage array

-Would it be possible to connect Veeam repository on iSCSI array to every proxy appliance and skip Veeam main server during backups ? I mean by this connect the same storage repository like a cluster shared disk between veeam proxy appliances.

-What would be recommended to connect iSCSI storage to veeam ? Using iSCSI on ESXi hosts, then create vmfs, vmdk and connect to veeam OR use iSCSI initiator inside windows where Veeam is setup ?


Thanks for your help !

[foggy]

You'd definitely want proxies to write directly to repository, leaving only management tasks to the backup server itself. Using Windows iSCSI initiator is recommended (so that backups are not stored on VMFS - unnecessary additional layer).

[HannesK]

Hello,
yes, one proxy per ESXi host is best for performance.

For the target storage: there is the "repository" role which is currently not in your concept

depending on the amount of data, I would try to go with one big repository as that would simplify the concept. If every proxy would also be a repository to write directly to iSCSI, then you would end up with tons of small repositories. But that depends on personal preferences.

Best regards,
Hannes

[tntteam]

Hello,

Thanks for your answers !

To be sure to understand you, if we connect our proxy appliances to iSCSI storage, they will not be abble to share the storage repositories between them (proxy appliances) ?

I mean, if we make a 60TB iscsi space to receive backups, and connect each proxy appliance to this storage, they will have separate folders.
So if a VM A is backuped up by proxy 1, using forever incremental, proxy 2 will not be abble to backup VM A using the same forever incremental chain, it will start a new chain on its own repository, correct ?

Amount of data is not easy to give but on our current architecture we have 90 TB of backup data splitted between 4 repositories of various sizes between 10 and 60 TB.

So for you, the way to go would be :
1 main veeam server, that would be the orchestrator
1 repository server
1 proxy appliance per ESXi

And connect the iSCSI storage into repository server using microsoft iSCSI initiator and not VMware.

[HannesK]

Hello,
it might be a little confusing, but a proxy role cannot be connected to iSCSI. It can only do backups. The repository role can write to iSCSI.

The repository role and proxy role can be on the same system (as it is on the backup server)

A repository can be shared between different proxies. So you could make every proxy VM a repository and add an iSCSI LUN to each proxy / repository VM. But by doing that, you will end up with tons of small LUNs. Proxy-Repository-VM1 could also write to Proxy-Repository-VM2

So for you, the way to go would be :
1 main veeam server, that would be the orchestrator
1 repository server
1 proxy appliance per ESXi

And connect the iSCSI storage into repository server using microsoft iSCSI initiator and not VMware.

correct maybe a second repository if you run into bandwidth issues.

Best regards,
Hannes

[tntteam]

Sorry my english is lacking and I'm not understanding quite well your latest answer

So you could make every proxy VM a repository and add an iSCSI LUN to each proxy / repository VM. But by doing that, you will end up with tons of small LUNs. Proxy-Repository-VM1 could also write to Proxy-Repository-VM2

If I understand correctly, you mean by this that :

if VM-A is backed up by ProxyRepo1 on iscsi LUN1,
ProxyRepo2 can backup VM-A too but it wil do it via ProxyRepo1 to be saved on iSCSI LUN1 ?

Maybe if I ask you the other way arround :

Have 1 LUN1 (on iSCSI) say-60TB, connected to multiple Veeam ProxyRepo1, 2, 3 (so they all have access to the same iscsi disk)
Would it be possible to :
- backup VM-A, using ProxyRepo1
- VM-A get vmotioned to another ESXi
- Backup again VM-A but this time ProxyRepo2 is chosen by Veeam (data goes via ProxyRepo2 to iSCSI LUN1 without going via ProyxRepo1)
- Have that backup keep the incremental chain that was started with ProxyRepo1

Another way to say it is, are veeam appliance able to share one iscsi disk like microsoft clustered disk and be able to read and write concurrently on this disk ?

[HannesK]

Hi,
no problem - I'm also not a native speaker

ProxyRepo2 can backup VM-A too but it wil do it via ProxyRepo1 to be saved on iSCSI LUN1 ?

yes, that's correct

Have 1 LUN1 (on iSCSI) say-60TB, connected to multiple Veeam ProxyRepo1, 2, 3 (so they all have access to the same iscsi disk)

this is not possible with block devices (iSCSI / Fibrechannel) except for cluster configurations (different story there and not applicable here)

To keep it simple, I recommend one (or maybe two for more performance) dedicated repository VMs. As an alternative one physical repository.

Best regards,
Hannes