For NAS backup bottlenecks, query what proxy really means

[JonJR]

We now have managed linux server File Share backups working. For the initial "big" backup Veeam is reporting that the bottleneck is the "proxy". This seems odd because we are using our main physical B&R server as the proxy and it seems to have plenty of resources, nothing seems to be maxed out - 10 cores are free as it 20GB of RAM, it's multiple 10G NICS which are less than 25% used and the disk isn't really being touched.

However the server (an Ubuntu VM) that is being backed up, is utterly slammed, we've had to increase RAM, Swap, Cores etc. and all the time it still shows as Proxy as the bottleneck, when it really seems to be the server - which I would have assumed should have shown up as a "Source" bottleneck?

So is the managed server actually a proxy or is the lack of resources from the managed server only being detected at the File backup Proxy level?

[Shestakov]

Hello Jon,
Something is always indicated as bottleneck even if everything flies.
Could you provide detailed bottleneck statistics with percentage(4 load numbers in per-share statistics)?
Thanks

[Dima P.]

Hello Jon,

So is the managed server actually a proxy or is the lack of resources from the managed server only being detected at the File backup Proxy level?

With Linux server added as file server there is no way to select proxies (Linux machine acts as a proxy on it's own). Mind me asking, why you want to protect Linux machine via NAS backup functionality, instead of using Linux agent? Cheers!

[JonJR]

Mind me asking, why you want to protect Linux machine via NAS backup functionality, instead of using Linux agent?

Curiously it's actually a Linux VM which we already backup with a regular Veeam VMware snapshot backup, but for reasons we're using LUKS to encrypt the drive and whilst I have faith in our implementation I wanted an additional "Files Only" backup just in case... and in fact we were doing an agent backup to achieve this with v9.

What I really like about the NAS backup is that rather than doing its retention on restore points, it does its retention on versions of each file. Hence I can run a backup every hour and not worry about retention limits or creating big backup chains. Soon we'll do a secondary copy to S3, which again (I think) we'll be able run every hour too.

Also for a for this file server (about 1TB), the agent backup took about 1.5 hours, whereas the NAS backup takes 10 mins

Finally, moving forward we have have several big (to us they are big!) 20TB file servers which we backup via snapshots, on which there might be one or two file shares that we want to offer extra protection on and rather than having to place those files on their own file server, we can instead run another more frequent agent/NAS backups just for the smaller subset of files.

[Dima P.]

Hello Jon,

Thank you for the details!

What I really like about the NAS backup is that rather than doing its retention on restore points, it does its retention on versions of each file.

Technically the retention is set for the backup (but is applied to the files within). Say, if you have set the retention to two days, the backup will keep all the file versions detected during backup job runs for the past two days. Retention based on file versions is available for the archive repository. With this setting you can control how may file versions to keep in the backup. You can set this up at Backup Storage Settings > Archive repository > File masks.

the agent backup took about 1.5 hours

Is that file level backup or volume level backup? What version of Linux agent is used?

moving forward we have have several big (to us they are big!) 20TB file servers which we backup via snapshots

Mentioned servers are Linux VMs too? Cheers!