VBUR Performance with Synology NAS as a backup target and/or backup copy source?

[Wad4iPod]

Hello and Thanks in advance for any help.

I have been attempting to figure out why our Synology NAS backup (VBR) performance has been sub-par at 5 MB/s (bottleneck at target). We have backup copy jobs that use this source backup file(s). This copy job has a direct attached USB 3 target repository. The jobs run about 20-24 MB/s (bottleneck at source).

All Synology NAS' we have are running the latest DSM.

I had surmised this performance degradation(s) could be related to SMB 1/2/3 configurations.
Browsing the www I have found others/posts that have encountered similar performance issues with the Synology NAS devices. I don't recall if they were all specific to VEEAM repositories or other application type. There was mention of AD named accounts vs local NAS accounts, IP vs. DNS named access - as plausible performance degradation reasons/remedies.

However, I now [working through the three sites below] believe it is related to one, or a combination of, these configurations below.
• NAS domain joined and using DNS Name to access the CIFS Share.
• NAS domain joined and using a AD named account to access the CIFS share.
• NAS domain joined and SMB v1/2/3 performance metrics - in play - what might they be?

The first thing I would like to try is changing the existing repository definition from DNS named to IP address.
What is the recommended process for doing this without losing my existing backups?


Site 1:
I am working with BUR v9.5u4 running on a Windows 2012R2 VM Guest (ESXi v6+). This is my proxy and application VM for VEEAM. The VEEAM Proxy mode is set at Network. This VM is backing up itself and running on the same ESXi host as the VM's I am backing up.
The target repository, a CIFS/SMB v3 share (Max SMB v3 min SMB v2), is a Synology 1513+ NAS.
The NAS is domain joined (Windows AD). Currently, we are using a permissioned AD account to authenticate the VEEAM repository (Synology NAS) CIFS share. The configured path in the repository properties is: \\DNSName\share.

'Do not reserve disk space when creating files' is selected on the NAS' SMB settings.
VM Networking (Infrastructure) is 10GB. Physical Networking is 1GB.


Site 2:
At another site. BUR v9.5u4 running on a Windows 7 x64 Pro VM Guest (ESXi v5.5). This is my proxy and application VM for VEEAM. The VEEAM Proxy mode is set at Network. This VM is backing up itself and running on the same ESXi host as the VM's I am backing up.
The target repository, a CIFS/SMB v1 share (SMB v1 and v2 soon to be disabled), is a Synology 1512+ NAS.
The NAS is domain joined (Windows AD). Currently, we are using a permissioned AD account to authenticate the VEEAM repository (Synology NAS) CIFS share. The configured path in the repository properties is: \\DNSName\share.
'Do not reserve disk space when creating files' is selected on the NAS' SMB settings.
VM Networking (Infrastructure) is 1GB. Physical Networking is 1GB.

Same Synology NAS backup (VBR) target performance has been sub-par at 5 MB/s (bottleneck Target).


Site 3:
Site 3 is a site with a very similar configuration to site 1. BUR v9.5u4 running on a Windows 2012R2 VM Guest (ESXi v6+). This is my proxy and application VM for VEEAM. The VEEAM Proxy mode is set at Network. This VM is backing up itself and running on the same ESXi host as the VM's I am backing up.

The following are general differences:
The target repository, a CIFS/SMB v2 share (Max SMB v2 min SMB v1), is a Synology 1618+ NAS.
The Synology NAS repository is not domain joined. It is a workgroup member. The VEEAM repository account used to access the CIFS/SMB share is a local (NAS) user account. The configured path in the repository properties is: \\ipaddress\share.

'Do not reserve disk space when creating files' is selected on the NAS' SMB settings.
VM Networking (Infrastructure) is 10GB. Physical Networking is 1GB.

This site runs as I would expect at 106 MB/s. Backup Copy Job from and to the NAS at this site is at 82 MB/s.

[Egor Yakovlev]

Greetings!
Few notes worth checking:
- Keep in mind that three Veeam installations are independent and are unaware of each other. That means they will fight for NAS resources, with first come first serve rule. For example, if Site2 Veeam server runs backup at 11pm, and Site1 Veeam server starts Backup Copy from Site1 NAS to Site2 NAS.
- Double check NAS Repository Gateway servers on each location for each NAS box. Especially for Target (ones Backup Copy is using as target). For example, Site1 Veeam server must have correct Site2 Gateway server set for Site2 NAS Repository, otherwise traffic will roam across network in an inefficient manner.
/Cheers!

[Wad4iPod]

Hello Egor.
Thank you for the reply.
My apologies for not mentioning this in the initial post.

These sites are not withing the same company/enterprise. They are independent and unaware of each other.

[Egor Yakovlev]

Ahh, you was mentioning Backup Copy processes that led me to conclusion of a seamless infrastructure.
Anyhow, I think neither DNS\IP part, nor AD\Workgroup part is what causes performance differences:
- first of all, NASes are of different model(which, beside different hardware, might also have different OS\firmware).
- Since NAS boxes are of different version, I would suspect different drives plugged in, maybe different RAID configuration. Thus difference in speed.
- IP\Name resolution problems happens when job starts and if fails, you will know that from Veeam errors. It is general best practice of Veeam to have properly configured DNS, so it should be out of question.
- Initial Authentication happens and refreshed periodically to keep session up, it should not cause any delays during job run(will be clearly visible in job logs as authentication timeouts and most probably would lead to job being stopped with errors).
- ideally you want to check those cases separately, ignoring the fact of lookalike identical infrastructures. I would give NAS boxes a stress tests in each site to see max possible performance. We have special guide for that here.
I suspect you will see totally different results giving same speed test on each site.
/Cheers