report about backup repository gateway usage

[pirx]

Hi,

#04394925

in Veeam One I can see the top proxy servers, in RTS log or with powershell I can see the current concurrent tasks for repositories and proxies. Where - other than the detailed logs - can I see the usage of gateway server for copy or offload tasks? We have 6 server that act as proxy and CIFS gateways. I've a pretty good overview about the backup proxy tasks but I can't find similar for gateways. I'm just wondering because two newly added servers do not have much load. On the other hand support claims that we still have ressource problems on processing side.

[HannesK]

Hello,
as far as I understand the message from support from Monday, the software behaves like expected.

The logic is that the source job (backup) will have priority, followed by the backup copy job and then by offload. This is by design and it seems that it is more important for us to protect the data rather than trying to free up space on the repository. Due to this, tasks such as GFS transforms will take precedence over Offload tasks.

GFS transforms are "synthetic operations". Synthetic operations are performed by the mount server https://helpcenter.veeam.com/docs/backu ... ml?ver=100. That's why I assume that adding more proxies did not help.

That's actually the reason, why we strongly recommend block storage as Veeam target. SMB (especially for your environment size) is the worst choice possible (especially with the storage you use). I saw that you are already thinking about XFS and can only recommend to continue that way. I also recommend to not try XFS / REFS on Netapp FAS systems. Yes, it's faster than SMB, but the Netapp "intelligence" is counter-productive. XFS / REFS works best on "dumb storage". If that's not possible, then you can try out active full backup copy jobs. They do not merge and usually make it faster for SMB targets.

https://helpcenter.veeam.com/docs/backu ... ml?ver=100 - "Read the entire restore point from source instead of synthesizing it from increments"

You can expect around 3.5Mbyte/s per physical disk in your storage for the merges. Adding more compute does not help in fixing IO issues.

Best regards,
Hannes

[pirx]

Hi Hannes,

thx for your reply. I don't have the "Read the entire restore point from source instead of synthesizing it from increments" option if I edit a existing BCJ.

I'd still be interested to get an overview of the gateway load, do you have an idea for that?

[pirx]

I just found out that "Read the entire restore point from source instead of synthesizing it from increments" is not available with Immediate copy mode.

[HannesK]

yes, it's only available for the periodic backup copy job. But my experience with it is very good for NAS systems (from low-end to high-end)

I would suggest to log into the gateway server / mountserver and look with windows built-in or sysinternals tools. But chances are high, that it looks like "doing nothing". I have seen it a couple of times with scale-out storage systems... every system says "I'm idling" and after months somebody finds load on the storage side. If I remember correctly, then Netapp shows the load of the disks somewhere pretty nice.