Type of repository, which one?

[ISM_Christian]

Hello!

We have a couple of VMWare server two different cluster (manage by the same vCenter). Each cluster has their own storage (one has 1 SAN + 2 expansion with fiber-channel, the one 10gbps via iSCSI on 10gbps switch). The repository are 2x dedicated vmware host with Local disk (2x RAID 10 per host), with vmware on a USB stick.

Each Backup server has a VM, that is stored on the iSCSI SAN. We would like to add more storage, with a lwoer budget, has dedicated host have higher price than QNAP NAS.

Veeam is configured this way: we have 1 proxy per host in the each cluster. We do forever incremental.

I know the best practice is to have Physical server instead of virtual, but easier to manage. My question is: Considering we have good performance with a lower budget (more space has some VM are big), a QNAP NAS using SMB, using a gateway proxy for processing the merge file locally?

What would be the best practice? Any suggestion is appreciated


Thanks

[Rick.Vanover]

One thing, even if you only have 1 repository, I would recommend using the Scale-Out Backup Repository. See this post: https://www.veeam.com/blog/scale-out-ba ... itory.html

I generally recommend physical components as they simply perform better *and* will not skew your VMware DRS performance during the backup time. However, it is fine to have the Veeam infrstructure virtualized. I do however recommend having your backups out of the VMware infrastructure. On the NAS device - we find that iSCSI performs better - yet SMB is easier to set up. So we'll leave that up to you.

My recommendation is to put forth a backup storage for each cluster that has the following characteristics:
-As separate from the vSphere Cluster it is backing up as possible (in case vSphere is the problem)
-As highest performance as you can afford (consider if you want to do DataLabs, Instant VM Recovery, etc.)
-Maybe introduce 2 storage systems for backup and leverage the backup copy job. Meaning, a small but high performance storage resource for the first 1 or 2 days of backups - then something that is slower but higher capacity and less cost for the long term retention (Say 1 month).

Just a few ideas here. It's hard to pick a single recommendation with specifics without a consultation. Maybe reach out to your sales team where you bought Veeam or VMware - and they can advise some storage or configuration options?

[ISM_Christian]

Thanks for responding!

-Having backups out of the vmware infrastructure --> The Backup hosts are standalone Server, not in the cluster, only joined to the vCenter. I have a offsite server/QNAP with Backup Copy configured, which is working fine. But I guss the proxies could be out of the DRS environment?
-For performance, we are not looking for instant VM recovery. We can wait for the time to restore.
-Scale-out, I didn't thought about it but it would be a good idea, this could resultat in a better performance, since incremental would be on a different datastore and the merge would be using 2 Array instead of one.

We were using ReFS, but I had an issue on a volume, where the entire ReFS volume crashed and can't be repaired, went back to NTFS.

As for iSCSI, this is nto a problem, it's only because I had bad experience last time with QNAP iSCSI, having it to disconnected for no reason.

[Rick.Vanover]

-Having backups out of the vmware infrastructure --> The Backup hosts are standalone Server, not in the cluster, only joined to the vCenter. I have a offsite server/QNAP with Backup Copy configured, which is working fine. But I guss the proxies could be out of the DRS environment?
//That is a really good step, logical separation.

-Scale-out, I didn't thought about it but it would be a good idea, this could resultat in a better performance, since incremental would be on a different datastore and the merge would be using 2 Array instead of one.

// Really - *all* repositories should be managed in a SOBR context. This helps a lot in the following situations:
-Device full
-Device fail
-Device return on lease or end of life
-Scaling

[ISM_Christian]

Great, thanks for the info. That will help out.

if using multiple NAS for storage:

-SMB: Will need a gateway for merging file? Using 1 gateway server could be a bottleneck?
-NFS/iSCSI: will need to be mounted to a Host directly or via iSCSI in windows (Which I don't really like).

Repo servers got: 4x 1gbps, 2x iSCSI (for the VM) and have around 24gb of ram, 12 to 16 vCPU has they are dedicated host. I guess using them has gateway event for SMB NFS/iSCSI/, there shouldn't be any issue?

Which one would you suggest? We also use RAID 10 for faster performance and rebuild time in case of failure. Off-site is using 2x RAID 5


Saying it again, thank you for the time you take to answer

[Rick.Vanover]

Hi Christian:

Sound like you prefer SMB, which you can build into the Scale-Out Backup Repository as an "extent" - which is just the name of the underlying repository.

As for bottlenecking - you'll not know until you run a job - There are many variables - frequency of job, change rate, source data size, etc. And your repo sounds rather powerful, so that's good.

If the repository is on the Repo server - if you have the proxy role and repository role on the same system - you'll have the best performance option - as all manipulations are local file system tasks versus the network protocol. So if you had the repository, proxy and gateway on same instance of Windows- that is ideal for performance. Does that make sense?