Can you give more details on your backup environment including the network?

the smb share is carried by a nutanix filer, the whole thing is connected on a 10GB network and the repository is an HP Storeonce bay.
I followed the best practices found in this KB :
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2017-Veeam-on-Nutanix:BP-2017-Veeam-on-Nutanix

Do you have the latest update for 11a installed from here - https://www.veeam.com/kb4245?ad=in-text-link

It adds many fixes and would be something to try to address this.

Hi @julmont  

Try adding a gateway server to support transfer to an smb repo?

Gateway Server - User Guide for VMware vSphere (veeam.com)

SMB (CIFS) Share - User Guide for VMware vSphere (veeam.com)

enjoy

@julmont 

I don‘t get from your first Post if you backup vms to a Nutanix Filer or if you use Fileshare Backup Jobs to backup a Nutanix Filer.

Start with analyzing the bottleneck. This gives you an idea where the bottleneck is.

@Link State 

If it’s about a SMB Backup Repo, then he has already a Gateway Server or the first backup wouldn‘t have worked. The Backup Server is also a gateway server.

Hi @julmont,

Can you please tell us which Hypervisors you are using? is Nutanix Files deployed on existing or standalone cluster? 

in such situation, as @Mildur said, start by analysing bottlneck. In addition, check about StoreOnce Best practices with veeam.

I'm going to start by playing the last update, thanks !

the smb share is carried by a nutanix filer, the whole thing is connected on a 10GB network and the repository is an HP Storeonce bay.
I followed the best practices found in this KB :
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2017-Veeam-on-Nutanix:BP-2017-Veeam-on-Nutanix

 

Hi @julmont  

Try adding a gateway server to support transfer to an smb repo?

Gateway Server - User Guide for VMware vSphere (veeam.com)

SMB (CIFS) Share - User Guide for VMware vSphere (veeam.com)

enjoy

I was not aware of the Gateway Server feature in Veeam. I'll look into it after I pass the last maj. thanks a lot

I use Veeam backup file share to backup my Nutanix filer.
 

The identified bottleneck is the source (Nutanix Filer)
Below is an example of a backup report on a file share

12/07/2022 08:00:24 :: Queued for processing at 12/07/2022 08:00:24  
12/07/2022 08:00:28 :: Required backup infrastructure resources have been assigned  
12/07/2022 08:02:12 :: Share processing started at 12/07/2022 08:02:12  
12/07/2022 08:02:12 :: Using backup proxy P4
12/07/2022 08:04:40 :: Source share size: 2792881 files and 338611 folders (2,2 TB)  
12/07/2022 08:04:40 :: 17 files and 16 folders (7,3 MB) transferred at 2 KB/s  
 2/07/2022 08:55:21 :: Backup metadata update completed successfully  
12/07/2022 08:59:04 :: Backed up 17 files and 16 folders (7,3 MB); skipped 5 locked files  
12/07/2022 08:59:05 :: Busy: Source 77% > Proxy 19% > Network 4% > Target 19%  
12/07/2022 08:59:05 :: Primary bottleneck: Source  
12/07/2022 08:59:05 :: Network traffic verification detected no corrupted blocks  
12/07/2022 08:59:05 :: Processing finished at 12/07/2022 08:59:05  
 

I use ESX version 7 on my Nutanix cluster, Files is deployed on this cluster.
Veeam/Nutanix/Storeonce best practices have been applied.
There is only the veeam gateway which is not deployed, I will document myself on this part

You don‘t need the Gateway Server. That‘s only used for the backup repositories and not for file share backup jobs.

And you have already one (backup server), if you have HPE StoreOnce as the backup repository.

If the source is the bottleneck, then that means Veeam has used the most time of the backup job to read the files from the source location. You need to start analyzing the source or optimize the read from the source.

Please make sure, that you have the Cache Repository next to the File Proxy and don‘t use a dedup appliance (your StoreOnce) for the Cache data. The cache is responsible for faster incremental backups. 
And dedup appliances are the worst for read performance. 

Hi @Mildur  and @julmont sorry,  I had interpreted that the backup repository was a share smb, "instead it is a nas backup with a dedup repo appliance.